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 

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 

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.