In many macros I see that there is a 1/4 second pause added after a DRO is updated by the code.  Is this necessary? Also, if the code has the axis moving, such as during a G31 probe move, is a pause needed before reading the DRO or does the DRO closely track the progress of the move. I guess I am asking if pauses are necessray and if so when are they needed...after the code updates a DRO, before a DRO is read after a move, or both?

Thanks,
Kent

I never understood the "Pause for DRO to update" line and why it is necessary. Can someone please explain this? Is this an inherent "bug" in Mach3 - that any function to read a DRO must be preceded by a short pause in order to get reliable data?

I suspect this has to do with the 10Hz update rate of Mach, if you call for a DRO to be updated in a macro it may be called and the macro moves on before the DRO has a chance to update. Putting a dwell in gives it that time to update and all is well.
 Rev 4 should be a lot better in this respect as the update rate will be faster, probably 50Hz or more, and also if I recall I think Brian is writing it into Mach that any DRO update calls or code moves etc in a macro will automatically be taken care of before the macro can move on. But as said I am not 100% sure on that.

Hood

An old tool height probe routine was my foray into the world of macros; it was then that I noticed this pause "trick". If it weren't for that, I would have never thought that reading from a DRO is just that... reading from a DRO and whatever value it currently displays. I would have assumed, as it would be normal in a well-designed system  , that - say - GetDRO (0) would return precisely the current X position.

A bump from 10Hz to 50Hz or even more doesn't really solve the problem, the only solid implementation would be for a GetDRO() function to return the actual value "behind" the DRO. Whatever is physically displayed on the monitor should be handled by a separate process that can draw the pixels as slow as it wants... twice a day, for all I care.

This subject has been discussed in great detail, both here and on the zone, with regard to tool position setting and probing.

My understanding of this is basically that the timing of a running macro and Mach itself are asynchronous therefore it is quite possible for a  macro to write to a DRO then read from that same DRO an incorrect value unless some form of synchronization is introduced. The command 'While isMoving()....Wend'  does just this and effectively causes the macro to wait for a 'handshake' from Mach to tell it that the last task has been completed and that it is now safe to proceed.

Tweakie.

Kently - As Tweaki has said it's all down to the fact that Mach and macros execute in two distinct asynchronous threads. It's nothing to do with screen reading - nor is it a bug or poor design. Pausing should really be termed synching. IsMoving is synching, Sleep is pausing. Some argue it's good to put a sleep in the middle of an IsMoving loop, some that a sleep on it's own will do. I'd certainly disagree with the latter.

That said - I sometimes think synching is used unneccessarily - kind of - not sure if I need it so what the .... I'll put one in. I'm sure someone will correct me if I'm wrong but I think I'm right in saying there is no need nor point in synching before or after a read. There IS however very good reason for synching after a write. One caveat to this is if you do nothing in your later code that depends in any way on the written value, you needn't even synch after a write.

Ian

EDIT: There is some wisdom in delaying the synch after a write until immediately prior to a read (of the thing you wrote to). Then, the synch may return immediately, i.e. the time you would have waited has been occupied by the intervening code. This is not so much synching before a read but delaying for as long as possible a synch after a write.