Position vs Velocity mode

endian wrote:

zmrdko wrote:

Thank you for explaining. So basically we are better off with position mode. Because servo drive is better at handling position commands from linuxcnc. I am running 8kHz linuxcnc servo thread which is the same as 8kHz cycle in B3 drives. The following error showed in servo drive is basically zero with proper tuned servo drive. The linuxcnc shows following error 0.22mm at 3000mm/s speed and 0.44mm at 6000mm/s and 0.88 at 12000mm/s. Does it mean that I should just set MINFERROR in linuxcnc with some room (so that I dont get following error errors), because the the following error which lonuxcnc shows is not the true following error? I will come back with screenshots and exact values later.
hello zmrdko,

your thread in the linuxcnc are running at oversample 8kHz .. what is your confing for them ? hardware and else.. ethercat has which time period ?

Hi foxington,

i am running i7 9700k (8c/8t - i think it’s the last cpu with one thread per core)
32GB ram and z390 motherboard and external intel ethernet card. I had bad latency with onboard ethernet adapter. I have also better experience with full size built pc, rather than office desktops (dell, lenovo). I dont know if it’s the motherboard thing, but i achieved better latency results with desktop PCs without any hassle. Might be the power efficiency crap in office pcs.

 
and also radeon rx580

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.

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

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.

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.

I true ECAT controller can use all 3 modes. Pos, Vel, and Tor. LCNC only truly supports Pos mode. That is the only limitation from LCNC. Based on the timing charts from EtherLabs best performance will be an open control/drive loop for Pos control only for the control side.

The balance of the performance is application specific to the user. It is up to the end user to build a properly configured mechanical drive and tune the motor drive combo to the setup you create.

If you need .001mm accuracy for the entire servo loop at speeds in excess of 10000mm/m then you should choose a different control software, and drive OEM.

Here is an actual scenario used in PNP(Pick and Place) for the chip making industry.

Positional accuracy and net velocity is desired at .002mm at 60000mm/m. In their controllers the servo positional update is sent every 1ms in .001mm increments in a point to point program. This is done using highly tuned and regulated hardware for the specific application.

CNC milling or turning does not need that level of granularity as feed rates/velocity is usually below 30000mm/m and rarely send point to point moves at .002 or below as the moves are typically highly coordinated multi axis moves such as a 3 axis arc move. This means that a 1ms tick cycle is more than enough to maintain a solid coordinated move within a volumetric accuracy of .002mm.. if one chooses a solid drive/motor/machine setup that can manage that granularity.

LCNC is hobby grade with some really cool features. But hobby grade none the less. Therefore, if you expect to see the performance of the chip machine you cannot use LCNC. The mixture of OS, Ethernet driver, and software stack limit the granularity of position to a velocity @ or near 30000mm/m. Above that and you will see the positional accuracy lower and repeatability suffer. And that is further disrupted by the rigidity of the mechanics and motor tuning. Remember that a servo drive position has a settling time, Acc/Dec, and following error. All are effected by the load inertia and capability of the drive to sufficiently recognize the error in cmd/act position and adjust while maintaining P/T. Many modern drives have such ability but as the ability grows so does the cost.

Donb9261 wrote:

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.

Ethercat cycle time should be shorter then 1ms but have to be longer than control scan time which has linuxcnc on correct hardware ... there is DC sync setup in the slaves and for drivers are multiplies of 250us times... therefore if lcnc scan time we change to 250000ns and calculations will be done, next we can change in the ethercat-conf.xml time to 250000ns and in the slaves too... we can change that time to single time sync period which are 250us... teoretically it should works but I do not have proper hardware for the check correction of this idea right now... 

At 1ms tick time round trip for the ECAT bus, you can theoretically achieve .001mm granularity of position. At that rate one could also have 60000mm/m velocity or 2362 ipm. Very few machines in the CNC world can even handle such speeds and the acc/dec inertial demands this velocity creates. Any attempt to advance the bus cycle time aka tick time is a waste of time and energy especially for a hobby/light industrial machine.

I would recommend doing some study of basic physics before walking down a road to nowhere. No matter how faster your motor, bus, etc... you are limited by the physical construction of your machine. Period. End of discussion. Or you have a $1 million machine for the likes of DMG or Chiron. Or simply a million bucks you like throwing away fixing the scrap heap that speed would create of your machine.

Millions of motion control systems utilizing ECAT run using the standard tick cycle of 1ms. I will default to a proven theory put to practice any day. A theory I have proven over years of practice myself.

Have a nice day.