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/10^th 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.