Advanced Search

There is really no control mechanism that can compensate for backlash
in a very satisfactory way, especially if the cutting forces can reverse.

Linear scales can compensate for ballscrew thermal growth, and flex
in the drive system in response to acceleration and cutting loads.
With any system you would need a way to read the scales and combine
the scale information with the main position loop.

Typically 2 PID loops would be involved as the tuning of the scale feedback
would have lower bandwidth than the much more tightly coupled rotary
encoder feedback.

 

I am a little bit confused about what to download, the one Rodw put on google drive or the one that was posted on 03/08
because I got the same errors about the opensuse stuff
it was really hard for me to get my boss to agree with changing from his hacked mach3 shit to linuxcnc with ethercat ...

Thanks.
Do I read between the lines, that you think it hardly makes sense?

If the hardware would be “perfect” with no backlash at all, there would'nt be an necessity for linear scales… And with backlash it is “problematic”.

Originally, the machine had tacho’s on the motors, to detect the motors were spinning and to control theirs rpm... Based on the position measurement of the linear scales (distance to go), the loop was closed until position was reached.

Would that principle be different if I would use step/dir instead of analog +/-10VDC in the old situation? The resolver needs at least 10x higher resolution than the 1um resolution of the linear scales I presume….

And is there then a necessity for a drive with two resolver inputs? Or can a controller-card take over the correction of backlash (which will be in any case)
Do they even exist without paying the highest price?

In the xml you can change mm to inch for the tab. Thats just optical change.

In the probe_pocket macro:

#<ff_distance> = 5 (5 mm distance to contact with fast forward speed)

Just change accordingly.

I dont have homing (I bought the limit switches but did not install them yet )

So every start I have to zero x,y,z and that will be my G53 every time.

What I am doing now is G53 G0 x0 y0 then I shut the machine

next start I will set x, y to zero again to set g53 again. For some reason G54 is saved. But it is useless if G53 is lost.

Thanks

Philip


Edit : 

apology

I just realized that my question has no meaning.

I have to install the limit swiches, be able to home, then G54 will work because it is saved.

 

 
It looks lilke aekhv has pulled the project There are are forks of it, but forking doesn't capture the wiki or the project or the releases. I'll attach the debian 3.2 release in case you still want to use it..

Since no advice was forthcoming, I decided to develop my own component that can monitor and change SDO parameters.
Essentially, this will be a similar component to the one currently working with EtherCAT LinuxCNC but specifically for manipulating SDO data. Unlike the existing driver, it will work with YAML, which is much more convenient than XML.
An approximate example of such a file will be attached. If there are any suggestions, I would be happy to hear them.
I think I will start this week and finish in about a week. Later on, it will be possible to integrate the old functionality for working with PDO.
Although the current one works well, it has its drawbacks.

PS Admins, please add yaml and yml formats to the editor.

Yeah inches...

Ok. There are two minor things to change. I am currently not at home but can answer later in more detail.

One is the fast forward in between a pocket. Here I use 5 mm to the estimated contact to use faster speed while probing. 5 inches just leads to the fact that there ist no faster movement.

The second one you find yourself. I have some (yes I know quick n dirty programmed) safety functions. In inches the values are way smaller so that the macro thinks that the probe is not calibrated.

Can you show your tool table please.

Julian

If you having trouble finding it, see github.com/thestealth131205/vfdmod

I'm not sure if the project has been hijacked, or the original owner changed his login without realizing the impact on his links. The good part is that the bits are all still there. I'll be making a fork to have a backup in case it goes away...

The spindle output is _not_ a PWM output but rather
an isolated analog output used to replace the potentiometer
of a VFD.

If you need a 5V PWM signal, you would need firmware
that includes a pwmgen with an output on a 5V pin

7c801p_5abobd.bit

Is one, this replaces STEP5 with a PWM output

 

I've tried different deadband settings by adding to my hal :

setp remora.joint.0.pgain [JOINT_0]P_GAIN
setp remora.joint.0.ff1gain [JOINT_0]FF1_GAIN
setp remora.joint.0.deadband [JOINT_0]DEADBAND

And to my ini in joint 0 section :

P_GAIN = 1
FF1_GAIN = 1
DEADBAND = 0.001

I've tried different values like 1, 0.5, 1.1, all of them didn't change anything.

Ok, two more questions:

First, what is the procedure for using this with a machine set to inches for the units?  I have converted the mm values to inches in the ini files but are there other values that need to be adjusted in other files?

Second, the calibration completes and enters the data into the tool table (I checked the file and there are now X, Y, I and J values added to Tool 99). When I try to do any other probing operatoin, i get the following error: No calibration data found in tool table. Please do a calibration. aborting
I re-ran calibration and now it is working. 

So, my first question still stands.

-Sean

I tried using 2.7 and I kept getting dbounce error and LinuxCNC would not load. I upgraded to 2.8.4 and I did not get the dbounce error any longer.

So you are saying that changing eno1 coalesce settings affects the other interface?
That's extremely weird

Is it possible both interfaces are sharing an interrupt?

(lshw should show this)