plugin too fast?

[ger21]

Anyone doing probing in a plugin ever seen this? After a probe that triggers the input, var 5060 is occasionally returning 1, which is stopping my probing routine. I was seeing this about 1 out of 10 times, maybe even more? My only thought is that the UC.Getvar was happening before the VAR was actually updated? I added a UC.Wait(100) after the probe move, and it seemed to help, but it did happen again one time. I'm going to try increasing the wait to 250ms and see if that fixes it. I'm testing with an AXBB-E on me desk, using a pushbutton for the probe input. The probe move is 12", and I push the button as soon as it starts probing, and the messagebox opens immediately. Everything else seems to be working perfectly.
If I can't resolve this, I may just need to remove the code that checks the probe was good.
Using 2.115, but if I keep seeing this, I'll try an older version later today.

Code: Select all

   
gcodestr = "G31 Z" + CStr(znew) + " F" + CStr(FirstProbeFeed)  ' First Probe Move
                        Call MyProcThread()

                        ProbeFinished = UC.Getvar(5060)

                        If ProbeFinished = 1 Then
                            MessageBox.Show("Probing move completed without triggering input." + Environment.NewLine + "If no contact was made, increase Probe Distance and try again." + Environment.NewLine + "If contact was made, verify that probe input is functioning properly.", "Probing Error", MessageBoxButtons.OK, MessageBoxIcon.Error)
                            UC.AddStatusmessage("Probing failed - Auto Zero aborted")
                            gcodestr = "F" + CStr(CurrentFeed) : Call MyProcThread()  ' Reset Feedrate
                            Call RestoreScale()
                            Exit Select

                        End If

[eabrust]

Morning Gerry,

When you do 'call MyProcThread', are you firing up the probing routine as a new thread, or are you in a thread already stepping along and calling a plain subroutine from the main form thread?

If calling a new thread, when you pull Getvar(5060) and check ProbeFinished, it may be happening out of sync with when the probe finishes. Can't tell for sure how you're calling the routine, so just guessing


When I call up a new thread, I put everything in that routine running as a new thread, from start to finish, including checks for hit/miss, etc to be called form that thread in order. They can be in subroutines called from the thread right after the moves, and trigger a flag like 'abort'.

Say I have a 'diameter routine' button and its going to do a lot of things in an order, the general order is:
Screen Button Creates new thread, calls 'diameter' routine as a new thread
Now that it is running in a new thread, all the following happens in order on that thread:
-call initializing all probe variables
-Probe X+
-check hit/miss (abort if miss and show dialog, exit sub, kill thread (MyProcThread=nothing))
-Probe X-
-check hit/miss (abort if miss and show dialog, exit sub, kill thread (MyProcThread=nothing))
.. More probing, same as above
-move to final position
-Set DROs (if zeroing)
-Run a 'closing' sub where message boxes / outputs are shown
-set MyProcThread= nothing





regards
Eric

[ger21]

The main problem is that I don't know what I am doing. I'm not using any forms, so everything runs in the Buttonpress_Event sub.
I'm using this code:

Code: Select all

 
 Public Sub MyProc()
        Dim thrMyProc As New Thread(Sub() MyProcThread())
        thrMyProc.CurrentCulture = Thread.CurrentThread.CurrentCulture ' Stay in English
        thrMyProc.Start()

    End Sub

    Public Sub MyProcThread()

        UC.Codesync(gcodestr)

        While IsMoving() ' <-- this is the private IsMoving()
            Thread.Sleep(5)
        End While

        Call StopCheck()

    End Sub

I don't really know how to tell if I'm actually using a new thread. The only place I can add thread=nothing is like this. Does this stop the thread after the move?

Code: Select all

  Public Sub MyProc()
        Dim thrMyProc As New Thread(Sub() MyProcThread())
        thrMyProc.CurrentCulture = Thread.CurrentThread.CurrentCulture ' Stay in English
        If Not thrMyProc Is Nothing Then
            thrMyProc = Nothing
        End If
        thrMyProc.Start()
        thrMyProc = Nothing

    End Sub

[eabrust]

Like I said before, threading kicked my butt for a while... I probably still do things wrong too, but have routines that work for my needs and I'm


From the point you call 'thrMyProc.Start', you have just started a new thread that is running the procedure ' MyProcThread() ' . From that point you probably don't want to allow the user to either accidentally start another thread (say they click your button to probe to many times...), and you don't want to do anything in the calling routine 'MyProc' after starting the thread that depends on the thread, as they are potentially out of sync at that point.

I'm assuming you are calling MyProc direct from the button press event. what you might want to do to prevent a user from multiple runs of your routine is:

Code: Select all


Public Sub MyProc()
       
if thrMyProc is nothing then   ' its OK to start thread, existing not running

        Dim thrMyProc As New Thread(Sub() MyProcThread())
        thrMyProc.CurrentCulture = Thread.CurrentThread.CurrentCulture ' Stay in English

        thrMyProc.Start()

else ' existing thread is running,

      messagebox.show("Another threaded routine is currently running!")
       ' do nothing, or alternately could kill the running thread by setting abort flag and setting thread = nothing.

end if

End Sub

Then you let MyProcThread run to the end, call other subs, do what it wants, and when you terminate MyProcThread routine for what ever reason (either finish successfully, or aborted/canceled), you can throw the thrMyProc = nothing at the end or in the middle as needed:

Code: Select all


Public Sub MyProcThread()

       ' Do a probe check
      if probecheck = false then
          exit sub
         thrMyProc = nothing   ' kill the thread due to aborting process...
      end if


        UC.Codesync(gcodestr)

        While IsMoving() ' <-- this is the private IsMoving()
            Thread.Sleep(5)
        End While
       
     

        Call StopCheck()
       
        'Finished Succesfully!
        thrMyProc = nothing 
    End Sub


if thrMyProc is defined globally, any subroutine you have can set it to nothing.

hope that helps more than confuses.

Just to confirm, I did not back-check any of the code I modified above, it could have typoes, etc.

regards
Eric

[ger21]

This throws an error because thrMyProc is not yet declared.

Code: Select all

Public Sub MyProc()
       
if thrMyProc is nothing then   ' its OK to start thread, existing not running

        Dim thrMyProc As New Thread(Sub() MyProcThread())
        thrMyProc.CurrentCulture = Thread.CurrentThread.CurrentCulture ' Stay in English

        thrMyProc.Start()

If I declare thrMyProc so it's accesible everywhere, then I can do this.

Code: Select all

    Public Sub MyProc()

        If thrMyProc Is Nothing Then
            MsgBox("new thread")

            thrMyProc = New Thread(Sub() MyProcThread())
            thrMyProc.CurrentCulture = Thread.CurrentThread.CurrentCulture ' Stay in English
            thrMyProc.Start()

        Else
            MsgBox("Thread already running")

        End If

        thrMyProc = Nothing

    End Sub

But the message boxes never show up, so I don't know what's happening.

Everything is actually working, so I don't know if I even need to do this. I check everything and exit before I call the Codesync in the new thread. So the only time I think I would need to kill the thread is if the user hits the Stop button? If so, then this should do all I need?

Code: Select all

   Private Sub StopCheck()

        If UC.Ismacrostopped() Then Stopflag = True
        thrMyProc = Nothing

    End Sub

I changed the UC.Wait(100) to 250ms. I haven't seen an error today. I need to remove them and see if the errors return.
Thanks for the help, it's much appreciated.

[dezsoe]

This problem is caused by a bug. (I'm also struggling with it in the probing plugin.) It seems like the bug has been found, but we need more tests before we could say that it's fixed.

[ger21]

I'll check when I get home, but since I changed the wait to 250ms, I haven't seen this happen again.
I'll be doing a lot more probe testing this weekend, so I'll let you know if I see it again.

[cncdrive]

Hi Gerry,

Yes, there is a bug which makes the #vars to not to return the updated value for the Getvar function in time.
The issue seems to be that the controller goes out of the running state back to idle before the API actually updated the variable to the new value when the Setvar function was called.
This makes the Getvar function to still read the old value of the variable and this is why the Wait function resolves the issue.
This issue happens only like 1 out of 100, but it happens unfortunately.
And a Variable writting usually happens very quickly in less than 20msec though, so there is no need to put in much wait IMO.
We currently working on fixing this bug.