Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Hence the need for jolt limited tool paths.I have experimented with 60m/min and 0.8 G Accelleration (8 m/sec/sec) on a plasma table and can confirm what Don says that the inertia at this level of performance will shake your machine apart. People seem to gloss over that part of his discussion but it is very true.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Maybe my use case is a bit different as it is on a milling machine which is comparatively slow compared to the numbers being mentioned in this thread. But at the 0.0005 - .001ms offset you mention at a 10000mm/min milling speed (max rapids in my case) would only result in a position deviation of 80~166nm!The problem with LCNC and ECAT is that the master which is lcec driver from EtherLabs has a lag over the true ethercat comm cycle. In their docs they show a .0005-.001 ms offset from the true 1 ms tick cycle required for true ether at frame rate. That means that the FB of position is at a lag. Therefore by the time the position is returned to LCNC and LCNC recalculates the new position and determines the error the data is outdated. So Lcnc will never be able to show the true error nor fully close the loop over ether at in the purest sense.
...
The other course of action would be to install a scale and set LCNC to use that position to monitor the actual position to derive error from. But it would be overkill and a waste.
With LCNC over ethercat think of LCNC as a GCODE sender kinda. The sender has no idea if the axis did its job for the most part and assumes it did. But since I have a really smart drive, my assumption can within solid parameters be correctly assume it did its job.
This is the best you will get with LCNC.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.