Messages

1161

Mach4 General Discussion / Re: Pressing Stop button during move loses position

« on: May 16, 2021, 11:12:56 PM »

Hi,

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.

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.

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

1162

Mach4 General Discussion / Re: Pressing Stop button during move loses position

« 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

1163

Mach4 General Discussion / Re: Can you read if G68 is active from the API?

« on: May 15, 2021, 05:20:04 AM »

Hi,
I suspect it is possible:

Code: [Select]

ROTATION X 2135
ROTATION Y 2136
ROTATION 2137
and:

Code: [Select]

MOD GROUP 12 4012 // Group 12 // modal macro (G66,G66.1,G67)
MOD GROUP 13 4013 // Group 13 // spindle mode
MOD GROUP 14 4014 // Group 14 // coordinate systems
MOD GROUP 15 4015 // Group 15 // exact path or cutting mode
MOD GROUP 16 4016 // Group 16 // coordinate system rotation mode
MOD GROUP 17 4017 // Group 17 // polar mode

These are from the Pound Variables listing in:

https://www.machsupport.com/forum/index.php?topic=40051.0

Craig

1164

Mach4 General Discussion / Re: Hazardous Motion - Mach4 Software

« on: May 13, 2021, 05:56:44 PM »

Hi,

You are talking about *incremental* jog mode.  In that version, you are repeatedly increasing the location of the destination, faster than the MPG commanded motion is being output to the motors.  Nothing is being buffered up in Mach4 when you spin the MPG wheel fast, but Mach4 realizes that the endpoint is still, for example, 3 inches away, and Mach4 will fulfill the command to travel that entire distance, even if it takes a few more seconds or minutes. Mach4 will keep telling the ESS how far to move for each time slice, until the commanded position is reached - Mach4 is doing exactly what it was commanded to do.

My apologies, yes I am indeed talking about incremental movement, and your description is exactly as I observe on my machine.

When in 'continuous' mode the motion ceases very shortly after button release. My ESS is set to default buffering, ie 180ms, and I would guess that is the delay I
observe.

To be honest I don't really use continuous mode very often, but rather incremental mode.

When using Machs on-screen buttons incremental mode causes one jog unit of movement, effectively single stepping. This is not convenient if you wish to traverse a distance
to work zero for instance. With an MPG however spinning the handwheel results in a stream of 'single steps' which is highly convenient for rapid traverse AND also for fine
and slow speed single stepping when touching off.

In my opinion an MPG used in  incremental mode represent the most versatile, usefully safe means of manual control for both rapid  traverse and touch off.

Craig

1165

Mach4 General Discussion / Re: Hazardous Motion - Mach4 Software

« on: May 13, 2021, 04:32:42 PM »

Hi,

As soon as you let your finger off of the button in a continuous jog at full speed, the next time slice we pull from Mach4 should start showing the deceleration.  It will take the 0.15 seconds (or whatever you have it ESS motion buffer size set to) for that deceleration to work through the ESS's motion buffer.

That is not correct, I can with the jog increment set to 1mm cause the MPG to buffer up moves that carry on motion for several SECONDS after the MPG has
stopped moving. The same can be done with the on-screen jog buttons.

If the movement were restricted to the length of the ESS motion buffer that thread would not exist, there would be no need.....but the motion can persist for SECONDS

Craig

1166

General Mach Discussion / Re: Mach 3: Programmatic change to config

« on: May 13, 2021, 04:25:41 PM »

Hi,
using Mach4 its possible to use either analogue velocity mode OR Step/Direction mode at will.

I can do both, but in truth VERY seldom use Step/Direction, as a free running spindle (analogue velocity) is enough
for my purposes, and analogue velocity mode is SO EASY to use.

I would suggest that unless there is specific reason to employ a more complicated solution then just use plain old PWM
output with the servo in velocity mode, its so simple!

Craig

1167

General Mach Discussion / Re: Mach 3: Programmatic change to config

« on: May 12, 2021, 06:58:14 PM »

Hi,

This is a Chinese Servo. They seems decent enough for my application.

I don't think there is to much issue with these Chinese servos, they seem to operate as they should and while not top quality they are not
rubbish either, entirely suitable for our purposes.

Where I do take issue with these Chinese products is the Chinglish documentation and even more damningly NO  PC based set-up and tuning software.

My advice to users new to servos would be to get a slightly more expensive but better brand like Delta or DMM which have vastly superior
documentation, support and set-up software. Once you learnt how to get the best from that thereafter you'll have no trouble transferring what
you have learnt to the cheaper brands, almost all AC servos are very similar to each other, if you can 'drive' one you can 'drive' others.

Craig

1168

General Mach Discussion / Re: Mach 3: Programmatic change to config

« on: May 12, 2021, 06:50:34 PM »

Hi,

Would you mind to post the 2 macros that you use?

My macros are no good to you because they are written in Lua for Mach4.

They are simple though, one macro asserts an output high, and the other de-asserts that output.

Craig

1169

Mach4 General Discussion / Re: Hazardous Motion - Mach4 Software

« on: May 12, 2021, 06:47:23 PM »

Hi,

I've got the jog steps at 0.001", so I'm not sure how small they have to be.  It is frustrating that I cannot repeat the incident on demand to test various parameter changes.

The issue occurs when the product of the jog step rate and the jog increment equal or exceed the max machine velocity. You can use the jog rate slider to
reduce the jog step rate and/or set even lower jog increments. The problem with using very small jog increments is that when you want to touch off in incremental mode
you effectively have to cycle through your programmed jog steps to find a more suitable number.


It won't hurt to try 0.001, 0.0001,0.000001.......it will tell you pretty simply whether you are on the right track.

Do you know if there is a command that will flush the buffer to prevent "after-run"?

No I don't, and I don't believe there is such a command, and even if there were you would be using it to counteract a poorly chosen setting by you.
Establish the 'sweet spot' jog increment and progress from there.

I do rather suspect that you can change the jog step rate within Mach and that I think will be your long term fix....but you can establish the limits
and the nature of the problem by using the slider and/or jog increments.

Craig

1170

General Mach Discussion / Re: Mach 3: Programmatic change to config

« on: May 12, 2021, 04:48:20 PM »

Hi,
You may have to do a hardware swap, rather like the probe problem. Whether that is required is determined by the control
modes offered by the servo rather than any limitation in Mcah3.


Most of the time my AC servo runs as in velocity mode with a 0-10V PWM input, easy. My Allen Bradley servo has dual mode,
so by asserting one digital input to the drive it changes from analogue velocity mode to step/direction position mode.
Thus when I want to do a C-axis  move during a job I call a macro that asserts the change-over pin, then write Gcode
of the form:

G1 C3600 Z-10

which results in the Caxis (spindle) doing 10 revolutions while the Z axis descends 10mm for a 1mm pitch helical interpolation move.

Once the Caxis move is complete I can run another macro to de-assert the changeover pin and the spindle goes back to analogue velocity
mode with PWM input. This all happens without any intervention on my part while running the Gcode program.

Note that this dual-mode option is pretty much standard across all modern AC servos. My new Delta B2 series servos for my new build have that feature
as well. I imagine your spindle servo will have the same feature, although I have not read the manual closely enough to be sure.

If your spindle servo has that feature you can swap between the two modes WITHOUT having to switch any wiring. If it does not have that feature
then you will have to do some sort of hardware switch.

Craig