Hello Guest it is March 29, 2024, 09:42:43 AM

Author Topic: losing probe signals with USB game controller?  (Read 20014 times)

0 Members and 1 Guest are viewing this topic.

Offline Tweakie.CNC

*
  • *
  •  9,196 9,196
  • Super Kitty
    • View Profile
Re: losing probe signals with USB game controller?
« Reply #20 on: February 07, 2010, 03:21:09 AM »
I think Ray has already summed up the situation but this is my interpretation of the chain of events……

There are basically two programs running here at the same time and the speed at which they each execute is not always the same. Mach has many tasks to execute at the same time (screen refresh, keyboard poll, port monitor, etc. etc.) whilst being asked to update a DRO and will be considerably slower to respond or complete the task than the auto tool zero macro. Therefore it is possible for a macro to write a new value to a DRO and then read from this DRO the old value because Mach has not had time to update it fully. The ‘while / wend’ controls the speed at which the macro executes and has little, if any, effect on the speed at which Mach executes whereas the ‘G4’ dwell controls the speed at which Mach executes but has little, if any, effect on the speed at which the macro executes.

Tweakie.
PEACE

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: losing probe signals with USB game controller?
« Reply #21 on: February 07, 2010, 04:11:20 AM »
This is why I provided the link in my earlier post. It's all discussed and explained there. I'll reproduce a little here. Tweakie is on the right lines but in detail: while isMoving() wend actually causes the VB thread to WAIT for the mach thread to SIGNAL the VB thread that it has finished doing the last thing it was asked by VB to do.

As I said in the linked thread, isMoving() would have perhaps been better named MachIsBusy() as it actually has nothing to do with whether anything is actually moving.

without this synchronisation of the two asynchronous threads (Mach and VB) the DRO could be read by the VB before Mach has actually updated it.

Any VB "command" to Mach should be seen as a REQUEST: as in "can you do this as soon as possible?" - NOT a COMMAND as in "do it now". Any VB that continues without waiting for Mach to say "OK - I've done it" is unreliable.

Ian
Re: losing probe signals with USB game controller?
« Reply #22 on: February 07, 2010, 11:06:58 AM »
Thanks to both of you for your patience, I think I have a better understanding.  I guess you just have to be very careful when writing VB scripts.  I did look at the earlier reference to your thread, Ian, but I guess I gave up too soon, sorry - my bad.  I will make the recommended changes. 

It sure makes me wonder how many other sync problems are lurking.

Too bad there isn't a way to keep a single place for updated/corrected scripts and other add-ons, so that folks don't download the same troubles over and over.  At least, if there is, I wish it were more obvious!

Thanks again for your help.
Re: losing probe signals with USB game controller?
« Reply #23 on: February 07, 2010, 12:49:51 PM »
The UI in Mach is only updated periodically - roughly 10X/second.  When you "write" a DRO, the DRO itself does not get updated immediately.  Instead, the request to write the DRO goes into a queue of things to do on the next UI update.  So, if you write a DRO, then immediately read it back, you stand a good chance of reading the old value, rather than the new one.  Putting a Sleep(200) between the write and read should also guarantee a UI update has occurred.

All of this will me MUCH simpler and more deterministic in v4, and scripts will very rarely need to include explicit delays to get the expected behavior.

Regards,
Ray L.
Regards,
Ray L.

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: losing probe signals with USB game controller?
« Reply #24 on: February 07, 2010, 01:48:11 PM »
Putting a Sleep(200) between the write and read should also guarantee a UI update has occurred.

This is misleading, and doesn't GUARANTEE anything. isMoving() tests a semaphore and while isMoving() wend repeatedly tests the semaphore. It is only when Mach sets this semaphore and VB reads that fact that it is "safe" to continue. A sleep(X) on its own is at best a "guess" and within the while isMoving() wend loop only serves to takes a little load off the CPU. The ONLY way to GUARANTEE synchronisation of asynchronous threads is via semaphores and the only way of reading this particular semaphore is via isMoving().

Cheers

Ian
Re: losing probe signals with USB game controller?
« Reply #25 on: February 07, 2010, 02:00:27 PM »
Other than potentially unnecessary delays in the scripts, do you know of any other impact V4 will have on scripts or addons?

Also, any idea about the target date for when v4 will be available?
Re: losing probe signals with USB game controller?
« Reply #26 on: February 07, 2010, 02:21:34 PM »
Putting a Sleep(200) between the write and read should also guarantee a UI update has occurred.

This is misleading, and doesn't GUARANTEE anything. isMoving() tests a semaphore and while isMoving() wend repeatedly tests the semaphore. It is only when Mach sets this semaphore and VB reads that fact that it is "safe" to continue. A sleep(X) on its own is at best a "guess" and within the while isMoving() wend loop only serves to takes a little load off the CPU. The ONLY way to GUARANTEE synchronisation of asynchronous threads is via semaphores and the only way of reading this particular semaphore is via isMoving().

Cheers

Ian

Ian,

Could well be you know something I don't, but neither Art nor Brian has ever indicated to me that IsMoving() is a *guarantee* of a UI update.  In fact, on occasion, Brian has suggested using a delay.  Certainly, if the machine is idle, a delay of 2X the update rate *should* guarantee an update has occurred, as UI updates are regular, timed events, unless the machine is too busy running a program.  But, as I said, v4 will be FAR better in this respect.  It is a little ridiculous for user to have to worry about this kind of stuff.

Regards,
Ray L.
Regards,
Ray L.
Re: losing probe signals with USB game controller?
« Reply #27 on: February 07, 2010, 02:26:08 PM »
Other than potentially unnecessary delays in the scripts, do you know of any other impact V4 will have on scripts or addons?

Also, any idea about the target date for when v4 will be available?

v4 scripts will be almost completely different - almost nothing will carry over, unless you run in "legacy mode", in which case you will not get any of the benefits of all the v4 changes.  The v4 scripting environment will be a HUGE improvement over v3 - simpler, more consistent and predictable, but with greatly expanded functionality.  It will be much easier to learn, MUCH easier to use, and capable of doing many things v3 simply can't.

Regards,
Ray L.
Regards,
Ray L.
Re: losing probe signals with USB game controller?
« Reply #28 on: February 07, 2010, 03:13:45 PM »
delete
« Last Edit: February 07, 2010, 03:15:22 PM by woffler »

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: losing probe signals with USB game controller?
« Reply #29 on: February 08, 2010, 09:02:06 AM »
Could well be you know something I don't, but neither Art nor Brian has ever indicated to me that IsMoving() is a *guarantee* of a UI update.  In fact, on occasion, Brian has suggested using a delay.  Certainly, if the machine is idle, a delay of 2X the update rate *should* guarantee an update has occurred, as UI updates are regular, timed events, unless the machine is too busy running a program.  But, as I said, v4 will be FAR better in this respect.  It is a little ridiculous for user to have to worry about this kind of stuff.

Ray

I wouldn't presume to think such a thing and I'd absolutely agree with what you say Art & Brian have said and I don't think I've said anything to the contrary. In an ideal world of course it would be nice if the semaphore was accompanied by the called thread's success or error status but we can't have everything.

I think you'd agree that mult-threading is not unique to Mach and I've based what I've said on the assumption that Mach implements it in much the same way as any other multi-threading application - if not then I'd be intrigued to know how and why.

Certainly if a called thread is expected to complete after a particular time, then a wait by the calling thread for some period longer than that *should* give expected results. But when a semaphore is available, I would suggest that it is better practice to use it.

The only reason I can think of where a wait might be preferable, would be if there were some concern over the reliability of the code implementing the semaphore. Not that I'm suggesting this is the case with Mach of course.

Cheers

Ian