Machsupport Forum
Mach Discussion => Mach4 General Discussion => Mach4 Plugins => Topic started by: fjgesser on June 23, 2019, 10:46:02 AM
-
Dear,
About the encoder inputs of the ESS board with Mach4:
a) Is Mach4 capable of detecting a "following error" and performing an emergency stop? Consider a step loss situation detected by the encoder reading.
b) Can Mach4 acquire the current position after an emergency stop? That way, the CNC would not be forced to seek home again.
Best regards,
Felicio Gesser
-
Hi,
Is Mach4 capable of detecting a "following error" and performing an emergency stop? Consider a step loss situation detected by the encoder reading.
The ESS can read the linear encoder and can transmit the result to Mach4 but with a communication delay of several or maybe tens
of milliseconds. Mach would then compare the actual position result with its 'assumed' position. Remember that Mach believes
that machine is at position A, because it has sent moves to that effect, but those moves have been buffered so the machine
may not have made those moves yet and still be some way short of position A. The concept of where Mach 'thinks' the machine
and where it actually is, is indeterminate because of the comm delay is one direction and the variance of the length of
the buffer in the other.
The problem is that Mach4, or rather the Windows PC it runs on is not a real time system. The communication delays and
the motion buffer prevent you from having a real time feedback loop.
Controllers like the Hicon can be activated (at a cost) or the CSMIO/A can be feedback controllers because all of the feedback
processing is done on board in real tume without the comm delays of reporting bac to Mach.
If you use a modern servo and servo drive it will have a 'following error' function built in. Thus if the accumulated commanded
position from Mach differs by more than so many encoder counts (programmable) it would raise a fault.
Craig
-
joeaverage, Thanks
I ask my question in another way:
Would the ESS board (on its own firmware) be able to detect a "following error"?
I noticed the following information:
https://warp9td.com/index.php/gettingstarted/setting-up-the-smoothstepper-and-mach4
Encoder 0 Phase A
Encoder 0 Phase B, ...
(Please see attached picture.)
What would be the function of the encoder inputs on the ESS board?
Best regards,
Felicio Gesser
-
Hi,
Would the ESS board (on its own firmware) be able to detect a "following error"?
No. The ESS is not a feedback controller.
As I have previously explained, due to comm delays/buffering, neither is Mach4 capable of direct feedback control.
The principle function of the MPG read inputs of the ESS is to hook up handwheel. The ESS reports to Mach that the handwheel
has been operated and Mach can then issue move instructions to the ESS and thereby move the machine. There is a small
time delay, inconsequental for manual handwheel operations but inadequate for closed loop feedback.
Craig
-
Hi,
the general trend in CNC is for each servo/servo drive to be ever smarter.
In the early days of CNC servo drives were just amplifiers, they required a precision analogue input from the motion controller.
The controller would monitor the encoder/resolver and make adjustments to its analogue output to effect feedback control. So all the
smarts were in the controller and the servodrive was dumb.
A more recently the controller offers step/direction commands to the servo drive. The encoder is hooked NOT to the controller
but to the servodrive. The servo drive has the smarts built in to close the loop. Mach4 is natively a step/direction controller
and this is the sort of servo/ servodrive I would recommend.
The latest and greatest servodrives actually have a partial motion controller built in and they do their own motion control for its own axis.
Ethercat is an example of this. Mach still plans the trajectories and communicates to each servodrive but each servodrive does it own motion
control. This is an example of 'distributed motion control'. Mach is not 'yet' quite ready for Ethercat, but it will be. Whether you and I will be ready
any time soon is another question!
As to your current question if you use a modern servo and drive (prefered) or alternately a closed loop stepper (less advantageous but useful) you
can achieve what you want.
If your axis is coupled to a ballscrew then the rotational position MUST be directly linked to the linear position. Thus the encoder of the servodrive (or closed loop
stepper dive) performs identically to a linear scale attached to the axis and can signal a fault if the commanded position deviates from the actual position.
Given that this is monitored by the drive (realtime) then there is no issue with delays/buffering with Mach.
As an example I have a secondhand Allen Bradley servo I bought for a spindle motor. It is not new by any stretch of the imagination but is stil really really good.
It has an 8000 count per rev encoder. It has two (among many) parameters that I can program. One called 'following error window' I can program from as low as 4 encoder counts
up to 8000 counts. The default (where I tend to leave it) is 20 counts. If the output shaft of the servo gets more that 20 counts (0.9 deg) away from where it should be
it faults. The other is called the 'zero window. Its default is 4 counts. It means that when the servo shaft is within 4 counts (0.18 deg) of its commanded position
it ceases to try to close the loop any further.
If you had such a servo hooked to your axis would that suffice? It relies on the smarts in the servodrive which as I started with is the current trend in CNC.
Using a linear encoder and a smart controller is more the way things used to be done.
Craig
-
Thank you for the detailed explanation.
I consider that the Mach4-EtherCAT will be the biggest gain for the automation of CNC machines.
I use servo motor (step / dir) in low cost application.
From my experience a board like ESS based FPGA could be able to monitor the pulse train read by the encoder.
I'm talking about a passive comparator (no PID control).
You need to imagine a situation where the ESS commands pulses but the signal is lost before reaching the servo drive input.
If the ESS board monitored the encoder it would be possible to detect the error (pulses commanded - pulses executed).
Best regards,
Felicio
-
Hi,
From my experience a board like ESS based FPGA could be able to monitor the pulse train read by the encoder.
I'm talking about a passive comparator (no PID control).
You are correct, the ESS COULD be a feedback controller but Warp9 have expressed no interest in doing so. A major part
of that thinking is because each servo and servo drive is a feedback loop. Thus all an ESS need do is provide open
loop step/direction commands and allow the servo and drive to follow. The servo/drive have an following error window
and can monitor if the loop gets out of whack with respect to the input commands.
You need to imagine a situation where the ESS commands pulses but the signal is lost before reaching the servo drive input.
Imagine what situation? Are you talking a faulty breakout board?
My ESS has never lost any pulses in the four years I've been using it. As an example I have a PCB
program that I run from time to time, it is a largish but detailed board and it takes 10-12 hours to run. At the end of the
program I can drill a 0.4 mm through hole EXACTLY through the hole I drilled at the start of the job. If Mach, or the ESS,
or my BoB's, or my stepperdrives, or my stepper lost a step that would not be the case.
If the ESS board monitored the encoder it would be possible to detect the error (pulses commanded - pulses executed).
What I have proposed is that the servo drive monitor the commanded position (the cumulative step/direction position) by
Mach/ESS and the machines actual current and live position which achieves exactly what you are proposing.
There are controllers that can do as you wish, but they start at six and more times the cost of an ESS. In addition those
controllers are suffering a shrinking share of the market because of the to trend smart servo drives, the motion controllers
don't need it any more, in fact Ethercat does away with the motion controller altogether and 'distributes motion control'
amongst its Ethercat slaves.
Craig
-
Hi Craig,
You are correct, the ESS COULD be a feedback controller but Warp9 have expressed no interest in doing so. A major part
of that thinking is because each servo and servo drive is a feedback loop.
The three main reasons we have not done this yet are:
1) Servos with their closed loop control solve the issue for the majority of users who need it. This makes it a lower priority for us than other features that we have been delivering like Laser Raster and THC.
2a) In Mach4 a person could write their own lua script to monitor the distance of actual vs commanded and if the following error gets too large stop. Admittedly this wouldn't be ideal and it would be better done in the Servo or the motion controller. This would be happening all the time during GCode.
2b) If you are running in exact stop mode, whenever the motion stops and Mach receives an all stop position update, the lua script could see the reported position vs the glass scale position. This is a better option, especially in the lost steps scenario, telling you if things got off. But again only at stops not during motion.
3) The ESS doesn't have room in its FPGA for us to do it on board at this point. We are planning to make closed loop control an option in our next product, where it would be in the SmoothSteppers firmware.
Andy
-
Hi Andy,
I was interested in this new product.
Can you anticipate any information?
1. What are you planning to start selling?
2. Will the closed loop be with a step-dir or +/- 10V interface?
3. Support for 4 or 5 axes?
4. Planned price?
Best regards,
Felicio
-
Hi Felicio,
The new product won't be available until later this year.
It will have the same connectors and placement as the ESS. It will have a step/dir interface (or CW / CCW, or quadrature, just like the ESS), but it won't have a +/- 10V interface. It will be able to perform a real-time comparison of the commanded position and a linear encoder and either EStop or perform a controlled slow stop.
It will support as many motors as the ESS does, which is 6.
The price will be similar to the price of the ESS.
Andy
-
Dear Andy,
This will be the cost-sensitive solution for industrial applications with Mach4.
I will be awaiting the product release.
The other options (Galil, CS-Lab, Vital) are very expensive. More expensive than industrial grade CNC such as SZGH.
https://www.aliexpress.com/item/32972757912.html?storeId=1540064&spm=2114.12010612.8148356.4.5a9020edC870WU
Congratulations for the initiative.
Felicio
-
--
If your axis is coupled to a ballscrew then the rotational position MUST be directly linked to the linear position. Thus the encoder of the servodrive (or closed loop
stepper dive) performs identically to a linear scale attached to the axis and can signal a fault if the commanded position deviates from the actual position.
--
Craig
Identical? Ahhh, not quite. Closed loop motor position is being read prior to the drivetrain, (and most significantly before any slop that drivetrain contains, couplers, ball nut, thrust bearings, wear) unlike linear scale position which is being determined after the drivetrain and so is a real measurement of the actual rather than hoped for travel of the carriage.
-
Hi,
Identical? Ahhh, not quite. Closed loop motor position is being read prior to the drivetrain, (and most significantly before any slop that drivetrain contains, couplers, ball nut, thrust bearings, wear) unlike linear scale position which is being determined after the drivetrain
Quite correct, however you need a controller that can close the loop about a linear scale and that is not possible with an ESS. As has been pointed out Hicon
and CSMIO/A can do so....at greatly added cost and complexity.
There are two other alternatives:
1) Use a better quality preloaded ballscrew which reduces backlash to zero and lost motion to nearly zero....or
2) Use a load sensing servo drive, for example A2 series Delta servos.
To explain this last option somewhat better: all AC servos absolutely require a close coupled rotary encoder on the servo shaft so the 'Field Oriented Control'
algorithm can work. Any effective 'slop' in the rotary feedback will cause major and unsurmountable instability with the Field Oriented Control loop.
Thus, and for example, the Delta B2 series has a 160,000 cpr encoder built into the servo and that connects directly to the servo drive and it uses it to close
the Field Oriented Control loop and incidentally the load position via the angle-to-linear drivetrain. There is no opportunity to close the loop about a linear scale say.
The A2 series however can. It has a second encoder input and the position loop is closed on that encoder, which could be a linear scale.
The A2's built in encoder ( 1,280,000 cpr) is still required and used for the Field Oriented Control loop. You get the best of both worlds. The A2 series servos are about an
extra $50 by comparison to the B2 series.
This idea of a 'load sensing' encoder channel is not new nor is it restricted to Delta, almost all of the top end manufacturers offer the same or similar thing.
Neither is the secondary load sensing encoder limited to a linear scale. You could use an LDVT or even an interferometric sensor. Both of these devices are used to
'fine' control semiconductor processing equipment which has accuracy demands in the nanometer range.
For my new build mill I elected the first alternative, that is high quality preloaded ballscrews. They a re C5 ground, double nut screws by THK. I estimate that any
inaccuracy or lost motion will be smaller than my machine resolution. Such screws are not cheap, but then neither is the premium you pay for load sensing
servo drives and the linear encoders necessary to drive them.
Craig
-
Hmm, for my second machine, a mill conversion, I went to linuxCNC and a mesa card which has been able to do just this since its infancy. And at a much lower price point than an ess id add, I run one of those on my router.
-
Hi,
yes, that is indeed possible with LinuxCNC because the Linux distro on which it runs has realtime extensions, and can therefore be a realtime controller.
The Windows OS precludes realtime operation and all Windows CNC solutions must be buffered (hence not be realtime). To get closed loop performance
with a Windows OS machine requires an external hardware controller, like a Hicon or CSMIO/A, to provide the realtime processing loop.
There is another exotic solution for deterministic realtime on a Windows PC....but is rather getting away from the point. If you are interested you will
find some great videos by IntervalZero about it. It is by use of the this solution that Mach4 is able to run Ethercat, which is by definition a deterministic
realtime communication protocol. A very worthy and interesting development in Mach4 and available from Automation Solutions, a complete CNC system
without need of a motion controller or BoB.
Just as a side note Linux with RTE (RealTimeExtensions) on most PC hardware has a runtime jitter of about 4us, pretty respectable but it is not deterministic,
also called 'hard realtime'. By this I mean that while on average the jitter is 4us the system cannot guarantee it.There is an industrial standard which requires
absolute determinism and the system MUST be able to respond within a certain time frame. This standard is often applied to safety systems, medical equipment,
automotive and areospace systems. Linux with RTE does not (quite!) satisfy that standard.
Craig