Reading IO issues

[tbyrd0918]

I've been using this exact code on 3 machines with good success for several months.  All of a sudden, wham!!  No worky!! I have the v. 3.042.040 of Mach and 2.06.00  driver for my SmoothStepper version v015ogx2 plugin. When I run the M1000 macro, it moves the cylinder down, but it never says "made it".  I can look on the diagnostics screen in Mach and it shows the switch is made. The logic is I keep recurring the codes until it makes the switch. When it makes, it drop out of the code.  I have this same code only reversed and checking a different switch for "up" and it still works fine.  What I would really like is a word like "IsNotActive". It would allow me to stay in the same M code with a "while" statement. Any clues, or better way of coding?

  T.Byrd

 
'rem  M1000 down cylinder till switch
DeActivateSignal (output4)
ActivateSignal (output9)
If IsActive (input2) Then
Code "(made it)"
Else
Code "M3000"
End If   

'rem M3000 cylinder down return
Code "M1000 (I AM WORKING ON IT!)"

[Hood]

Not much of a clue with VB but this is what I would do.

 DeActivateSignal (output4)
 ActivateSignal (output9)
 If Not IsActive(Input2) Then               
 Do                                       
 Message ("I am working on it!")   
 Sleep 10             
 If IsActive(InPut1) Then Exit Do             
 Loop                                     
 End If
  Message ("made it")


Hood

[stirling]

One thing I notice is you appear to be calling a macro from a macro which is generally a no no in Mach, so maybe that's been tightened up on as versions have progressed and that's why it used to work but now doesn't.
Not only that but you also appear to be calling M3000 from M1000 and then calling M1000 from M3000 i.e. indirect recursion. This is probably best avoided even if you intended it and understand recursion as CVB is broken and doesn't handle it properly at all.
Anyway - here's my shot at what you describe.

 DeActivateSignal (output4)
 ActivateSignal (output9)
 While Not IsActive(Input2)
    Message ("Switch is Inactive")  
    Sleep 10
    'Something must cause the switch to make at some point, otherwise this is an infinite loop
 Wend
 Message ("Switch is Active")

Ian

EDIT: Not sure of course on the whole picture - but you do know about G31?

[tbyrd0918]

Thanks a bunch for the replies.  I knew that M codes from M codes was bad news, but didn't know how else to do it.  I guess the obvious was looking right at me.  I am not a VB student, just learned from looking at examples in Mach. I think the "NOT" word is the answer for me. I will try as soon as possible.  Thanks again.

T. Byrd

[HimyKabibble]

If you're going to do that, you have to use a semaphore to keep the first macro from exiting before the second one has completed.  Mach provides no synchronization between macros at all.

For example:

M1000.m1s:

Code "M01 ("This is M1000")

M2000.m1s:

Code "M1000"
Code "M01 ("This is M2000")

If you execute M2000, it will queue up the M1000 macro, then proceed executing.  So what you'll see is:

"This is M2000"
"This is M1000"

Which is exactly opposite what you want and expect.

Here's what you need to do:

M1000.m1s:

SemaphoreVar = 1000  ' This can be any unused Var number - Must be same one as in M2000.m1s
Code "M01 ("This is M1000")
SetVar (SemaphoreVar, 0)

M2000.m1s:

Code "M1000"
SemaphoreVar = 1000  ' This can be any unused Var number - Must be same one as in M1000.m1s
SemaphoreVal = 1
SetVar (SemaphoreVar, SemaphoreVal)
Code "M01 ("This is M1000")
While SemaphoreVal > 0
    SemaphoreVal = GetVar(SemaphoreVar)
    Sleep 10
Wend
Code "M01 ("This is M2000")

The semaphore ensures that the M1000 macro completes execution *before* the M2000 macro progresses beyond the While/Wend loop.  You can actually nest macros several deep if you initialize the semaphore to zero in the top-most macro, then have the calling macro increment the semaphore value, and make the While condition wait for it to be decremented back to its original value, and have the called macro decrement the semaphore, instead of simply clearing it.  This is the only way I know of to make nested macros behave in a predictable manner.  Without this, you have no way of knowing the exact order in which they'll execute, so it will behave differently at different times.  This is another of the MANY things that will be fixed in v4.

Regards,
Ray L.