Feedhold / Realtime issue

[jrobson]

Hi

I was quite excited by the low price of Mach3, the large majority of boards and especially the ability to easily customize the interface, but then I read on here after a lot of searching of a feedhold problem with Mach.

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?

The reason it appears is because it is compiled to run on stander windows as a standard application. While something like EMC2 runs in realtime and receives confirmation pulses before sending out new steps as a result feedhold in EMC2 is instant within the next step and not he next line of code. Am I still on the right track?

Lastly is there a solution to this, can Mach not be compiled to run in realtime http://www.tenasys.com/support/files...eDatasheet.pdf. From the video on the site the gui performance is great.

I assume for the most part that the feedhold cannot be done in the motion controller card because mach would lose track of where the machine is?

Feedhold is a deal breaker for me, it will be really difficult to use Mach without it functioning properly, but the fact that the GUI is so easily customized is very tempting compared to EMC2.

Speaking of GUI performance(I've read on here some slow performance), has anyone tried launching mach with the /realtime switch to improve performance?

Are there any other options to get feedhold and feed override to function as it does on commercial controllers?

[ger21]

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?

Not really.

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.

Lastly is there a solution to this, can Mach not be compiled to run in realtime

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.

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.

Speaking of GUI performance(I've read on here some slow performance), has anyone tried launching mach with the /realtime switch to improve performance?

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.
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.

[jrobson]

Thank you for your response, it clears it up now about how the commands are sent.

I'm not yet 100% clear on the feedhold speedup you are talking about though, if the machine is at X0 Z200.(mm) and I command G0 X0 Z0. and press feedhold half way through at 100mm, since this is a single command will it stop at some stage before hitting 0 or at 50 or at 100?

On our lathe programs they are typically very short, 10-30 lines, we will stay with manually programming and not run many short stroke commands so the programs will stay short, the lookahead can be as low as 5 and still function fine, but the feedhold should stop quick. I believe the Galil products can handle this but not sure, but the cost for their controllers are high. It might be cheaper to pay a developer to build a decent interface for EMC2 and go that route.

Is it possible to get an estimation for how long it would take to activate? The machines are old, with 2500ppr servo's, 5m rapid on X and 10m on Z. DC's and I plan on putting the DC drivers in from cnc4pc along with their C32 card running through the parallel port. The pc I am looking at is a Atom 525 industrial pc with 2GB ram a 16GB solid state drive running stripped down Windows 7 or Windows 2008 R2(Or plain 2008 32 bit since I see 64bit doesn't work) core installation since I have a lot of open licenses left, dedicated for Mach, it has an onboard parallel port, It also has one PCI-Express slot and I believe I should add a plug in graphics card for best performance?

Sorry for the misunderstanding on the gui performance and thanks again for taking the time to respond.

[ger21]

I really can't tell you how fast it will stop. You'll need to actually test it to see, and try the different options I suggested.

I think with your 2500ppr encoders, you may not be able to use the parallel port, as you'll need a very high step rate. Or are you planning on using the drives step multiplier?

What is Windows 2008??

I don't believe you'll need to add a video card. That requirement was important 5 years ago, but most newer PC's run Mach3 fine with onboard video.

[jrobson]

Thats no good I thought it would be okay since they are servo not stepper I'll investigate what needs to be done... no use having a machine that is slower and more jittery than a 5 or 6t... I actually don't have a problem programming 5/6t but we are spending a bit of money on the hardware for repairs every year that I want to get away from.

Windows 2008 server 32bit is based on the Vista 32 bit kernel and the 64 bit version based on the 64 bit vista kernel, Windows 2008 R2 is based on the 64 bit Windows 7 kernel only, there is no 32bit windows 2008 R2.

It is easier to slim down 2008 server than it is vista/7, since you can install it without the gui called core installation, it is exactly that, just the windows core.

Understanding Windows Server 2008 Server Core

[jrobson]

I read on Machsoft that in 2010 ART figured out how to get some real-time performance on windows, not sure what that means for the future of Mach, when does V4 come out though and is there somewhere I can read on what to expect in future?

Regarding the limitations on the parallel port should I use a product like: 8-Axis Ethernet Motion Controller, Mach3 CNC Controller, .Net C# CSharp Library instead I assume?

They claim up to 2Mhz "soon" no mention of the current step performance though, but I've seen 2 video's with this controller and it's fast.

[ger21]

I read on Machsoft that in 2010 ART figured out how to get some real-time performance on windows, not sure what that means for the future of Mach

Art's been retired for about 2 years now. He'll occasionally make some minor mods to the parallel port driver, but that's it. Nothing major has changed in the last few years, and most likely won't in regards to becoming a "realtime" control.

when does V4 come out though and is there somewhere I can read on what to expect in future?

It's supposed to be beta testing soon, but is already over a year behind schedule. But the basic method of operation won't be changing.
I've heard that parallel port support may go away, but I don't think it'll be gone in V4.

From what I've read, V4 will have a new toolpath display, support for multiple spindles, better VB integration, new cutter compensation,.....
That's all I can remember right now.

As for the DSPMC, I can't answer that. But, there are other options.
Smoothstepper
KFlop
Centipede
And Galil cards are supported, too.

[jrobson]

Thanks, any recommendation?

Eventually I want to change all 4 lathe's over, but I want to start with the easiest.

It's a Wasino Lenuc-1, Fanuc 6T control X and Z only, no turret (Gang tooling) no spindle brake, the machine isn't working right now(busy building a bar feeder for it, and Z ballscrew needs replacing/fixing) so it's a good time to look at changing it over as a test piece. I just want to keep the motors and replace everything else, the spindle controller is fine too haven't had any problems with these ever but the servo drivers and controls are another story.

I'll read through the documentation from all these companies on how the products work and see which way to go.

Thanks for the help so far!

[jrobson]

After going through all those links I think I'll go with the kflop/kanalog setup, the response from them via email is fast and it looks like a good solution for older analog stuff. Thanks for the heads up

Btw, Tom said that the feedhold can be done in hardware to stop the machine instantly, but it's not clear yet if it can resume after, technically if it can't it wouldn't be called feedhold, but I'll check up on this.

Looks like this should all work in 64bit as well so possible to do a core 2008 setup.

[jrobson]

I saw on the yahoo group, indeed with feedhold wired into kflop it can be done in hardware, instant like OEM machines and resume, this is great news!