Advanced Search

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)

G53 is your machine reference point that is set during homing.
G54 .. g59 should be saved when you exit linuxcnc. At least that is what happens on my installations.

Note that whatever control hardware is used, tuning will be problematic
unless you can remove almost all backlash from the mechanical system.