Hello Guest it is March 28, 2024, 05:41:19 PM

Author Topic: Pressing Stop button during move loses position  (Read 1701 times)

0 Members and 1 Guest are viewing this topic.

Pressing Stop button during move loses position
« on: May 15, 2021, 07:01:27 AM »
This never used to happen. However, since I updated to 4612, it's now a problem.
I think this is connected with the horrible sluggish response that we now get with Mach4 when doing anything that used to be nice and snappy. I get the impression that it's to do with a buffer being filled and emptied.
In this case, the contents of the buffer seems to be getting dumped! I've just clocked up the job again, and it lost 0.61mm in the X-axis!!!

To be honest, I'm sick of the problems that have been introduced... the Single block, the sluggish response and now lost position. It used to be a much more stable platform, and now I can't trust it.

Please don't tell me that I shouldn't hit Stop while it's running. That always worked and it's something you can do on any CNC machine. It's up to the CNC control to deal with it or disallow it, not the user.

I've ordered a KFLOP and KANALOG board from Dynamotion so I can get a machine that I can rely upon to repond correctly to the user commands. It's a pity, because Mach4 has so much promise. However, endless tinkering and messing up basic functions that worked fine for years is not acceptable.
« Last Edit: May 15, 2021, 07:06:47 AM by striplar »
Re: Pressing Stop button during move loses position
« Reply #1 on: May 16, 2021, 05:07:53 AM »
Hi,
it is, and always has been that if you press <Stop> the machine crash stops with probable lose of reference.

You should always press <FeedHold> followed by <Stop>. The <FeedHold> allows the motion buffer to drain before stopping
whereas <Stop> causes the contents of the motion buffer to be aborted.

This happens with all motion buffered CNC software solutions including Mach3, Mach4, UCCNC, PlanetCNC etc and is a
direct consequence of Windows being a non realtime computing platform which is turn requires a motion buffer.
The ESS for instance has a default motion buffer of 180ms. You can, if you have a suitably powerful, well tuned and uncluttered
PC reduce that to about 30-40ms, but it cannot be eliminated. Thus even with such a PC to press <Stop> is to abort 30ms worth of
motion commands with consequent loss of reference.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Pressing Stop button during move loses position
« Reply #2 on: May 16, 2021, 05:17:43 AM »
I have an AC Servo with encoder feedback that has no difficulty in following any stream of steps that the controller outputs. I've never had any issue with pressing the stop button because my system just follows the output.
Something new has been introduced whereby the controller doesn't output the right amount of steps during this procedure. That's a bug that's been introduced that wasn't there before.
There's absolutely nothing wrong with a controlled rapid stop, it's exactly what you want when you see something going wrong and you want it to stop without losing position. If the position control system can't cope with that, it's a problem for the control system. It's up to Mach4 to always output the true amount of steps so control can be resumed. To just dump a buffer full of outputs is just plain wrong.

I can't see how the ESS would lose counts. If Mach4 outputs a position move, the ESS surely just outputs whatever it's been told. Why would you lose anything?

Why has this been changed? it makes no sense to keep changing things that worked perfectly well before!
« Last Edit: May 16, 2021, 05:22:26 AM by striplar »
Re: Pressing Stop button during move loses position
« Reply #3 on: May 16, 2021, 11:12:56 PM »
Hi,

Quote
There's absolutely nothing wrong with a controlled rapid stop, it's exactly what you want when you see something going wrong and you want it to stop without losing position.

Correct, the operative words there are controlled stop. But Mach 3 and 4 have never done a controlled stop with the <Stop> button, a <Stop> command
causes a crash stop. <FeedHold> is the controlled stop, and always has been.

Quote
I can't see how the ESS would lose counts. If Mach4 outputs a position move, the ESS surely just outputs whatever it's been told. Why would you lose anything?

Try this thought experiment:
1) Mach gets a G1 X300 F300 instruction (mm units)
2) Machs trajectory planner issues 1ms time slices of approx 300/60/1000=0.05mm X movement per slice, neglecting accel and deccels.
3) The time slices get queued up in the ESS, typically 150 slices or 150ms worth of movement.
4) The ESS generates the pulses required for the stepper or servo to advance 0.05mm and then discards the slice.
5) The ESS will process the next slice in the queue.

Note that Mach being a Windows application is not realtime, that is to say Windows will be busy doing something else and will not fill up the
buffer immediately, but that's OK, the ESS has a 150 or so to go on with. Surely Windows and Mach will be back to issue more slices long before
the buffer runs out.

6) If you now hit <Stop> the trajectory planner issues a crash stop command and all pulses from the ESS stop immediately. Any movement instructions
queued up in the buffer are lost. There might have been 140 slices of 0.05mm each in there so Mach thinks the machine is at point Y but the ESS has not
enacted those steps yet so the machine will lag 140 x 0.05=7mm behind.

This is an essential piece of understanding with any Windows CNC software, movement must be buffered so that Windows can go away and do other stuff,
and yet the motion controller has data  enough to carry on what it was doing. If the motion controller runs out of data the machine stops and cannot
simply be restarted as any new motion time slices would require infinite acceleration. You may have seen such 'Run Out Of Data' errors from
time to time, it's what happens when the ESS runs out of time slices.

If the machine is idle then all the time slices will be the same , ie no motion between slices, so if you hit <Stop> then it would not matter if slices
were discarded, the machine and Mach agree as to where the machine actually is.

Quote
Why has this been changed? it makes no sense to keep changing things that worked perfectly well before!

It hasn't changed, Mach3 was and is still like this, and Mach4 has always been that way also.

The correct way to stop the machine without loss of position is to use <FeedHold>. With that instruction whatever movement in the ESS motion
buffer is executed and THEN the machine stops, or rather enacts a whole stream of zero movement time slices. Thus once the machine stops
the ESS has executed all the time slices that the trajectory planner issued and so Mach and the machine are in agreement.

I never use <Stop>, I always use <FeedHold>, then once the machine is stopped, THEN use <Stop>.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Pressing Stop button during move loses position
« Reply #4 on: May 17, 2021, 03:14:52 AM »
Firstly, I've been stopping using the Stop button since 2008 and have never been aware of losing position, so I think you're overstating the case or is just doesn't pan out the way you describe.
Secondly, this is now VERY different, because now you lose a huge amount of steps which is definitely NOT what was happening.

Thirdly, it only stops that in the way you describe because that's the way you've designed it. I'm sure it's easy enough to keep Mach4 in step with the steps output if you were interested in doing that. The ESS could simply give a one off count back to Mach4 to tell it what steps have been output.

Personally, calling it a 'crash stop' is misleading, because it infers a loss of control. The button says Stop, that's all. A rapid stop is fine, you just have to maintain syncronism with the ESS rather than just throwing up your hands. This is all about philosophy and expectation. The user has one expectation, and you have another. I think you should do more to keep the two alighned.
Re: Pressing Stop button during move loses position
« Reply #5 on: May 17, 2021, 04:50:45 AM »
Hi,

Quote
Thirdly, it only stops that in the way you describe because that's the way you've designed it.

I designed it????
I have nothing to do with the design or development of either Mach or the ESS.

I have taken the effort to understand why Windows CNC software is necessarily buffered and the consequences of that buffering.

Quote
I'm sure it's easy enough to keep Mach4 in step with the steps output if you were interested in doing that

Well...no as it turns out, that would require that Mach would deliver movement instructions that are enacted immediately, and Windows
is not realtime so there would be gaps in the stream of instructions which would stop the machine.
LinuxCNC is a realtime sytem, or rather has Realtime Extensions, which amount to the same thing in practical terms, and thus motion
cnotrollers in LinuxCNC do not need to be buffered, perhaps you could do some research on that possibility.

Quote
Personally, calling it a 'crash stop' is misleading, because it infers a loss of control.

<Stop> and <Estop> button effectively do the same thing, they stop the machine dead still without any attempt at deceleration and often
result in loss of reference, rather than loss of control. To my knowledge <Stop> and <Estop> have behaved identically in Mach3 and Mach4
since Mach3 was invented way back when.

Whatever my expectations were, or even still have, must be tempered against the reality of what is and what is possible with Windows.
I can of course buy a genuine realtime controller like a Fanuc21i or a Siemen840D, but I don't have $20,000 to spare, I just have to make do with
what I can afford.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Pressing Stop button during move loses position
« Reply #6 on: May 17, 2021, 05:13:16 AM »
So you don't know the code then, you're just surmising from what you know about this kind of system. I can surmise from what I know, and my conclusions are different to yours.
Answering as if on behalf of Mach4 is misleading, and you should refrain from doing so if you're not intimately involved in the management of the code.

There's no realtime control needed to keep the ESS in step. All you need is for Mach4 to know what it's told the ESS to do, and the ESS needs to tell Mach4 how much of that has been done. They can both agree when the motion has stopped, and the ESS can tell Mach4 where it is. That's VERY simple to do, and Mach4 only has to make note of that for when it restarts.

Note, there's no expectation that Mach4 will be able to restart from this as if it were paused. The only expectation is that Mach4 won't have lost knowledge of where the machine is. That really isn't much to ask, and as I've explained, it isn't difficult.

Don't tell me nothing has changed, because it has. The whole way that Mach4 behaves now is sluggish compared to the version I switched from. Clearly there's now more buffering involved because it's not snappy any more.

E-Stop is not the same as Stop, because E-Stop invokes the disabling of the drives which most certainly will cause loss of position.

Let's leave it for Mach personnel to answer for themselves, rather than you guessing what they can or can't do.
Re: Pressing Stop button during move loses position
« Reply #7 on: May 17, 2021, 05:26:53 AM »
Hi,

Quote
Answering as if on behalf of Mach4 is misleading, and you should refrain from doing so if you're not intimately involved in the management of the code.

Have I ever claimed so?

Quote
There's no realtime control needed to keep the ESS in step. All you need is for Mach4 to know what it's told the ESS to do, and the ESS needs to tell Mach4 how much of that has been done. They can both agree when the motion has stopped, and the ESS can tell Mach4 where it is. That's VERY simple to do, and Mach4 only has to make note of that for when it restarts.

If it were simple why do you suppose it has not been done? You certainly seem to think its simple...so how would you go about it?

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'
Re: Pressing Stop button during move loses position
« Reply #8 on: May 17, 2021, 06:13:29 AM »
I think anyone reading your responses would conclude that you're associated with Mach and speak on their behalf.

Mach4 knows where it is at all times. Even if the planner has to be interrupted, Mach4 will still know what it has sent as a request to the ESS. Mach4 and the ESS are synchronised in as much as they both agree what commands have been sent.
Once Mach4 stops sending commands, it knows what it has sent to the ESS. The ESS knows this too. The ESS may not have output all of the Steps necessary to complete that command, but it DOES know how many it has output. Therefore it can go back to Mach4 and tell it that out of 2000 pulses that were requested, it only output 1000. Simple.

As long as the ESS can communicate back to Mach4, it's easy enough. You can't solve it in real time, but you don't need to.
Re: Pressing Stop button during move loses position
« Reply #9 on: May 17, 2021, 07:10:56 AM »
Hi,

Quote
Mach4 knows where it is at all times. Even if the planner has to be interrupted, Mach4 will still know what it has sent as a request to the ESS. Mach4 and the ESS are synchronised in as much as they both agree what commands have been sent.
Once Mach4 stops sending commands, it knows what it has sent to the ESS. The ESS knows this too. The ESS may not have output all of the Steps necessary to complete that command, but it DOES know how many it has output. Therefore it can go back to Mach4 and tell it that out of 2000 pulses that were requested, it only output 1000. Simple.

Simple indeed, all you need it access to the proprietary code of two different manufacturers and you could do it. Or you could try the solution you have
alluded to, Kflop and Kanalog, perhaps you could post what you find, and good luck with it.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'