I want to trigger an error if the difference between the actual servo position and the commanded position exceeds a certain threshold (e.g., 5mm) due to external forces. However, unless I set the  in the .ini file JOINT section to something very large (like 50 or 500), a 'Following Error' occurs immediately.

= INI FILE =[JOINT_0]
MIN_FERROR = 500
FERROR = 50

I want to set these values to be able to check following error within 5mm (5.0mm)
 I have already tuned the SERVO gains appropriately and confirmed that the actual physical deviation is nowhere near 50mm. The servo's electronic gear is configured so that 1 unit equals 1/1000mm, and I am converting the values to integers before writing them to EtherCAT.

= HAL FILE =
setp cia402.0.pos-scale 1000
 I know threre are 1ms time difference in EtherCAT and latency for servo position, but I think these settings are not proper.

Which part of LCNC settings should I check or modify to resolve this problem?

 

I'm using Sigma-X with EtherCAT.
I could rebuild IgH Master, thanks to Hakan.
Yaskawa Sigma-X is very strict for communication timing, etc.

Good morning everyone. This is very likely the problem. I've noticed that sometimes the problem occurs on the first reboot. I start LinuxCNC, with automatic startup at system startup. If I restart LinuxCNC with the system running, the problem goes away, but sometimes it doesn't. Tomorrow I'll try to test Grandixximo's latest fix. If it doesn't work, I'll reverse the bus sequence, install the SLA and I/O last, make sure the drives are the first node, and modify HAL.

I seems the initial delay is caused by lcec setting a bad initial reference time to the slaves.
Here is a listing of the first five lines, from lcec.write-all.
Data is cycle number, pll-err, reference clock time, application time lcec reads reference time of 3.53 second, and then sets it to 2.80 seconds. (lower 32 bits).
Now, speculating a bit, the clock is not changed right away, instead the clock is slowly changed
and the slave maintains a system time offset register 0x92c. It can then report and accurate
time by using the clock, that is off until in sync, and add the system time offset.
Must say it is speculation this though.

Anyway, the initial time setting in rt_app_main, or possibly the first few rounds in lcec_write should be looked at.
 

Hi,
was sind dort für Spindeln eingebaut Trapezgewinde oder Kugelgewindespindeln?
Wenn Trapezgewinde, dann würde ich Versuchen diese gegen Kugelgewindespindeln zu ersetzen.
Servos:
Da du scheinbar auf Ethercat gehen willst, würde ich hier zu Stepperonline raten.
Die gibt es günstig bei Amazon und sind hier im Forum gut getestet.
Die Glasmaßstäbe kannst du eigentlich ausbauen und gut aufräumen. Die Encoder der Servos sind bei weiten präziser.

Hi,

I've written a guide on this.
forum.linuxcnc.org/ethercat/58467-settin...attery-encoder-cable

all done, thanks

MaHa wrote:

While reaching the limit before generating gcode, just had a look at the operation options. Missing essential selection for ucs, and in general a preamble to be set. It seems corner radius is missing for pocket and contour, to have smooth direction change, and desired cornerradius. Stepover as percentage of the cutter diameter is more preferable than fixed value. The contour operations have no rough dimension input? Zig zag facing, is it using stepover? And the drilling operations, eg grid drill have no selection for cycle, retract, clear z (G98)
As i was not able to test for free, this is just from looking at the interface.
 

all done, thanks

Hi,

Thank you for testing! Found another Python 3 compatibility bug.
The function that modifies the ini file was still using old Python 2
API (io.BytesIO with str argument).

This will be fixed in the next release (2.0b-2) which I will push
to GitHub shortly.

By the way, there's a separate issue — your config folder has a
space in the name ("MILLING MACHINE"). LinuxCNC works with it, but
it can cause problems with some tools. Consider renaming to
"MILLING_MACHINE" for safety.

github.com/cnc-proton/nativecam-py3-gtk3/releases

Best,
Axemas

The main errors:
K0.75 is radius mode while in diameter mode.
I1 is radius mode (X34-X32) while in diameter mode
G96 D2500 ? 2500 m/min surface speed? Cutting steel with carbide  is typically only 1/10 that or less.
Maybe consider G97 S500 just to remove a variable while you are getting used it it?

Assuming a thread major diameter (stock OD) of 32, with you drive line at  X34, I-2. In practice, the major diameter is probably more like P/8 smaller. Somewhere around 31.8mm. Andy has programmed all that into his lathe macros, so you just give it major diameter (32mm) and it takes a first turning path at P/8 smaller before starting threading.
Since this is G7 diameter mode, the final depth K is also in diameter, so that will be 32-30.5 K1.5. Actually it is more likely to be about 30.38, so you will tweak this number to get your thread to fit, if you don't have perfect full profile inserts. Dont be surprised that you need around K1.62 to get the nut to fit.
J0.3 is reasonable. You will need lots of passes. See if you can get the insert to survive at J0.5
The R 1.6 means your cut will get heavier at each pass. I tend to set that at R2 for constant area, of course leading o increased number of passes.
The rest looks good.

G7 G18 G21 G90 G94
G0 X34 Z10
G97 S500 M3 M8
G76 Z-15 P1.5 I-2 K1.5 J0.5 Q29 H2 E0.75 L2

andypugh wrote:

You will need to have different orientations in the CAM tool table and the control tool table, but there is no auto-synching anyway, so that's not a problem.
 

Not that I can tell.

I set all tools to "turret 104" - i.e. back-tools - in Fusion, and make sure all tools are oriented the same way.  Fusion simulation always shows the tool above the part.  I just have to make sure spindle direction is appropriate for the particular tool.

The tool orientation value isn't passed from Fusion to the post, so the 'flip' only happens in LCNC.

I've not tested Fusion's 'turn below center' setting yet, so that behavior and post output remains to be seen.  I think if you select an OD boring tool and create an ID turning toolpath it will automatically reverse the spindle direction and output negative-X values.  Would be rather user-friendly if it works as advertised...

Well, that works nicely with only a minor issue remaining.

Backplot display now follows actual tool orientation, according to the orientation value in the tool table.  Had to swap the orientation M-codes; was confused until I remembered I have the configuration set to BACKTOOL in the INI file (X is up/away).

What's a little odd is that rotating the WCS doesn't alter jog direction on the handwheel.  X+ moves the table up/away, and X- moves the table down/towards the operator regardless of the WCS flip.

Remaining Issue: Something is off in the remap or toolchange.ngc, because G43 isn't automatically applied despite being in the .ngc file.  G43 works in the lathe-fanucy sim, but not on mine for some reason.

Down-facing "normal" tool - T5:
 

Up-facing "back" tool - T2
 
 

Thank you for your valuable feedback; I will look into each and every one of it.

While reaching the limit before generating gcode, just had a look at the operation options. Missing essential selection for ucs, and in general a preamble to be set. It seems corner radius is missing for pocket and contour, to have smooth direction change, and desired cornerradius. Stepover as percentage of the cutter diameter is more preferable than fixed value. The contour operations have no rough dimension input? Zig zag facing, is it using stepover? And the drilling operations, eg grid drill have no selection for cycle, retract, clear z (G98)
As i was not able to test for free, this is just from looking at the interface.