Machsupport Forum

Mach Discussion => General Mach Discussion => Topic started by: alfaalfa on October 17, 2008, 04:40:57 AM

Title: M-command speed and delays
Post by: alfaalfa on October 17, 2008, 04:40:57 AM
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
Title: Re: M-command speed and delays
Post by: jimpinder on October 17, 2008, 05:04:25 AM
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 ;D ;D


 
Title: Re: M-command speed and delays
Post by: alfaalfa on October 17, 2008, 05:36:14 AM
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

Title: Re: M-command speed and delays
Post by: Hood on October 17, 2008, 06:17:59 AM
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
Title: Re: M-command speed and delays
Post by: jimpinder on October 17, 2008, 08:38:11 AM
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.
Title: Re: M-command speed and delays
Post by: alfaalfa on October 17, 2008, 10:30:58 AM
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

Title: Re: M-command speed and delays
Post by: Hood on October 17, 2008, 10:34:24 AM
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
Title: Re: M-command speed and delays
Post by: Chip on October 17, 2008, 04:01:33 PM
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
Title: Re: M-command speed and delays
Post by: alfaalfa on October 20, 2008, 06:35:33 PM
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.

Title: Re: M-command speed and delays
Post by: TOTALLYRC on October 30, 2008, 04:57:44 AM
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
Title: Re: M-command speed and delays
Post by: jimpinder on October 30, 2008, 06:54:00 AM
I was speaking to Brian Barker about this at the UK Model Exhibition. I understand that the disproportionate delay on M3 has been fixed.

If you are wanting a faster response that the activate/deactivate, then are the step and dir controls any faster - and use the A axis as a driver for the laser - using a G0 command. The difficulty would be in the time "on" since this would have to be equated to the distance the A axis supposedly moved - but it seems this could be relatively easily calculated. If the "step" pin was used (to fire a retriggerable monostable) the "distance" travelled could be gradually reduced to give the minimum "fire" time - or indeed the monostable could be hardwired to give the time directly.
Title: Re: M-command speed and delays
Post by: TOTALLYRC on October 30, 2008, 07:02:15 AM
Unfortunately the dspmc only has +-10 analog outputs. Yet.
Mike
Title: Re: M-command speed and delays
Post by: alfaalfa on October 31, 2008, 06:32:11 AM
I have spent some time thinking about this workaround. I could do it for our machine but for machines to be selled out - this would not work well because of the safety reasons.

All in all - this would be a another 'glued on' feature to Mach3.

I think the brain function would be as slow as the others in handling the outputs.

It seems the enthusiasm to develop Mach has gone?

" Perfectness - real or imaginated - is the end of development "

BR. Arto
Title: Re: M-command speed and delays
Post by: Hood on October 31, 2008, 07:14:43 AM
Are you planning to build and sell these machines?
Hood
Title: Re: M-command speed and delays
Post by: vmax549 on November 05, 2008, 10:59:07 AM
SOmewhere in mach there is a code Art put in to turn off/on without delays such as laser use. Can't remember what it is you may want to do a search.

(;-) TP
Title: Re: M-command speed and delays
Post by: alfaalfa on January 08, 2009, 05:36:08 AM
The IO delay problem still exists.

After first trials it seems EMC2 does not have this problem. It seems these real time controls are still easier to do in Linux than in Old-un-Faithfull Win.

Any news? Do I need to start re-building the whole CNC-control to suit EMC2?

BR. Arto
Title: Re: M-command speed and delays
Post by: alfaalfa on August 31, 2013, 05:16:42 PM
Answering to a question I sent long time ago. I just noticed I have not explained how the workaround was made to get rid of the Mach3 slow IO.

Finally I made a dsp-macro to the dspMC/IP board. I use axis commands G1B1 and G1B0 to trigger the dsp-macro that turns beam on/off. The same macro also gives out the real vector speed to be used in laser PWM control for corner slowdowns.