Hello Guest it is March 28, 2024, 01:29:42 PM

Author Topic: G4 versus Sleep  (Read 11998 times)

0 Members and 1 Guest are viewing this topic.

G4 versus Sleep
« 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.
Re: G4 versus Sleep
« Reply #1 on: October 05, 2009, 11:37:55 PM »
Is the time units for G4 set to milliseconds?

Cheers,

peter
----------------------------------------------------
Homann Designs
http://www.homanndesigns.com
email: peter at homanndesigns.com
Re: G4 versus Sleep
« Reply #2 on: October 05, 2009, 11:46:55 PM »
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.
Re: G4 versus Sleep
« Reply #3 on: October 06, 2009, 01:15:19 AM »
Since it is milliseconds, have you tried

Code "G4 P100"

Cheers,

Peter?
----------------------------------------------------
Homann Designs
http://www.homanndesigns.com
email: peter at homanndesigns.com
Re: G4 versus Sleep
« Reply #4 on: October 06, 2009, 09:15:35 AM »
YES

Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Re: G4 versus Sleep
« Reply #5 on: October 06, 2009, 09:46:20 AM »
Did you put a

While IsMoving()
Wend

after the G4?

Hood
Re: G4 versus Sleep
« Reply #6 on: October 06, 2009, 09:56:17 AM »
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

Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Re: G4 versus Sleep
« Reply #7 on: October 06, 2009, 10:05:50 AM »
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

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: G4 versus Sleep
« Reply #8 on: October 06, 2009, 10:15:44 AM »
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
Re: G4 versus Sleep
« Reply #9 on: October 06, 2009, 10:25:46 AM »
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