Category: EtherCAT
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.
