Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Kently on October 05, 2009, 11:34:16 PM
-
Here is a script of code that raises the question of when to use G4 versus sleep.
This code works:
Code "G90" ' Set absolute mode
DoOEMButton (180) ' Set work coordinate mode on
Sleep 100
New_Z = GetDRO(2) + 0.2
Code "G0 Z" & New_Z
This code does not work regardless of the specified dwell time:
Code "G90"
DoOEMButton (180)
Code "G4 P0.1"
New_Z = GetDRO(2) + 0.2
Code "G0 Z" & New_Z
I have seen the dwell command (Code "G4 P0.1") used many times to delay movement of an axis immediately after a DRO is changed by code. Should the dwell command (G4) be used or should an equivalent sleep command be used? I am running a SmoothStepper which may be complicating this.
-
Is the time units for G4 set to milliseconds?
Cheers,
peter
-
Yes it is milliseconds. Note that the sleep 100 command worked. The dwell command did not work regardless of how long I made the dwell time. If I inserted a break in the code and stopped between the mode changes and the move, everything worked fine as well.
If the dwell code did not work for this example, I doubt it is really doing anything when inserted between a DRO change and an axis move. The macros that I have seen that use the dwell coomand have a comment that says "pause for the DRO to update." I am wondering if the dwell is even needed or if I shoul be using sleep instead of dwell for those instances as well.
-
Since it is milliseconds, have you tried
Code "G4 P100"
Cheers,
Peter?
-
YES
-
Did you put a
While IsMoving()
Wend
after the G4?
Hood
-
Hood..I am so glad you jumped in on this.
Actually that is how I first fixed the problem. I added:
While IsMoving()
Wend
After I issued:
Code "G90"
DoOEMButton (180)
That fixed the problem and led to the begining of my confusion. Nothing should be moving due to the G90 and OEM Buttom (180) commands, but yet the While IsMoving loop fixed the problem. It seems the G4 P command is not effective at doing what I think it should be doing. I am tempted to replace all G4 P commands with the equivalent Sleep delay. I having been digging through this forum for a while and cannot figure out when the G4 P (dwell) command should be used versus the sleep command. I am also reading that sleep is no longer neede in the While IsMoving(), Wend loop.
I will greatly appreciate your insight on this.
Kent
-
I would use Sleep**** mostly just because all it needs is one line ;D
I could be talking bull$hit here but Sleep if I recall never worked properly a while back so often the only option was to use the G4, now however Brian has the Sleep working very well :)
Soon you will no longer even need a
While IsMoving()
Wend
after any Code("**") as Brian is also doing away with the need for that and in the test version I have tried it works very well :)
Hood
-
Mach and VB exist in two distinct asynchronous threads. VB (the client) issues requests to Mach (the server). G4 runs in the Mach thread, sleep runs in the VB thread. Requests are not neccessarily run by Mach in the order they are sent by VB. Mach decides on the priority of the request i.e. in which order all the currently queued requests will be run. gcode is higher priority than updating the display.
isMoving() is arguably mis-named - it doesn't neccessarily have anything to do with axis movement, it might have been better if it were called "MachIsBusy()"
Hope this helps
Ian
-
Mach and VB exist in two distinct asynchronous threads. VB (the client) issues requests to Mach (the server). G4 runs in the Mach thread, sleep runs in the VB thread. Requests are not neccessarily run by Mach in the order they are sent by VB. Mach decides on the priority of the request i.e. in which order all the currently queued requests will be run. gcode is higher priority than updating the display.
isMoving() is arguably mis-named - it doesn't neccessarily have anything to do with axis movement, it might have been better if it were called "MachIsBusy()"
Hope this helps
Ian
Yes, this helps very much! I was wondering if the IsMoving was really more than an indication of an axis moving. So I am still not sure when to use sleep versus G4, but I think I have come to one conclusion. Whenever you make a change to Mach, such as changing a DRO, the coordinate system, etc AND you have subsequent code that relies on those changes to be made, you should always add a While Is Moving loop after those changes to make sure Mach has completed them. Is this correct?
Thanks,
Kent
-
but I think I have come to one conclusion. Whenever you make a change to Mach, such as changing a DRO, the coordinate system, etc AND you have subsequent code that relies on those changes to be made, you should always add a While Is Moving loop after those changes to make sure Mach has completed them. Is this correct?
Thanks,
Kent
Yes, for the time being but as I said above it will soon not be needed. It will however be backward compatible so it wont require macros to be changed if you don't want to.
Hood
-
As Hood says, yes.
A while isMoving will wait until Mach signals VB it can continue, wheras a sleep is VB guessing how long it should wait. A while isMoving with a sleep is a wait until Mach signals with a well mannered nod to the OS that it can ignore the VB thread for a while and save those precious CPU cycles. However of course Mach might signal whilst VB is asleep which wastes precious micro-seconds - its all horses for courses.
Bottom line is... In any asynchronous multi-thread programming setup, there are usually times when you need to synchronise. i.e. wait for the server to be at a known point before continuing with the client.
Waiting on semaphores (the fancy/geek term for all this malarky) is an integral part of multithread comms so at the moment I can't figure out how this can be done away with but Brian clearly has some devious scheme up his sleeve ;D
Again hope this helps
Ian
-
Here is a script of code that raises the question of when to use G4 versus sleep.
This code works:
Code "G90" ' Set absolute mode
DoOEMButton (180) ' Set work coordinate mode on
Sleep 100
New_Z = GetDRO(2) + 0.2
Code "G0 Z" & New_Z
This code does not work regardless of the specified dwell time:
Code "G90"
DoOEMButton (180)
Code "G4 P0.1"
New_Z = GetDRO(2) + 0.2
Code "G0 Z" & New_Z
I have seen the dwell command (Code "G4 P0.1") used many times to delay movement of an axis immediately after a DRO is changed by code. Should the dwell command (G4) be used or should an equivalent sleep command be used? I am running a SmoothStepper which may be complicating this.
The "Code" function does *not* complete execution of the G-code before returning, so doing a Code "G4 Px" will return immediately, regardless of the dwell time given by the P argument. The dwell *will* execute correctly between successive lines of G-code. So, for example:
Code "G0 X0 Y0"
Code "G4 P1000"
Code "G0 X1"
will correctly insert a one second delay between the two rapid moves. If you want VB to dwell, you must use Sleep.
Regards,
Ray L.
-
I nkow this sounds like I am asking the same queston, but it is a little different. The zero touch plate probing routine I was modifyig was originally written by someone else. In that code, anytime a DRO was changed they added G4 P0.5 with a comment that said "pause for the DRO to update." Based on the feedback from this thread, I don't think the G4 command was the appropriate one to use, but rather a sleep command should have been used to pause on the VB side. However, rather than have a fixed pause, I'd like to add this code after a DRO is updated:
While IsMoving ()
sleep 10
Wend
My question is: does "IsMoving" apply to a DRO update? If so, I would think I could add the While IsMoving loop and do things fatser than having a fixed pause.
Thanks for all the help!
Kent
-
I nkow this sounds like I am asking the same queston, but it is a little different. The zero touch plate probing routine I was modifyig was originally written by someone else. In that code, anytime a DRO was changed they added G4 P0.5 with a comment that said "pause for the DRO to update." Based on the feedback from this thread, I don't think the G4 command was the appropriate one to use, but rather a sleep command should have been used to pause on the VB side. However, rather than have a fixed pause, I'd like to add this code after a DRO is updated:
While IsMoving ()
sleep 10
Wend
My question is: does "IsMoving" apply to a DRO update? If so, I would think I could add the While IsMoving loop and do things fatser than having a fixed pause.
Thanks for all the help!
Kent
Oddly enough, that should work fine. IsMoving(), rather than indicating that an axis is moving, I believe actually indicates there are remaining commands in the G-code queue. So, IsMoving() will return 1 any time there is *any* G-code waiting to be executed. This can be confirmed by running the following as a button script, as I just did:
Message "Startin delay..."
Code "G4 P5000"
While IsMoving()
Sleep 100
Wend
Message "Delay Done"
You'll see the first message displayed for 5 seconds (more or less...), before the second message is displayed.
Regards,
Ray L.
-
does anyone ever feel they're living in a parallel universe and that maybe they don't actually exist? - I know I do ;D
-
Can you use IsMoving to see that a DRO has finished updating. I wouldn't call a SetEOMDRO command G-code, so I am wonderig if IsMoving will be a good way to detect that the DRO has finished being upadted.
-
Can you use IsMoving to see that a DRO has finished updating. I wouldn't call a SetEOMDRO command G-code, so I am wonderig if IsMoving will be a good way to detect that the DRO has finished being upadted.
No. The DROs update when Mach does its ~10X/second update loop. There is no way to "wait" for that other than with a Sleep. In Mach3 v4, most of these issues, and many others, will be handled in a FAR more deterministic and regular manner, and it will rarely be necessary to add delays or While loops to your VB code.
Regards,
Ray L.
-
OK..hopefuly I am about finished asking questions on this. The original code had a G4 P0.5 command after any DRO update. Given all I have learned from that thread, it sounds like that command could not be doing as intended. But then again, I am not sure what the problem was that casued the need for this to be added. Perhaps this is code developed long ago that no longer applies. It sounds like I should actually use a Sleep 100 (or perhaps add some, say Sleep 120) to make ure that Mach has made it through its 100 msec loop). Do people normaly add a sleep command after any DRO update?
CAN'T WAIT FOR VERSION 4...just hope it plays well with a SmootStepper!
-
OK..hopefuly I am about finished asking questions on this. The original code had a G4 P0.5 command after any DRO update. Given all I have learned from that thread, it sounds like that command could not be doing as intended. But then again, I am not sure what the problem was that casued the need for this to be added. Perhaps this is code developed long ago that no longer applies. It sounds like I should actually use a Sleep 100 (or perhaps add some, say Sleep 120) to make ure that Mach has made it through its 100 msec loop). Do people normaly add a sleep command after any DRO update?
CAN'T WAIT FOR VERSION 4...just hope it plays well with a SmootStepper!
You only need to put a delay after a DRO access if you're reading the DRO, and want the modified value. For example, if you do this:
Code "G0 X0"
SetDRO(123, 456)
Code "G1 X1"
X = GetSRO(123)
You should be fine. But, if you do:
Code "G0 X0"
SetDRO(123, 456)
X = GetSRO(123)
You will likely find X gets set to the old value of the DRO, unless you insert the delay. This is something I've never understood, but I've seen it enough times to just be careful.
Regards,
Ray L.