Advanced Search

Hello,
I'd like to say that I've managed to figure what the problem was. The devil is really hidden in the details. The product ID in the DeMS300 was set to the older CMM-EC01 module. I figured it while I was tinkering with the generic Cia402 slave. I just changed the PID in the lcec_ms300.h and recompiled the LCEC. No initCmds were needed.

Best regards!

This is true. But, no matter what as stated in most ECAT drive manuals they have a 1Khz servo update cycle. Which is the same rate as the tick cycle. Furthermore, 1Khz is more than sufficient as the drive~controller is not a closed loop system. This tick cycle at 1Khz has been used for well over a decade with success. Enough that ECAT is nearly the standard protocol.

Your limitation is neither LCNC or ECAT. Your limitation is hardware choice and understanding how to get your drive to perform based on your end effect loads or in the case of your initial question, no load.

ECAT is a protocol. A standard method of communication. Meaning, it is what it is out the box for a reason. You can have 50Ghz servo threads, and 50Ghz servo update in the drive, but the frame rate for the protocol will still be 1ms. Period.

Hi Arciera,

Yes XYZAC, XYZBC need different kinematics. For the math and calculating the tool direction in opencascade i just
thought use the letters A & B. At this stage the kinematics are not solved. Only the tool tcp & tool direction is then solved.
Do you think this is ok?

I'm still a bit confused seeing that tool motion still decelerates to a full stop after each segment.
In the video i speak about a first test without any motion logic for hal-core. Stopping motion at each gcode line.
Next step now is to add g64 fillets to the gcode. Then eventually the look ahead add's end velocity where it can.

That is okay for ECAT or Mesa.

That is 125 nano seconds not milli seconds. Or 1/8th of the ECAT tick cycle standard. That leaves more than enough time for the TP to calculate and form ECAT frames in the proper order and respond to incoming requests or updates such ACT VEL and ACT POS to update the planner. This is not your problem.

ECAT is a sync distributed clock frame bus. It is by ECAT standard fixed for specific reasons. The most important is determinism. ECAT motion control was designed for smart peripherals that no how to make cakes, nice and perfect cakes. It just needs a steady stream of how many and and how fast do the cakes need to deliver. The drive, if of decent quality should be more than capable to do this. ECAT for CNC is a very mature setup and requires very little "tuning" for the frames. What does need tuning is you motor/drive/machine.

Since ECAT in LCNC is only fully functional in CMD POS mode, you must tune your drives to match the return loop of your motor/drive. In your manual it gives a fairly detailed description of the parameters that are used in that mode. The TP and POS Loop will ONLY use those parameters. Typically, these are FF related needing gains to be adjusted for higher or lower inertial loads. You can try all the other parameters but, in the diagram for your drive you will see that in CP mode very few are used. But, if the drive is mature in the ECAT eco-system this mode will typically see better results than any S/D Mesa setup due to the internal TP and the true real time within the drive. Yes, ECAT drives have their own internal motion controller. Like a Mesa card in each drive only better.

It is not complicated. It just gets complicated when you look at ECAT on any CNC as a method to control motion using old and outdated concepts. Very few major CNC control OEM's use the fully closed loop system through the CNC control. They offload and create separation of concerns so that if the CPU needs to update the UI, it can without interfering in the overall thread. In fact, Siemens CNC controls have 3 separate buses. UI bus, NCK bus, and motion bus. Each has it's own isolated stream and communicated via a single shared data exchange in a Pub/Sub setup.

If you want to try and use LCNC to control the actual motion of your motors, use a Mesa with full closed loop control.

Hi, i was solving issue with raspberry pi 5 with guys at etherlab, and from my understanding 1ms or 1kHz ethercat cycle is limit for genetric driver. You can get faster cycles when using native drivers like e1000 or igb for intel based ethernet cards.

gitlab.com/etherlab.org/ethercat/-/issues/104#note_1772346704

EtherCat is 1 ms. tick cycle or 1Khz for the frame cycle. EtherCat in LCNC is more a 800~900hz so there is a slight lag but the DC will always sync to the first clock in the first peripheral. From then on all DC on all devices will be offset to sync with the known clock derived from the first device.

Etherlabs EtherCat explains this in the docs.

So regardless of servo thread rate, the EtherCat frame cycle will find its own clock rate to update the drives. As I have stated in prior posts, EtherCat in LCNC is a quasi real time version. It is functional to the mid app level. If you exceed 1500IPM in simult axis control, accuracy may suffer. Or the driver will drop the comms and error due to overload in the frame buffer.

I was just posting that but then got distracted.
I feel that too many are ready to jump to the latest kernel without really testing.

Probably by remaping M3 would be the best way, but no idea if M3 can be remaped.
I am sure it can be done in hal but that is quite a journey.
Using M6 or M7 is much easier, see mist/coolant use, requires adding an output for it in wizard, be it StepConf or PncConf.

Seems to be a kernel issue, to many PC's having the same issue, i though this was already fixed by using new kernels.

Maybe these modified files help:
forum.linuxcnc.org/21-axis/53099-manual-...-9-2?start=10#304309

'/sim/axis/remap/manual-toolchange-with-tool-length-switch' runs for me on a 2.9 build from February:
 

I just had some time to look into this again and a closer inspection of the 'lib/python/gladevcp' folder revealed that I had modified versions of 'hal_python.xml' and 'hal_widgets.py' files that seem to fix this error.

 

If you want it to startup in G54 then change this line in your ini:

RS274NGC_STARTUP_CODE = G64 P0.05

to

RS274NGC_STARTUP_CODE = G54 G64 P0.05


You may also want to set other things here
RS274NGC_STARTUP_CODE = G17 G21 G40 G49 G54 G64 P0.05 G80 G90 G94 G97 G98

Actually just found it in the docs var 5220

Hi Andy ; can you send me your mail adress or facebook or insatgram ..

That would be embarrassing, but an easy fix, and the sequence of events would match that.

I actually assumed that linuxcnc defaults to that on startup.

My mini mill at home appears to. Is that specifically set in linuxcnc?

Will have to wait till tomorrow to give it a try


Will do a clean startup and see what appears in the modal window