Feed Hold

[Promech]

There is a noticeable lag between the time I hit Feed Hold button and when I see the axis stop (say when an MDI motion command with G0 or G1 is being executed). This may be dangerous when too close to the part. I have tried the same with Stopfile, and the axis movement stops almost instantaneously (as it should).  Any ideas as to how to get the feedhold command to react faster?

Jorge

[Hood]

PP or SS  or other device?
Hood

[Promech]

PP, Kernel 45,000 Hz.

[Hood]

Should be reasonably fast then but it will not be instantaneous like pressing Stop. Stop cuts the pulses right away and you will almost certainly lose position. Feedhold needs to pause the planner and decelerate the axis in a controlled manner. If your acceleration is slowish then that will add time to the feedhold but normally I would expect the feedhold to stop in well under half a second.
Hood

[ger21]

Try No FRO in Que setting in General Config.

[Promech]

It makes no difference. I am simulating at a laptop at home (not the real system at the factory) but it behaves the same (same lag).  Try say G0x50000, feedhold, cycle start, feed hold, cycle start, etc. The system travels a considerable distance before stopping. That may not be all too important. I just observe that (with Fanucs, Sinnumeriks etc.) operators use feedhold and cyclestart frequently when they trial cutting a part for the first time and I want my Mach3 to behave the same. It does not seem to be an acceleration issue. Its the time it takes from the moment the command is issued to the moment when Mach resacts.

[ger21]

 I thought that "No FRO on Que" would get it to pause quickly. Do you have the driver installed on the laptop? In some cases, Mach3 will not act the same without the driver installed.

The reason that it normally pauses slowly is that Mach3 buffers the moves, and when you pause, the buffer has to clear.

One other thing to try is to reduce the lookahead. I think the default is 200. Try 20.

[Hood]

Mach is a buffered system where as Fanucs etc are real time so things will work a bit differently but then again the cost difference is quite considerable as well.
How long are you talking about, is it seconds or less?

For what you are doing I have found using a pot for the FRO to be a good way to do things, the first run of the code the pot can be wound down as you are approaching the stock and if things seem right you can crank it up again. Only problem with Mach and using a pot for FRO is you need to have analogue inputs, I use my PLC to get that  but the other way I know of is the PoKeys.


Hood

[Promech]

Gerry, I just simulated with the lookahead and it makes nos difference. Actually I am trying with just  1 MDI line. I will try tomorrow the system with drivers and let you know.

Hood, the FRO is a safer way of doing things, and maybe that is what operators should use instead of feed hold. There is one installed in my system and I will be testing it for this purpose.  I would say it is about a second, which at a high feed rate is considerable distance.

Jorge

[Hood]

That seems quite a long time for the parallel port, I dont have any machines using the PP now but it certainly wasnt that slow for me when I did.

I made up a brain for my FRO so it will actually feedhold if you wind it to zero and then restart if you wind back up again. Reason I did that is you can never actually set the FRO to zero in Mach at this time, hopefully Rev4 will be different as its one of the things I asked Brian for. At the moment you can slow the FRO way down to 0.1% I think but that means its still creeping along and can catch you out. With the Brain it actually feedholds so you can be sure it is actually stopped. The only drawback is the auto start with winding the pot up requires a fairly slow initial wind of the pot as if wound too fast it will not see the conditions for the restart, however you soon get used to it and once restarted you can wind the pot as fast as you like the remaining way.
Hood