Not really.I'm not a programmer I'm just trying to understand the issue and am curious as to why it exists. From what I gather, Mach is open loop and only sends steps and does not wait for a return loop before it sends the next step, as a result it sends steps per line of code, which causes the feedhold to finish the line before it is active. Is this the correct assumption?
Mach3 is a buffered system, where many lines of g-code are sent to a buffer. This is the reason that Feedhold can be slow to activate.
There are two options you can try.
One, there's a setting in general config. "No FRO on Queue". This may slow the activation of the FRO, but should speed up the feedhold.
The other option is to decrease the lookahead setting in Mach3. I believe the default is 200. Try a setting of 10-20.
You'll need to try them to see if they work for you.
Some external motion controllers may indeed have instant control of feedhold, but you'll need to contact the manufacturers to know for sure. Since Mach3 sends motion commands, and not step/direction signals, these controls should be able to implement a realtime feedhold. Some of them may be doing that, but I've not used any to know.
No. Mach3 is almost like two different applications. The gui part, that reads and writes to the screen, and a kernel mode driver. The driver basically steals control of the PC from windows in order to do the critical timing things that it does.Lastly is there a solution to this, can Mach not be compiled to run in realtime
If an external motion control device is used, than the driver is not installed, as all the critical timing things are handled by external hardware.
While I posted yesterday about the slow gui while running on a 1Ghz PC, it's not really a complaint I've ever heard? What I was saying only relates to changing from one screen to another. There is now perceptible slow performance while on any given screen. The display in Mach3 is updated 10 times/second, and nothing can be done to change that.Speaking of GUI performance(I've read on here some slow performance), has anyone tried launching mach with the /realtime switch to improve performance?
There can be an issue when large g-code files are loaded (several hundred thousand lines of code). On some machines, this can slow the interface down. The workaround for this is to turn off the toolpath display. This issue is due to the way the toolpath display was written. It has been addressed and when the next major release of Mach3 (called Version 4) comes out, it should no longer be an issue.