Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Chris D on June 14, 2019, 05:24:43 PM
-
Good afternoon all,
I posted this on the Zone the other day and didn't get any suggestions so I thought I would try here. I know Mach 3 is somewhat "extinct" but thought maybe someone could chime in. Even if the solution lies within MACH 4, I would like to hear about it.
I have MACH 3, been using it for a decade or so. My current setup is: Windows 10, Mach 3, ESS (Ethernet Smooth Stepper). For the MPG, I am using a FANUC MPG wired up using "A" and "B" etc.
Regardless of what computer, what MPG, what machine, what configuration, I have NEVER been able to get the MPG to behave as it does on any industrial control.
I can set the distance per step, and if I slowly rotate the MPG, I will get a near perfect step with every click of the MPG. However, if I rotate the MPG any faster than "SLOW", not all clicks translate into an increment of motion. On industrial CNCs the machine will move 1 increment / click of the MPG.
I know there are settings for velocity mode, multi-step, single step, etc. I believe I have tried every combination of these and I cannot get the machine to perform "correctly". The best is in Velocity mode and the machine will move some distance greater than a single increment, however, it still starts and stops crudely.
I have tried the tuning function as well with no luck.
Has anyone found the magic combination to getting industrial MPG performance on MACH 3?
Thanks in advance!
Chris D.
-
You will not really get what you are looking for with Mach3 and the SmoothStepper.
The CSMIO/IP-A and IP-S do make the MPG behave like you want, not sure about others such as the DSPMC or the CNC drives controllers as I have not used them.
So basically you are stuck with the way the ESS works or change controller.
When I was using the ESS I used to use it almost exclusively in continuous mode and then just change to increment if I wanted to sneak up on something more precisely, it was still not perfect but it is the best you will get.
Edit
By continuous mode I am meaning Multi Step.
-
Hi,
I suspect that you are up against the limitation of a Windows CNC solution.
Windows is not a realtime system and due to Windows extensive use of the interrupt system for its own purposes it cannot
ever be a realtime system. CNC IS and IS REQUIRED to be realtime.
To achieve CNC control all Windows CNC solutions are buffered. That is to say that Mach issues P(osistion)V(elocity)overT(ime)
data to a motion controller in a buffer, sometimes as short as 50ms but possibly up to 1000ms. Please note that for the purposes
of this explanation that I consider Machs parallel port a motion controller just like a SmoothStepper or UC100.
Any realtime operation required by the CNC machine MUST be handled by the motion controller. As an example if you
are referencing (homing) your machine and the X axis is advancing towards its home switch. When the switch activates the
axis must stop immediately. The motion controller must do it, it can't wait to send a message to Mach, Mach decide what to do
and then send an instruction back by sticking it in a buffering queue. Its just to slow...the machine would have overrun the
home switch already. This is an example, one of many, of realtime 'supports' that a motion controller must be able to offer
because its nominal 'master' is at the far end (time wise) of a queue.
With respect to jogging, Mach plans a trajectory and issues PVT data to the motion controller by adding to the buffer.
Many, if not all, industrial machine controllers are realtime, thus each 'click' of an MPG results in a 'click or step' at the servo
concerned within microseconds.
It is not surprising then that there is a difference between to two approaches.
I have used Mach3 and Mach4. Mach4 has a somewhat faster response but is still buffered. I leave my Mach4 installation
at its default buffer length of 180ms. With subtle differences they both perform similarly.
If you require realtime response use a dedicated industrial controller or use LinuxCNC. Certain distros of Linux have
R(eal)T(ime)E(xtenstions) and makes a pretty fair realtime system.
It is possible to make Windows into a realtime system, the RTX64 solution of Interval Zero is a very good example and is well
worth Googling. It will help you understand the difference between Windows and buffering verses realtime. At the time I researched
it was beyond hobby budget.
Note also there is a conversation going on in the Mach4 board that addresses a similar issue. Both that thread and private
communications suggest that an Ethercat solution may be on the cards which rely on RTX64 to provide realtime determinism
to a Windows PC.
https://www.machsupport.com/forum/index.php?topic=41233.0 (https://www.machsupport.com/forum/index.php?topic=41233.0)
Craig
-
Craig
as I have said it can be done with Mach3 but it requires the controller to do it, the CSMIO/IPS and IP-A work exactly like an industrial control does regards the MPG. You set x1, x10 or x100 and it will move the exact distance you have set for each click no matter how fast or slow you turn the MPG.
-
Hi Hood,
I was unaware that the CSMIO can process MPG pulses directly into step/direction pulses in realtime.
The CSMIO Mach4 plugin is still lagging other Mach4 controllers and consequently is not well represented amongst
Mach4 users no matter how well built they are.
Craig
-
Yes I believe that to be the case with the CSMIO and Mach4.
Mach3 does all I need on the two machines I have the CSMIO on, the plasma and the Chiron, so it is fine for me and no need to upgrade at this time, what the future holds know one can tell, well except for death as that is a certainty :D.
-
i use a 80€ XHC USB MPG on my Weyrauch, and does exacly the selected step's.
-
Thanks for all the information guys. Frankly this is very disappointing. Being that MACH 4 is promoted more as a industrial control I would have expected that this would have been resolved.
As for the XHC USB MPG, I have a wireless version of that and it too performs poorly.
Chris D
-
Hi,
what exactly do you think should have been resolved?
Windows PCs are not realtime systems that implies certain limitations. If you don't like those limitations don't use
Windows. It's like trying to blame water for being wet.
Craig
-
It is not really Mach's fault but more the fault of the controllers used with Mach. If the CSMIO can do it with Mach3 then I must assume other controllers could.
With the parallel port then it may not have been possible but even then it may have been if it had been done at driver level, that however is something I know nothing about.
-
Thanks for all the information guys. Frankly this is very disappointing. Being that MACH 4 is promoted more as a industrial control I would have expected that this would have been resolved.
This is one of my biggest issues with Mach4. No matter how good the software is, you have to rely on the hardware supplier to make it work.
-
Hi,
This is one of my biggest issues with Mach4. No matter how good the software is, you have to rely on the hardware supplier to make it work.
Doesn't that apply to ALL Windows CNC software?
What you are talking about is the realtime supports that the controller manufacturer builds into his board. If he, like CSLabs built
in realtime MPG to step/direction then all well and good, if not then there is the buffering delay.
Presumably you could build an even more sophisticated controller that does more and more in realtime, in fact if it
did it all then there would be no need for a Windows PC at all! That would certainly cure the buffering problem. ::)
To OP: if you want genuine realtime performance not just of jogging but ALL motion then:
1) Use LinuxCNC
2) Use a dedicated industrial controller.
If however you are concerned only with MPG performance then Hood has outlined a solution....CSMIO.
Craig
-
Doesn't that apply to ALL Windows CNC software?
No. I'm talking about all features.
If Artsoft adds a new feature tomorrow, how long until it works in the ESS, or with a CS labs board? Months, if at all?
If CNC Drive adds a feature to UCCNC, they update the firmware at the same time and it works when it's released, on all their hardware platforms.
Same thing with every other windows control, as everyone else develops both hardware and software together.
Mach4 was released about 5 years ago. The ESS still doesn't support every feature, does it?
-
Hi,
The ESS still doesn't support every feature, does it?
Well yes it does, although it does not handle jogging as the CSMIO does.
ESS (in Mach4) offers:
1) Realtime THC
2) Spindle PID
3) Baklash Comp
4) Single point Lathe Threading
5) Laser Rastering/Vectoring
Plus all the usual homing/limits/gantry squaring/probing that we assume all controllers can manage.
Craig
-
how well does UCCNC handle jogging and the mpg?
-
Did a quick vid today to show the CSMIO and MPG. This is the X axis, set to x100 which means each click is 1mm and a full turn of the MPG gives exactly that.
https://www.youtube.com/watch?v=uh5D5hpipH4&feature=youtu.be
-
I like that video - that is what I expect a CNC machine to do when using the MPG!
I don't really care to dispute the capabilities of Windows, real time, non-real time, Linux etc.
I do know this, with Mach 3 using either the parallel port or using an external motion control card, they are doing real time pulse streams to the stepper / servo drives, this has been done for a very long time with the Mach software. Based on that, I fail to understand the "real time" issues related to Windows.
To me, it is a feature and capability of the MACH software that simply never has functioned properly. It is a feature that is presented and promoted, but never clarified with a disclaimers stating "the MPG feature sort of works, but not really, but it could work if you bought this controller card, but it won't work with the parallel port or any other motion control card, so, be informed, this feature will only work if you buy this particular motion control card .... blah, blah, blah."
Don't get me wrong, I am not bashing MACH, to this day I find it absolutely amazing what it can do.
Chris D
-
Hi,
this has been done for a very long time with the Mach software. Based on that, I fail to understand the "real time" issues related to Windows.
Mach, or indeed any program on a PC, does not run continuously. It will run for a few milliseconds and then Windows will rush away
and do anther job or even several jobs and then come back to Mach and run for a few more milliseconds. This is the nature of
Windows and little or nothing you can do about it.
Your steppers/servos require non-interrupted pulse streams, the machine would stutter and stall if it relied on Mach alone
to generate pulse streams given that Mach runs 'in fits and starts'. For this reason Mach builds up a string of moves
and stores them in a buffer so while Mach is idle waiting for CPU time the motion controller 'has something to go on with'.
Its that 'something to go on with' that characterizes ALL Windows based CNC programs. While it works pretty well,
jogging in response to an MPG is one area where the 'something to go on with' idea catches you out.
The CSMIO works as well as it does because it can directly process MPG pulses to step/direction pulses without Machs
intervention. It is however the only controller that does that, to the best of my knowledge, and until Hood pointed it out
I didn't know that.
All the genuine realtime hardware controllers are very expensive, ten times and more what Mach costs.
LinuxCNC however is free and the hardware required is modestly priced. I personally am not a fan of Linux but you may
differ.
I use a VistaCNC P1A pendant, first with Mach3 and then with Mach4. The pendant is USB connected to the PC and has its
own plugin. In response to the pendants plugin Mach plans moves and communicates them to my ESS which in turn
generates the pulse streams required to move the axes. I have no trouble, if I select 0.1mm per click, the axes move 0.1mm
per click. What can happen if I select 1mm per click and spin the MPG fast the 'clicks stack up' faster than the machine can move,
and the machine runs on after I have stopped spinning the MPG to catch up on the backlog. It is very un-nerving. If I increase
the jog speed the machine can move that much faster an the problem is much reduced. I don't like that idea much, usually when I'm
jogging I want modest movement speeds to prevent overruns, inaccuracy and crashes. For this reason I tend not to use 1mm
per click, but I find 0.5mm per click or 0.1mm per click better matched to my machine speed and my brain function!
There is a thread running on the Mach4 board which talks a bit about Ethercat. Ethercat is essentially real time communication
for which Windows PCs have struggled because they are not real time capable. What changed here is a VERY clever
innovation provided by Interval Zero called RTX64 which adds a real time processing core to your existing Windows machine.
Further is sounds like its coming to Mach4 soon......and we hope affordably.
https://www.machsupport.com/forum/index.php?topic=41233.0 (https://www.machsupport.com/forum/index.php?topic=41233.0)
Whether it would solve your problem is not immediately clear to me but it might interest you. Googling Interval Zero and
RTX64 will yield some very interesting and informative videos.
Craig