Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: akcnc on March 13, 2020, 12:34:08 AM
-
I have searched the forum to see if anyone had developed a partial or fully working plugin for any of the Mesa FPGA boards but most post on this subject seem to end a long time ago. I had started on a plugin project for Mach4 a number of years back but had to drop off completing it due to other obligations.
To get started on this I have updated the SDK I have to version 4430 and will be setting it up on one of my Win7 development computers in the next few days to refresh my self.
One of my milling machines is using a pre-programmed network connected Mesa 7I80 FPGA board and almost all of its 72 available pins are in use. The milling machine runs fine using Linuxcnc but I would like to have the option of being able Mach4 on this machine as well. Another of my machines uses Mach3 and would benefit from a upgrade to a Mach4 and Mesa configuration as well.
Referring to the short description below, do you think that Mach4 can be set up to handle those same functions?
The knee mill I plan to use for testing if all works out has 5 motor drivers for DC motors using step and direction with each also having rotary decoder inputs. 4 motors are in use with rotary encoders mounted on the back. There are also linear encoders on the machines knee, X, Y and Z axis that provide a,b and index pulses to provide closed loop feedback for position control on X,Y and Z. So I hope that Mach4 is able to handle the closed loop signals from the linear encoders.
The spindle has gear tooth encoder along with index detection to control spindle speed which also provides a,b and index pulses. Spindle speed being controlled by Mesa PWM converted to 0-10 Vdc externally.
There are positive and negative limit switches on the Knee, X, Y, Z. and home switches are on X,Y and Z. Two probe inputs are used, one for spindle use and one for the table. Additional IO pins are used to switch the machine from CNC to Manual use and to provide a interface to the manual control box for power on, move out of limits, estop and other functions related to CNC or Manual mode switching.
-
Hi,
sounds like a great project.
Craig
-
Hi,
So I hope that Mach4 is able to handle the closed loop signals from the linear encoders.
No, Mach4 is not a feedback controller because it is buffered. That is to say that Mach4 is not realtime and must therefore buffer motion commands and as a consequence the 'around the loop delay' precludes realtime feedback.
Those devices that do offer feedback control to Mach4 (Hicon suitably activated and CSMIO/A) the feedback loop is handled by the
motion controller with realtime hardware under the supervision of Mach.
If you wish to have realtime linear encoder feedback YOU MUUST enact it within the FPGA of the Mesa board.
Craig
-
A slight clarification about closed loop feedback with Mach4. The signals to read back the encoder data would need to be provided by the FPGA on the Mesa card, but the action of using the feedback signal to correct for following errors could be implemented in either the FPGA or in the software of the Mach4 plug-in running on the computer. Using the plug-in software would likely be the easier approach.
-
Hi,
or in the software of the Mach4 plug-in running on the computer. Using the plug-in software would likely be the easier approach.
Really? What about the buffering delay between Mach4 and the motion controller? The ESS has a default setting of 180ms buffer.
All Mach4 controllers require a buffer. You cannot close loop control a servo with that sort of delay.
It is certainly possible for the FPGA to present Mach4 with the current encoder count for a DRO for instance, but that is not closed loop
control.
Craig
-
It is complicated and I need to go back to review how it all works. I think the depth of the motion queue does not delay command and control messages. That may be motion device dependent. The motion queue is really about not upsetting motion when Windows is too busy for the Mach4 application to process data to put in the queue. The message transfer, Ethernet or USB, happens at a lower level in the system.
-
Hi,
I think the depth of the motion queue does not delay command and control messages
Motion commands are issued by the trajectory planner in the form of PVT data which is queued. Even if Mach was instantly
updated by Ethernet about the position of the servo it would still have to issue trajectory commands and ergo the buffering
delay.
Closed loop control bandwidth is highly dependent on the 'around the loop' communication delay. If you have a buffering
delay of 100ms, given the Nyquist sampling theorem, the best possible closed loop bandwidth would be 5 Hz. Any control
engineer will tell you that the discrimination of a control loop running at the Nyquist frequency is rubbish, you will get
only fair discrimination at 1/10th the Nyquist rate, in our example 0.5Hz.
Half a Hz bandwidth might be adequate for a temperature control loop with a temperature time constant of 5 seconds but
it will fail miserably trying to control a servo.
Adequate servo control for CNC axis purposes requires an absolute minimum position bandwidth of 100Hz, 250 to 500Hz is
the common norm for entry level servos and 1000 to 5000Hz for the latest and greatest servos.
Mach4 is not a realtime control system, and that is because the operating system on which it runs (Windows) is not realtime
capable.
Linux distros with R(eal) T(ime) E(xentsions) is realtime with a quite respectable jitter of 2us-4us on common PC hardware.
Windows can't manage that.
Craig
-
Command and control messages are outside of the PVT queue and I was implying that the servo loop correction would operate through command and control messages, not the Mach4 PVT queue. Granted there is still a round trip communication issue and scheduling delay for when the plugin gets to run, but these are still much less severe than the queue delay. Ideally the motion control would have a processor capable of closing the loop inside the motion control, but as far as I know, only the Vital Systems Hicon family and the CS Labs CSMIO/A offer closed loop within the motion controller.
-
Hi,
Command and control messages are outside of the PVT queue and I was implying that the servo loop correction would operate through command and control messages, not the Mach4 PVT queue.
Good point, and is this just exactly what NFS has exploited to enact software controlled THC released some months ago? Using
the concept of an override axis a servo/stepper can be adjusted in near realtime 'around' its nominal trajectory be offered up by
the motion buffer. The apparent bandwidth of that setup is about 10Hz-20Hz and is adequate for all but the most demanding
(dynamically speaking) THC loops but is still a factor of five short of the bandwidth required for effective servo control.
Ideally the motion control would have a processor capable of closing the loop inside the motion control, but as far as I know, only the Vital Systems Hicon family and the CS Labs CSMIO/A offer closed loop within the motion controller.
Yes, I would agree. This was my intent to inform OP that Mach4, not withstanding the much improved command/control loop frequency,
is not suitable as a positional feedback controller. That capability would have to be provided by the FPGA on the Mesa board.
I'm unfamiliar with those boards but was not aware that they had feedback capability.
Craig
-
I had forgotten that Mach does not have the same internal configuration ability within its hal layer that Linuxcnc does. Since Mach configuration is done with check boxes the features that I'm used to using and depend on would not be available.
I agree that the closed loop part should be within the FPGA programining and that is way outside of my knowledge base to accomplish. My gantry milling machine does not use closed loop functions so I will concentrate on converting it from Mach3 to Mach4 instead of proceeding on the knee mill.
Just out of curiosity would the use of windows embedded instead of the regular windows versions offer a performance increase or is it just a stripped down version that is still not real time capable.
I will also do more research on available motion controllers with closed loop abilities.
-
There used to be a beast called Windows RT, but as best I know it no longer exists. Even when it was around it was very expensive and almost unrecognizable as Windows.
As Craig said, the bandwidth of any scheme that tries to use software inside the host PC, as part of PMC or as part of a motion controller plugin, would have somewhat limited bandwidth. Probably adequate for running DROs, torch height controls, and supporting backlash compensation, but not full up servo control.
-
Hi,
There used to be a beast called Windows RT, but as best I know it no longer exists.
There is still such a beast, I don't know about RT, its been a long time since I've seen any reference to it, but there is
Interval Zero.
They have some superb videos on their website about how they enact realtime processing on a Windows PC, highly
recommended.
The idea is that one core of a multicore processor runs a realtime scheduler while the rest of the cores runs Windows normally.
There is a rather slick data exchange between the realtime thread and Windows but at no time can Windows interfere or stop the
realtime thread.
I investigated purchasing it some years ago, it was going to cost $16000AUD for the software tools and then there is still
the per machine runtime license. The price stooped me cold!
In recent times Interval Zero have partnered with Kingstar and they have used the realitme core to enact EtherCat, a realtime
Ethernet communication protocol that works with Mach4. This is to my knowledge, the fisrt attempt anyone has made to
'make Windows realtime' and thence use it as a CNC solution.
Note this idea of a realtime core does not make Mach4 suddenly realtime, Mach4 is still a Windows app and requires a Winodws
environment replete with the scheduling delays that characterize Windows. What a realtime core can do how ever is run a
smaller realtime program like EtherCat. All very clever!!!
Smurph seemed very impressed with the ease of which the Interval Zero realtime core could be grafted into an existing
Windows PC. The video banner of this forum is of a Matsurra VMC making a part running Mach4/EtherCat by Kingstar/Interval Zero.
It has rather taken us adrift from OP's question regarding the suitability of Mach4 for realtime closed loop control of
servos, then answer is no.
Craig
-
Hi,
Just out of curiosity would the use of windows embedded instead of the regular windows versions offer a performance increase or is it just a stripped down version that is still not real time capable.
I use Windows 7 Embedded (Standard) on my machine PC. Windows Embedded allow you to load, or not load chunks of code. For instance
you have no need of multimedia capabilities when designing and building a Point of Sale PC so why bother loading it?.
I would recommend 'The Professionals Guide to Windows Embedded Standard 7 by Sean Liming', Chapter 8 'Realtime Support'
and the references contained therein do a masterly job of explaining why Windows is unsuited to realtime use.
The essential idea is that 'Windows Embedded does not change Windows essential DNA'. Windows makes HUGELY EXTENSIVE
use of the CPU's interrupt system, it uses it to schedule threads and all manner of things in a multilevel priority scheme.
You can't turn them off nor can you (materially) alter the priority WITHOUT crashing Windows.
Thus when an app like Mach4 demands service it must always defer to higher priority tasks determined by Windows, to do otherwise
is to crash it. Therefore Mach (3 or 4), and in fact ALL Windows PC based CNC software solutions, must have a buffer so that
when Windows skives off to do some important (to Windows) task meaning Mach4 is paused the buffer allows the motion controller
a queue of motion data to consume. We just have to hope the Mach4 again receives CPU service BEFORE the motion buffer is drained
otherwise you motion controller 'runs out of data' and the machine stops.
You might think that this fundamental difference between realtime (example: LinuxCNC) and buffered (example: Mach4) puts
the Windows solutions at a disadvantage. There is a modicum of truth to that.
However when you are standing at the machine operating it there is virtually NO DESCERNABLE difference between them.
One time that you might notice a difference is if you hit <FeedHold>, with Mach the machine will continue to operate for the duration
of the buffer, commonly around 200ms, whereas LinuxCNC would stop, to all intents and purposes, instantly.
The other time where LinuxCNC shines is the ability of the software to enact closed loop control over servos whereas Mach4 cannot do so
directly. Having said that you may have noticed a recent development in AC servo technology called 'dual sensing'.
For example Delta A2 series servos. The servo drive monitors the servo mounted encoder as all servos drives must do but can in
addition monitor a second encoder, like a linear scale, and incorporate that into its position loop as well. Thus my Mach4/ESS solution
could now enclose a linear scale 'just like the realtime boys' by use of such a servo and drive. They cost about $50 more than
the regular B2 series (160,000 count encoder) servos I have just bought! Ho hum, I wish I'd done a little more research before I
bought them....not that I need dual sensing....its just I want to brag....and do what my mother recommended I did not for the sake of
my eyesight! LOL
Craig
-
I'll add a short tagline onto this. Most modern position servos close the position, velocity, and torque feedback loops at the motor controller (servo drive). 20 years ago, almost all servos were analog velocity or torque controlled and required a position controller separately. This got many people in the mindset (even to this day) that a closed loop motion controller is necessary or even beneficial.
Now there are a few cases where it is. Mainly these are software features like rigid tapping or threading on the lathe which requires axis synchronization to an external encoder. The other case would be using dual feedback (motor + load). This allows the control system to compensate for mechanical errors such as screw lead and backlash by direct measurement of the final actuator. The latter example is even incorporated into a handful of higher end servos as Craig mentioned.
The point I'm making is that if closed loop positioning is what you are going for, there are fully functional, inexpensive, and easy to integrate control methods which work with Mach 4 today and do not require Mach 4 to act closed loop. Many other features can be made closed loop at the motion controller (i.e. Ethernet Smoothstepper THC or PID spindle). Mach 4 being buffered isn't as big of a deal as many make it seem.