Position vs Velocity mode

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.

Hi,
you lost 3 orders of magnitude there.
1000mm/s * 0,001s = 1mm
3m/min *0,001s = 0,05mm
so there is a LOT of justification in trying to achieve more.

Plus there is people (like me) that build air bearing machines and want to achieve less than 50nanometer following error on dynamic applications with linuxcnc.
There is a reason why industry controllers run anywhere between 1 and 10khz position command cycle.

Regards
Leo

Hello,

At 60000mm/m the velocity is 1m/s or 39.37 IPS. In the world of linear motion this is quite fast. In the world of CNC, that is astronomical speed. Typically reserved for G00 commands for initial positioning. The limiter here would be the cutting feed. No tool can cut effectively at that speed of 60000mm/m. The scale of limitation is determined by the material being cut as a measure of chip load. Even the softest materials such as MDF have a finite chip load that will limit the overall max velocity of the command. Typically near 8800mm/m or 8.8m/m. Pretty simple.

If I have a 10mm pitch ball screw which will provide 10mm of linear travel per rotation I would need to rotate the ball screw 880 times to move exactly 8.8m over 1 minute. Again, pretty simple. That also means my motor will rotate at exactly 880 RPM. Or 14.6 RPS. If I need to move 1mm at that velocity of 146mm/s I would arrive at my desired position in .146 seconds or 146ms. If I use the same velocity for .5mm then my time of arrival is cut in half. and so forth. Since we are on a 1ms tick cycle and assume 50% of the time on the bus for sending the data to the slave and the slave responds in real time we can assume that the slave can effectively make the 1mm move 6 times +- per second. Not that anyone would ever do this, but for example sake... If I use a 20mm pitch ball screw I can double my speed to desired position of 1mm@8.8m/m at a reduced force arriving in .073ms(assumes a command multiplier in the slave). Now having the ability to move this distance more than 10 times per second. I can further modify this by increasing the command multiplier through EGR or additional pitch on the ball screw to say 50mm. The above only allow for less transmitting of positional data without having to lower the bus speed because the controller need only send half or less the moves to achieve that same ends. *Note - The above assumes you have a 23bit ABS system to allow for maximum PID control at such speeds. Since LCNC is Position Mode only you need the drive to have as much feedback data as possible so that the PID sampling is very tight keeping actual error low.

As you can see, if one is trying to use EtherCat via CoE at 1ms tick cycles, the machine performance with LCNC is more than ample to meet the specifications required to match the maximum effective cutting performance.

The positioning error is also easily managed by a drive that has a 1Khz sampling cycle at the speeds above. Although most drives of substance have a 10Khz sample rate such as Omron, Yaskawa, LS Electric. This is a function of the drive and not of LCNC since it is in Open Loop from LCNC to the drive. The drive closes the loop and uses its' internal algorithms to control the PID.

The accuracy of each move is determined by the drive/mechanical as a function of inertial load and the ability for the drive to control the jerk loads and closely manage settling time. Settling time being a function of the ability for the drive to acknowledge position arrival once settling is complete and is ready to accept the next command given.

At the end of the day, the performance of LCNC is well within tolerance for machine tool applications as long as the hardware choices by the end user are sufficient to drive the given load at desired velocities within a desired overall accuracy.

For nm following error, one would have to have a RT kernel written specifically to only handle the Ecat bus and have a dedicated driver for the PHY(Ethernet Port) to only allow for ECAT bus frames with no interrupts and absolutely zero addressing. This system would be a subsystem of the main kernel. More or less a PC in a PC. Kingstar uses Interval Zero RTX64 in a windows environment. The RTX64 RT is a sub OS that runs along side Windows. Kingstar layered in the ECAT framework inside the RTX64 OS and has achieved a true PC based ECAT with 100 um tick cycles with DC. It works flawlessly. But, it only works in Windows. Mach4 worked with them with me as an advisor to form the integration about 8 years ago. It still works today.

Mach4 has an issue though. They use wxLua for the GUI control and it crashes a lot making it unreliable. Hence, I never pushed forward due to the fact that Mach4 staff would not move away from the terrible wxLua system. The TP designed by the lead programmer is bar none one of the best but I require 99% uptime for my controllers. Mach4 barley breaks 90%. One side note is that I was able to during the same time have Mach4 built with custom Macro B and exactly mimic Fanuc macro variables for a linear compat for my clients who wanted to shift to Mach4 for cost but not sacrifice the overhead of rewriting hundreds/thousands of fixed programs that utilized Macro B. Still works today. But like I said, the wxLua aspect was a deal breaker.

If application desire is to have nm error at speed, you need to use Torque mode over ECAT and use a controller that accommodates that functionality to which, as far as I can see LCNC/Etherlabs has not implemented fully. You would be on your own to write the kernel config and PHY driver for that. Possibly even move it away from the uspace domain. Hard to say. If I were to do what you attempting, I would use a different CNC software specifically deigned for that purpose. But, I do fully understand the cost factor. Unless maybe you can get Biden to subsidize your desires... Lol.

I would find it more than interesting to see if you can achieve your goals in LCNC. Is it possible? Sure. Anything is possible.