Hi -
Within my M6 macro is the following code:

Declare Sub Sleep Lib "Kernel32" (ByVal dwMilliseconds As Long)

Sub MachWait
While IsMoving()
Sleep 100
Wend
End Sub

I call MachWait from various spots within the M6 macro when I need to wait.

I think this used to work ok (as far as I know). I wrote the macro
around verion 2.46 & have been using it since. Recently I updated to
r2.56. While running a job this eve I got multiple VB errors from mach on
the "sleep 100" line.

Sorry, I did not write down the error verbatim and now can't
remember the wording. This may have been happeing all along and
maybe I didn't notice... the error dialog box does not come to the
front - so the error dialog lurks behind mach and I don't see it
when it happens... I only noticed this eve as I saw an extra task in
the task bar and found the dialog box.

I thought the sleep call was good form to keep from locking up the
CPU in the wait loop... is there a problem to find here or should I
just delete the sleep 100 call?

Dave

I'm having the same problem.

I get a type mismatch error on my sleep commands after upgrading Mach3 versions.

Is there a new syntax for the sleep command?  A snipet of my code is below.

Declare Sub Sleep Lib "Kernal32" (ByVal dwMilliseconds As Long)
.
.
.
DoOEMButton (1002)
DoButton (24)
While IsMoving()
Sleep 100
Wend
RunFile
.
.
.

Please help... my script is now broken unless I take out the sleep commands.  Unfortunately, too much processor resources get used up if I do that.

Thanks in advance,

JJ

Nevermind... I simply deleted the Declare Sub Sleep line and the sleep commands are working well and processor use is at correct levels.

JJ

From my experience of writing multi-threaded applications, the while isMoving() construct is polling a semaphore in the Mach thread. By sleeping for 100ms you're simply slowing down the VB thread's response to the change of that semaphore.

Without it, the test by isMoving() will pick up the change of the semaphore as quickly as the VB thread possibly can. But with it, on average the change in semaphore will be picked up 50ms later than it could otherwise have been.

Personally I'd think that this will actually waste more resources than it could possibly save.

Just my opinion.

Hi Stirling,

Thanks for your input, but there was definitely an increase in processor usage without the sleep commands.

Processor usage w/o sleep commands is at a constant 62%.... after adding the sleep commands processor usage is below 5%.

Thanks,

JJ

Art "Embedded" the VB call  "Sleep" (to replace the full dec line, so that a use neede to put in sleep only), some where around the 3's.

Scott

Hi Stirling,

Thanks for your input, but there was definitely an increase in processor usage without the sleep commands.

Processor usage w/o sleep commands is at a constant 62%.... after adding the sleep commands processor usage is below 5%.

Thanks,

JJ

Hi JJ - Sorry - I havn't made my point very well. Obviously with a call to sleep you're going to see CPU usage falling but my point is - is that useful? and what are the downsides overall?

Let me try it another way. IF the CPU was whiting out then the possibility would exist that the Mach thread was being starved of CPU. In this case it may be useful to reduce the CPU being used by the VB thread. But from what you've said - this isn't the case - you're only at 62%. So the downside of slowing down the VB thread's reaction to the semaphore is somewhat pointless IMHO. By way of example:

code "G1 X100 Y100"
while isMoving()
  sleep(100)
wend
code "G1 X0 Y0"

On average there is going to be a delay of 50ms between the first move finishing and the second move starting - for what? Without the delay you have a CPU that's spending 38% of its time idle anyway. I don't know what the loop cycle is without any explicit delay but clearly its going to be shorter without it - 100ms shorter.

As I say - just my opinion but to my no doubt crazy brain - it seems to make sense to me 

Hi IAN, I found and interesting point when upgrading my CPU. I went from a single core 1. ghz to a dualcore 2ghz cpu and a lot of the old VB issues with timing and CPU hogging seems to have vanished. THe G31 has gotten extremely stable as well.

Just a thought,  (;-) TP