Hello Guest it is March 28, 2024, 10:20:38 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - HimyKabibble

1
General Mach Discussion / Re: Changes In Macro Execution?
« 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.

2
General Mach Discussion / Re: Changes In Macro Execution?
« 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.

3
General Mach Discussion / Re: Changes In Macro Execution?
« 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.

4
General Mach Discussion / Re: Changes In Macro Execution?
« 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.

5
General Mach Discussion / Re: Changes In Macro Execution?
« 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.





6
General Mach Discussion / Re: Changes In Macro Execution?
« 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.

7
General Mach Discussion / Re: Changes In Macro Execution?
« 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.

8
General Mach Discussion / Changes In Macro Execution?
« 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.

9
BTW - Anyone have a toolchanger plug-in I can use as a starting point?

Regards,
Ray L.

10
Ger,

Thanks!