Machsupport Forum

Mach Discussion => General Mach Discussion => Topic started by: HimyKabibble on July 14, 2015, 10:03:14 PM

Title: Changes In Macro Execution?
Post by: HimyKabibble on July 14, 2015, 10:03:14 PM
I've been away from Mach3 for several years, but now have to get back into, and write some relatively simple macros to operate my old power drawbar and toolchanger, which had been running under KFlop.  I've translated the KFlop C driver to CB, and it's sorta-kinda working, but I'm getting some really odd results.  Under various error conditions, I pop-up an error dialog using MachMsg, and I sometimes see these dialogs appear from portions of code that should never have run, and this invariably happens LONG after the macro, by all appearances, has completed execution.  

So, I am confused.  I notice in the Programmer Reference Manual, which I originally wrote many years ago, has been significantly updated.  In particular, I notice the new "RunScript" function, for which the manual seems to recommend NOT using M-macros, due to the need to "invent and handle semaphores".  WTF??

Anyway, my PDB/ATC macro is attached.  Does anyone see anything in there that could explain the bizarre behavior I'm seeing, or explain what I'm doing wrong?  It appears to me almost as though some subroutine calls are going off and running asynchronously in separate threads, so I end up with several threads running in parallel for what MUST be a linear sequence of operations.

Regards,
Ray L.
Title: Re: Changes In Macro Execution?
Post by: HimyKabibble on July 14, 2015, 10:07:03 PM
BTW - Another VERY odd thing I see:  I wrote some G-code to test this macro.  The G-code consists of nothing but a series of invocations of my macro, to invoke it's various sub-functions.  I cannot Load that g-code file into Mach3 - it hangs while loading the file, at about 30%, and never progresses any further.  The G-code program is attached.

Regards,
Ray L.
Title: Re: Changes In Macro Execution?
Post by: Overloaded on July 15, 2015, 07:37:14 AM
Hi Ray,
  One compile error. Might make a difference ? ? ?

Seems to load OK now.
 
Quite a macro .... looks like a lot of nice work !
Russ
Title: Re: Changes In Macro Execution?
Post by: HimyKabibble on July 15, 2015, 10:20:28 AM
That little typo crept in just before I posted the code, but wasn't in the code as I tested it.

Regards,
Ray L.
Title: Re: Changes In Macro Execution?
Post by: HimyKabibble on July 15, 2015, 12:00:47 PM
This is completely F-ed up!  The code compiles without error, it seems to run correctly, except....

If I load the g-code file (which today loads correctly - Why? I don't know....), and Single-step through it, here's what happens:

The first line, M806 P0, executes correctly, and initalizes the ATC.

The second line, M806 P20, also appears to execute correctly, and lowers the ATC "lift".

The third line, M806, P21, also appears to execute correctly, and raises the ATC "lift".

Here's where it gets strange - If I just wait a bit, after 10-20 seconds, I start getting error dialogs, coming from the code that actually performs the above operations.  These dialogs report both Lift Down and Lift Up errors, and come from the LowerLift() and RasieLift() functions.  Note the timeouts in these functions are 2 seconds, yet the errors don't pop up for at least 10-20 seconds AFTER the code is executed.  Also, since I am single-stepping the G-code, should it not be impossible to single step one line until the macro for the previous line has completed execution?  That being the case, how is it possible I am stepping several lines of code, and only getting error dialogs tens of seconds later?  The more lines I execute, the more errors I get, and the longer they are delayed before popping up.

When I manually execute the Lift Down and Lift Up operations using MDI, they work perfectly every time.

This makes no sense at all to me, and is CLEARLY different behavior from what I've seen in the past.  WTF is going on here?

Here is the LowerLift code.  The RaiseLift code is essentially identical except it flips the control but the other way:

Function LowerLift (ByVal verify As Integer) As Integer

    If IsOutputActive(ATC_LIFT) = ATC_LIFT_DOWN And IsActive(ATC_LIFT_SENSE) = 0 Then
        LowerLift = ATC_ERR_NOERROR
   GoTo EXIT4
    End If

    If verify = 0 Then
        ActivateSignal(ATC_LIFT)
        Sleep(1000)
        LowerLift = ATC_ERR_NOERROR
   GoTo EXIT4
    End If

    LowerLift = ConfirmAction(ATC_LIFT, ATC_LIFT_LOWER, ATC_LIFT_SENSE, ATC_LIFT_TIMEOUT, ATC_ERR_LIFT_DOWN_FAIL)

EXIT4:
    CurrentLiftPos = 1
End Function


Function ConfirmAction (ByVal bit As Integer, _
         ByVal bitval As Integer, _
         ByVal sense As Integer, _
         ByVal timeout As Integer, _
         ByVal err As Integer) _
          As Integer
                         
     '' Must not be mid-travel at start
    If IsActive(sense) Then
   ConfirmAction = err
        GoTo Exit7
    End If

    '' Set/Clear the control bit
    If bitval = 1 Then
        ActivateSignal(bit)
    Else
        DeactivateSignal(bit)
    End If

    '' Ensure it moves - first wait for sensor high
    ElapsedTime = 0
    i = 0
    While i < 10
        If IsActive(sense) = 1 Then
            i = i + 1
        Else
            i = 0
        End If
        Sleep(1)
   ElapsedTime = ElapsedTime + 1
        If ElapsedTime >= timeout Then
       ConfirmAction = err
       GoTo EXIT7
        End If
    Wend

    '' Now wait for sensor low
    i = 0
    While i < 10
        If IsActive(sense) = 0 Then
            i = i + 1
        Else
            i = 0
        End If
        Sleep(1)
   ElapsedTime = ElapsedTime + 1
        If (ElapsedTime >= timeout) Then
       ConfirmAction = err
       GoTo EXIT7
        End If
    Wend
    ConfirmAction = ATC_ERR_NOERROR

EXIT7:
End Function

Regards,
Ray L.




Title: Re: Changes In Macro Execution?
Post by: HimyKabibble on July 15, 2015, 12:31:21 PM
One mystery solved:  IsActive(signal) = 0 and IsActive(signal) = 1 do not work as expected.  You must use IsActive() and Not IsActive().  I put a MachMsg at the very end of the main code, so I can now see when the code stops executing, and it now ends when I think it should.

The other mystery remains:  I can still single-step the lines in the G-code window, BEFORE the previous line(s) have completed executing!  How do I fix that??

In addition, the timeouts in my loops are taking about 10X longer to time out than they should.  The Sleep(1) seems to be acting more like a Sleep(10).....

Regards,
Ray L.
Title: Re: Changes In Macro Execution?
Post by: stirling on July 15, 2015, 01:18:53 PM
One mystery solved:  IsActive(signal) = 0 and IsActive(signal) = 1 do not work as expected.

That's because in most (if not all) dialects of BASIC, true evaluates to -1 not 1. (if you must do an explicit compare) but the not op is preferable (in any language).

The other mystery remains:  I can still single-step the lines in the G-code window, BEFORE the previous line(s) have completed executing!  How do I fix that??

AFAIK this has always been the case with single block. Just tested it here on my trusty old 3.042.020 and that's how it is. A normal cycle runs macros "serially" though.

In addition, the timeouts in my loops are taking about 10X longer to time out than they should.  The Sleep(1) seems to be acting more like a Sleep(10).....

IIRC very low sleep values (<10) ARE inaccurate.
Title: Re: Changes In Macro Execution?
Post by: HimyKabibble on July 15, 2015, 01:37:29 PM
One mystery solved:  IsActive(signal) = 0 and IsActive(signal) = 1 do not work as expected.

That's because in most (if not all) dialects of BASIC, true evaluates to -1 not 1. (if you must do an explicit compare) but the not op is preferable (in any language).

The other mystery remains:  I can still single-step the lines in the G-code window, BEFORE the previous line(s) have completed executing!  How do I fix that??

AFAIK this has always been the case with single block. Just tested it here on my trusty old 3.042.020 and that's how it is. A normal cycle runs macros "serially" though.

In addition, the timeouts in my loops are taking about 10X longer to time out than they should.  The Sleep(1) seems to be acting more like a Sleep(10).....

IIRC very low sleep values (<10) ARE inaccurate.

I guess I never single-stepped through M macros in G-code before, because I never noticed that (incredibly annoying) behavior!

It does appear Sleep(1) is, very nearly, equivalent Sleep(10).  I divided all my timeouts by 10, and they're not at least in the ballpark.

Regards,
Ray L.
Title: Re: Changes In Macro Execution?
Post by: BR549 on July 15, 2015, 11:21:06 PM
HIYA Ray, What version are you running IF V.066 then you may want to DUMP that version and back up to .062  .  

as to isactive() sometimes

true / false works sometimes NOT

is /not may or may not work

-1/1 may or may not work

0/1 may or may not work

sometime the signal inverts sometimes not

SLEEP() (;-) anything under (10) is useless and don't count on it being exact cause it may or may not be.

It just depends (;-)

(;-) TP
Title: Re: Changes In Macro Execution?
Post by: stirling on July 16, 2015, 04:06:44 AM
It does appear Sleep(1) is, very nearly, equivalent Sleep(10).  I divided all my timeouts by 10, and they're not at least in the ballpark.

Sleeps longer than 10 should be reasonably accurate so there should be no need to modify or scale them. Generally just don't expect sleeps < 10 to be accurate and therefore don't use them. If your sleeps that are > 10 are wildly inaccurate then there's likely another issue somewhere.

as to isactive() sometimes

true / false works sometimes NOT

is /not may or may not work

-1/1 may or may not work

0/1 may or may not work

sometime the signal inverts sometimes not

LOL - well if you say so Terry, but I have NEVER seen isactive() fail to return true (-1) or false (0).

What I HAVE seen is functions that are documented as being boolean actually returning 0 and 1 instead of 0 and -1. Clearly there was some inconsistency in the interface implementation between the C++ "source" and the CB API. In those cases, using NOT will provide endless hours of debugging fun if you're not onto it.

Try this for your entertainment:

msgbox not 1

Perfectly logical, but a gotcha if you don't see why.

One example of a gotcha is getOEMLED. It returns 1 and 0 but how often do we see if getOEMLED(...) in code i.e. treating it as if it were a boolean function? Sure it'll work fine but then someone takes the logical next step and does a if NOT getOEMLED(...). That'll end in tears because NOT 0 implicitly casts to true BUT so does NOT 1.

isMoving() is perhaps the worst example for a few reasons. First, although it implies a boolean result it isn't (unlike most other is.... functions) so really, all the while isMoving() loops we see should really be while isMoving() = 1. Because again if you ever do a "if NOT isMoving()" it will not do what you might think. Of course isMoving()s worst "feature" is that contrary to its name it doesn't actually (exclusively) have anything to do with anything moving! Don't even get me started on isStopped().
Title: Re: Changes In Macro Execution?
Post by: HimyKabibble on July 16, 2015, 04:54:37 PM
Terry,

I'll give 062 a try.  I've got the ATC working, after a ridiculous amount of pain.  This has to be the single WORST environment for software development I've ever seen.  The compiler will report no errors, then I make a minor change somewhere, and it complains about a syntax error in code that hasn't changed in days!  I'm still concerned about loading G-code files that invoke the macro, as they seem to take FOREVER to load, if they actually ever complete loading at all.  For example, this simple program:

M98 P01 L10
M30
O01
M806 P1
M806 P2
M99
M30

will take several MINUTES to load!

Regards,
Ray L.
Title: Re: Changes In Macro Execution?
Post by: BR549 on July 16, 2015, 07:26:27 PM
Ray it is all going to depend on WHAT is inside of those Mcodes (;-)  Mach3 does very well as a Gcode controller. Not so well as a macro script interputor.

IF you bog it down with a heavy script load it will choke like a donkey eating a sandspur sandwich. It was not designed for that type of operations.

I have fed it massive amounts of Gcode with subs and vars and it runs like a new clock.  Just don't do ToolComp with that (;-).

Just a thought, (;-) TP
Title: Re: Changes In Macro Execution?
Post by: BR549 on July 16, 2015, 07:29:41 PM
HIYA Stirling, DON"T get started , there may not be enough bandwidth.  :o

It just IS what it IS,
(;-) TP
Title: Re: Changes In Macro Execution?
Post by: BR549 on July 16, 2015, 07:34:00 PM
Ray just curious BUT do you have it set to ignore Mcodes on load??  IF it does not have to load the and check the macros it should load that code it the wink of an eye.

(;-) TP
Title: Re: Changes In Macro Execution?
Post by: HimyKabibble on July 16, 2015, 08:00:34 PM
Ray just curious BUT do you have it set to ignore Mcodes on load??  IF it does not have to load the and check the macros it should load that code it the wink of an eye.

(;-) TP

Terry,

Didn't even know that was on option!  I'll check that.  Thanks!

The PDB and ATC are now (once again) fully functional, but boy was it painful getting it there!

Regards,
Ray L.
Title: Re: Changes In Macro Execution?
Post by: stirling on July 17, 2015, 04:56:40 AM
HIYA Stirling, DON"T get started , there may not be enough bandwidth.  :o

LOL - well if that ain't the pot calling the kettle.  :P

Yes CB is pretty crap and its interface to Mach leaves something to be desired but as you know I was having a little pop at your reply #8 by trying to give LOGICAL explanations.

So, I've explained why assuming TRUE evaluates to 1 was causing perfectly logical (pun intended) issues and I'm happy to take a shot at explaining every other issue here without resorting to "it's the grinch what done it".  >:D
Title: Re: Changes In Macro Execution?
Post by: BR549 on July 17, 2015, 07:48:32 AM
I like the Dragons explanation better  ;D

I hear that Art is doing another motion controller  for laser/3d printing  :o  ;) ;D

Based on a pokey 57e

Interesting

(;-) TP
Title: Re: Changes In Macro Execution?
Post by: ART on July 17, 2015, 09:24:23 AM
Terry:
 

As you know I never promise anything. I am working on a controller as I need one for my laser. I also feel  like using Tempest finally, so Ill attempt to complete the 6th order planner for the project and at the moment Im still back at the screen designer stage.
  Im curious to see if I can apply a lot of lessons learned over time. Ive got many idea's abut how things could be improved in several area's so I figureded I need a test bed to play with.. It will, as is everything I write from now on, be included in Gearotic,
however it turns out. :)

Art
 
Title: Re: Changes In Macro Execution?
Post by: BR549 on July 17, 2015, 10:31:24 AM
Art your adventures are ALWAYS a great adventure worth following. I did some research on the pokey are you are correct it IS an interesting critter.

BUT what happend to the beagle bone thingy ??

Nothing wrong with using Gearotic as a base of operations  ;)

(;-) TP