Hello Guest it is November 27, 2020, 03:39:54 AM

Author Topic: Mesa FPGA cards  (Read 414 times)

0 Members and 1 Guest are viewing this topic.

Re: Mesa FPGA cards
« Reply #10 on: March 13, 2020, 05:28:47 PM »
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.
Steve Stallings
www.PMDX.com
For PMDX product support, please use PMDX forum or direct email for quickest response. We do not use this forum as our primary product support site.
Re: Mesa FPGA cards
« Reply #11 on: March 13, 2020, 06:23:38 PM »
Hi,

Quote
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
« Last Edit: March 13, 2020, 06:33:26 PM by joeaverage »
My wife left with my best friend...
     and I miss him!
Re: Mesa FPGA cards
« Reply #12 on: March 13, 2020, 07:37:34 PM »
Hi,

Quote
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
My wife left with my best friend...
     and I miss him!
Re: Mesa FPGA cards
« Reply #13 on: March 16, 2020, 08:58:59 AM »
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.