Machsupport Forum
Mach Discussion => VB and the development of wizards => Topic started by: FXC on May 23, 2010, 01:43:09 AM
-
I'm trying to do some precisely timed movements, in sort of a "rhythm", if you want. I placed G04 commands between G01's and gave it a run. With pauses in the range of seconds, everything seemed to work as planned. However, scaling down the time intervals to the range of tens of milliseconds, pretty much flattened out the G04 durations, making them - as far as I can tell - constant pauses. Thus my intended "rhythm" becomes "monotone".
Basically, it comes down to something like this:
A G04 P300 pauses for approx 300ms - OK
A G04 P200 pauses for approx 200ms - OK
A G04 P100 still pauses for approx 200ms
Same for A G04 P50, which also pauses for approx the same 200ms. And so on.
Even a G04 P1 which should cause a virtually imperceptible one millisecond pause, actually causes a highly perceptible stop.
I don't know how to explain this better but...
PLEASE HELP!
-
I don't think mach was design to do accurate LOW ms pauses IN "GCODE" AS a simple G4 P0 will cause a slight pause in itself. Being a buffered system it really has no realtime control of the pause. AND in the range you are trying to do it may get delayed from the basic time loop mach runs.
Are you checking this with a scope or eyeballing it(;-)
Just a thought
-
I don't think mach was design to do accurate LOW ms pauses IN "GCODE"
Can anyone confirm this?
[...] really has no realtime control of the pause. [/quite]
I'm sure this is not the case. The entire concept on which Mach is built upon is for a PC to provide [relatively] accurate pulses for motors.
Are you checking this with a scope or eyeballing it(;-)
There's really no way of checking it, but it's just obvious. You can hear it. And, as you said, even a P0 causes a slight hiccup.
Is this way of handling G04's inherent to Mach3? Can anyone suggest an alternative or a fix?
THANKS!!!
Just a thought
-
I am having exactly the same issue in timing a pause at the end of a scribed path, on my CNC table, to allow the scribe to lift from the plate before a rapid move to the next cut-path. It is either too long of a pause and leaves a divot from prolonged contact in one spot, or too short (no pause) and leaves a "leadout" looking scribed mark as it heads rapids to the next part.
Any help? Sorry to jack this thread.
-
What you may be seeing IS Mach actually processing the dwell function, it is not just a countdown timer. It also has to put a hold on the buffer queing process. A G4p0 cause the que to hold the data from filling the buffer untill the buffer is empty so it can process the dwell in real time.
BUT this exta process has an overhead . It takes times to do it.
That is my best explaination and you have to remember MACH3 is primarily a CNC machine controller not a high end process controller. The CNC part does not require the precise time function control to turn on/off the coolant or start the spindle.
Just a thought, (;-) TP
-
Sounds like a GCODE problem with the scribing, not enough retract clearance. IF you command G0 z1 to lift the scribe from the surface the machine will not process the next line of code UNTILL Z reaches the 1 position. SO if the code is correct XY cannot move until z=1. TO test ADD more retract to the move Z=2 to make sure the tip is not draging the surface for an instant due to springback.
Just a thought, (;-)TP
-
iF you want extreme time base action use the motor pulse functions to drive YOUR function THESE are extremely accurate in time slices. BUT then again they are not CREATED in real time just output in realtime.
Take for example the LASER guys to precisely control the on/off of the laser they have to use the direction pulse of an axis to control the laser. that is the only thing fast and precise enough to do the job in MACH. Otherwise the axillary controls such as spindle on/off have a slight built in dwell. And for a laser that is not fast enought for precise control
(;-) TP
-
Just a crazy plane I haven’t tried. Set up an axis that you aren’t using and command a short move.
Instead of G04---
use something like
G91
G01 C .5 F10
G90
Then adjust the distance and feed rate to get your time.
Tony
-
Sorry guys, I wasn't clear on my previous post. I'm running the scribe with a pneumatic cylinder, and controlling it with a selenoid from the #2 output.
The mechanics all work beautifully. I ran some Gcode test moves today, and I can get approx 500ms pause with a Go4 command, or no pause at all. This is exactly the same issue the original poster had, when trying to get a 100 - 300 millisecond pause.
It appears that a 500ms pause is no problem... anything less, and mach wont do it.
After reading some other threads on the same issue, it appears that a VB script marco, with a sleep command WILL do the short pauses... that a G04 command wont.
Now.... since I have no idea how to write a macro, could someone offer me a few pointers on the basics?
All I'm looking for is a macro that has a "sleep 100" line that will work, and I can modify the pause length.
thanks for the help!
Jim
-
Jim,
I think the easiest solution is as both Tony and Terry have suggested in their posts above. You can get reliable delays from a few uS upwards by using a non-existent axis in this way.
VB macro's will also have their own minimum delays so it depends on the smallest amount of delay you really need as to which is best.
Tweakie.
-
The problem is your trying to make an accurate Z motion with an air cylinder and a mechanism. I don't think that is ever going to happen.
I use a scribe BUT it is mounted on the Z slide and lowered into position when needed. THEN I have full ZXY control over it with Gcode. NO problems with timing issues trying to NOT mess up a decent engraving.
You will not get the precision timing control on your air cylinder control from a VB macro it will be as bad or worse than the G4 to control.
But if you determend to use what you have do as TWEAKIE suggested use the DIR pulse from a phantom axis to control the Solenoid. IT is extremely accurate and precise in it time slices.
(;-) TP
-
Another way to insure the scribe is up before moving is to use a limit switch at the up stroke of the air cylinder wired as a probe.
Your code here to activate the solenoid
G91
G31 C2 f30 'G31 = straight probe move
While ismoving()
'Sleep 100
Wend
G90
This will wait until the switch makes and then return to the program.
-
Another way to insure the scribe is up before moving is to use a limit switch at the up stroke of the air cylinder wired as a probe.
Your code here to activate the solenoid
G91
G31 C2 f30 'G31 = straight probe move
While ismoving()
'Sleep 100
Wend
G90
This will wait until the switch makes and then return to the program.
Just checked this out. G31 only works with X, Y and Z
-
Tony,
I think you will find that G31 works with 'A' as well. ;)
Tweakie.
-
Thanks Tweakie, I was just playing with it and you are right.
Maybe Brian could add the "C" and "B". It makes for good switch sensing
-
I think the easiest solution is as both Tony and Terry have suggested in their posts above. You can get reliable delays from a few uS upwards by using a non-existent axis in this way.
True, and that's exactly what I ended up doing: used my [non-existent] A-axis, the motor of which I tuned to be the equivalent of 1 inch = 1 second.
Now, I'll disappoint everyone here and reveal the utterly useless (but fun) purpose of this whole endeavor (turn your speakers on): http://www.youtube.com/watch?v=Fq4VLwLFXaE&t=11s
-
Nice one, a Nintendo CNC machine. ;D ;D
Tweakie.