Hello!

This is a topic discussed earlier too but I still have the problem that processing M03 M05 commands in Mach3 takes too much time ie. ca 150 ms each.
If you use DoSpin commands inside your M's the time is ca 300 ms and it's not constant delay either. I'm using direct output commands in M-commands - a bit faster.

Any news of this?

BR. Arto

I don't mean this is a "clever" sort of way, but what difference does it make. Yes I suppose 150ms is a long time in computer terms, and 300ms certainly is, but if it is turning on a motor, which takes seconds to get to full speed, then the time delay dissapears, particularly when there will be some other electronics, e.g a digispeed and inverter in the line.

In answer to your question, and it might be the answer -

M3,M4 and M5 commands are, by their nature, not time dependent in the same way that say, pulses on an axis are, and therefore, might have to "step aside" in the scheme of things, so that more time important things get in the right place.

Have you tried to see what time delays are present on the other outputs - say the coolant. Is the delay a product of the fact that, although one socket, the top four output lines are, actually, a different address to the bottom eight.

I you are using a serial out, such as smooth stepper, then again there will be a preference order that each signal must take.

I have, yesterday, been doing a Macro to bore oout some gears. I did a 'code"M3"' but the macro just ignored it to all intents and purposes (becasue I had a previous "wait til key pressed" instruction before it. It seems that the code is written in any case, and when the key is pressed it just shoots through the instructions.

I ended up writing a plain old Gcode routine


 

Yes. I know. This is not an issue for everybody. If you control a relay- which commands a contactor - which starts a Y/D starter - which starts a 40 kW spindle...

However I need to contrl a laser that can be modulated up to ca. 100 kHz. With Mach I can't dream about modulation when even the swithing on and off is slow.

I'm now calculating a application where one part has 122 holes. Piercing time can be zero. Now I loose 122x0,3s=37 s/piece where cutting time is 181s. This is 20% more time than with a competitive controller. Next year 17 000 pcs should be made. 174 hours more production time needed because of this delay. A bit less than 10% of the yearly daytime working time.

Please try a simple program:

M03
M05
M03
M05
M03
M05
M03
M05
M03
M05
M03
M05
M03
M05
M03
M05
M03
M05
M03
M05

How much time it took? 3 s ?

BR. Arto

What revision of Mach are you using. Art had found this problem and was  think supposed to be sorting it. Whether its been done I am not sure.
Hood

Yes - I see - said the blind man.

If there is a problem with M3, why not, instead of using DoSpin, just turn on one of the outputs - using "Activate()" and "Deactivate()" -  it has the same effect and can be configured in exactly the same way - has this a delay as well???

The information, together with pin numbers, codes etc are all in the Wiki accessed via the "support" tab above.

I'm not saying this is the answer, since the delay may be the same, but if it is just to switch on an output, I can't see what delay would be involved.

Yes. Activate and DeActivate is taking ca. 150 ms to process and DoSpin ca. 300 ms. This is what I meant with direct output. I have tested this with several output lines and the same problem exists. I've got also the proposal to use one direction pin to control the shutter but as I'm mainly using DSPmc/IP there's no such in use.

And yes - Mach with parallel ports takes as much time as Mach with DSPmc does.  No difference. Delay must come from 'kernel' processes.

The Mach version I'm using is 3.041

BR. Arto

I would suggest you backup your config and try the latest Dev version, it may be fixed in that as a lot of work has been going on and a lot of the major problems from the past have been sorted.
Hood

Hi, Arto

As Hood suggested, Try Dev version 3.042.015,

It doesn't hang M3 and M5 for me as it did in previous versions.

Also turning off the Tool-Path View helps

Chip

OK. I tested the dev version today.

M3
M5
..
...pair repeated 20 times took 5 seconds if Activate/DeActivate commands used (new installation overwrites changes to M3 and M5 macros) and twice longer with DoSpin's.

Ie. one output change takes 125 ms. This is also exactly the same if I have toolpath on or off. I'm still not very happy with this and I can't see much progress.

I'm planning my next machine and yesterday I spent some time to evaluate EMC2. A lot of extra work if I need to go for it.

OK. I tested the dev version today.

M3
M5
..
...pair repeated 20 times took 5 seconds if Activate/DeActivate commands used (new installation overwrites changes to M3 and M5 macros) and twice longer with DoSpin's.

Ie. one output change takes 125 ms. This is also exactly the same if I have toolpath on or off. I'm still not very happy with this and I can't see much progress.

I'm planning my next machine and yesterday I spent some time to evaluate EMC2. A lot of extra work if I need to go for it.

I too have the dspmc board and I am very happy with it, but I am driving a mill so I ma not having the same problem that you are.
I was just thinking, what if you used one of the analog outputs,  and use a circuit to turn on with a positive voltage and off with negative voltage, wouldn't it respond as fast as an axis would? I would assume it would be faster than what you are getting know. Even if you had to use a small motor with an encoder on it just mounted somewhere so the axis could have encoder feed back. You could program a short move at G00 say .0001 if you really needed a short pulse duration. if you needed very fast output, just setup the electronic board to be on with either negative or positive voltage, this way any movement of the axis would trigger the laser.
Your programing might get a little silly, but with some cut and past it would work.
You could possibly program it to be on and off based on how far you send the axis or using a feed rate.
At least until Rufi gets the stepper outputs worked out.

The other option would to be to program a brain to turn an output on and off depending on which way you were sending the axis in question, but I am not sure if it would be fast enough.


Hope this helps, Mike