Plugin-Delay required after commanding motion for IsMoving?

[eabrust]

I was just starting to play with how to command probe moves from a plugin written in VB.net. I got a small test routine to run, and report back the variable stored in #5061 variable (x touch point), however I have a question about a delay being required after issuing the UC.Code command to initiate the probe event, and the while IsMoving loop.

Code sample, initiated by a button press on a form as I finally got it to work:

Code: Select all

Private Sub Button2_Click(sender As Object, e As EventArgs) Handles Button2.Click
        Dim x
        Dim feed As Integer
        Dim readX

        x = UC.GetXpos
        x = x + 1
        feed = TrackBar1.Value
        MsgBox("GO TO X = " & x & "  Feed = " & feed)

        UC.Code("G31 x" & x & " f" & feed) ' command a G31 probe move

        UC.Wait(200) ' THIS DELAY REQUIRED, OR THE 'IsMoving' loop was skipped before movement actually started.  WHY?

        Do While UC.IsMoving 
            MsgBox(" in loop")   '  Added as test to see if this loop was skipped or not
        Loop


        readX = UC.Getvar(5061)
        MsgBox("X = " & readX)
    End Sub



What I am struggling with was trying to get the 'while UC.IsMoving' loop to work and prevent the sub from finishing before movement even started. it seems unless I added a delay after issuing the code command, movement wouldn't even be started before the IsMoving loop was skipped and the final msgbox popped up, and it took between a 150-200 msec delay to make it finally work. I don't believe a delay was needed in macros written in C# between the code command and the IsMoving loop. I'm probably making a simple error... Any thoughts? Is there a delay between a plugin providing a code command to UCCNC and the initiation of movement that is different than a macro being executed?

regards,
Eric Brust

[cncdrive]

The plugin when executing the .Code directive has some delays, because it is not buffered motion like it is with g-code program execution.

In g-code execution the executer loop first reads the current coordinates from the motion controller and then sets those as the starting coordinates for the axes and then starts the loop with executing the g and m codes program one by one filling them into the motion buffer and every command which makes movement registers it's own final coordinate in.
So, there is one initial delay before the motion starts, but after that the buffer fills, so no more delays.

When the plugin calls a .Code directive then the same happens when an MDI command is executed, the first step is the same as above, the motion controller reads the coordinates from the motion controller and after that it compiles and executes the g-code line. If you then adding another command another .Code directive is called then again the start coordinates are read and the command is executed.
So, this kind of operation is not buffered and has some delay between the lines executed, because there is no buffer and on start the coordinates has to be read and for this at least a 20msec wait is required, because that is the time interval the motion controller updates it's coordinates to the software side, so this wait can ensure that the coordinates are up to date after the last command finished.

The other thing which can cause a delay is the compilation time of the g-code. When you send the code with the .Code directive then the g-code has to be compliled first.

And the third delay cause and probably this one is the most significant is that to start the motion the data has to be sent to the motion controller. Again, this operation is not buffered, so one time the command representing one line of code is being sent to the motion controller and so there is the delay on sending the line and receiving the line and starting motion and feeding the motion started signal back. In the g-code program execution this does not happen, because the software fills commands into a buffer, so the motion controller continously getting data and continously feeding back data.

[cncdrive]

2 more things I forgot to write about and may be interesting:

There is the .Codesync function in the plugin interface, that function is the same as the .Code function, but it does not start it's own thread,
it makes the execution in the same thread where it is called from.
So, the .Codesync gives the handle back to the caller only when the function is finished, in case of probing this happens only when the data is sent to the motion controller.
For probing a delay can still happen, but not as large I think, because the function only returns when it finished the code compilation and execution and the data is sent to the UC.
The issue with this function is that you can't seat it in the main Thread, because if you do can lock up the software, because then it will steal time from the main GUI as then they will be seated in the same thread,
so things may not be able to update and then an infinate wait to eachother condition may happen.
So, the .Codesync function should be executed from another than the main thread, e.g. from the plugin loop thread or from your own Thread or Backgroundworker.

The other thing is that with the probing you can wait for the Probe LED also, just one thing you should handle is that there can be cases when the probing will never start,
e.g. when the probe is not even configured by the user, the plugin should think handle handle this case also.

[eabrust]

Hi Balazs or anyone cranking out plugins that actually work! ,

I'm resurrecting this ancient question because I'm either screwing up something very simple, or something broke in recent test releases, or I'm losing my mind


I've built up a surface scanning routine as a Macro and got it working fairly well as a VB Macro... Now I'm trying to stuff that routine code into a Plugin so I can have an interface and plots to go with the routine to make it more user friendly. The plugin and testing is being done with UCCNC 2109, targeted for any cpu and DotNet 4.0, and is written in VB. I've tested on two computers, with both a UC300eth and a UC100 with same problems.

After struggling with the routine a bit as a plugin (as in, I can't get past the first move), I went back to a very simple button calling a single simple G31 move like this:

Code: Select all

 Private Sub Button9_Click(sender As Object, e As EventArgs) Handles Button9.Click
        Dim x
        Dim feed As Integer
        Dim readX

        x = UC.GetXpos
        x = x + 1
        feed = 10
        MsgBox("GO TO X = " & x & "  Feed = " & feed)
        'Me.TrackBar1.Value = 200

        delaytime = Convert.ToDouble(Me.TrackBar1.Value)
        MsgBox("delay =" & delaytime)

        UC.Code("G31 x" & x & " f" & feed) ' command a G31 probe move

       ' Delays and msgboxs commented out currently, un-commenting does not fix.
        'MsgBox("before delay")
        'UC.Wait(delaytime) ' THIS DELAY NO LONGER WORKING TO PREVENT PROGRAM FROM GETTING AHEAD OF MOVES.  WHY?
        'Thread.Sleep(delaytime) ' Thread sleep didn't work either...
        'MsgBox("after delay")

        While (UC.IsMoving())
            MsgBox(" in loop")   '  Added as test to see if this loop was skipped or not.  This works if the move is a G1 instead of G31
        End While
        'UC.Wait(delaytime) ' Tried delays down here, no affect on problem


        readX = UC.Getvar(5061)
        MsgBox("X read= " & readX)
    End Sub


No matter what I do with regards to adding a 'delay' after issuing the UC.Code("G31 .....") command, the routine runs to the end and shows the final dialog (which either spits out readX as 0, or as the value from the PRIOR G31 trip from pressing the button the last time...), then the G31 movement starts. No matter what, I cannot get the UC.Ismoving() to keep the routine from getting ahead of the move. I've used delays of 2000 msec, and it just sits there for 2 seconds, then shows the final msgbox, then movement starts. So, I'm baffled...

However, if I replace the UC.Code("G31 .....") command with a G1 move as UC.Code("G1 ....."), the Ismoving() loop triggers and things happen in the proper order.

Any ideas? I'm really at my wits end I was going to start recompiling back to a DotNet 2.0 release and try to use an old 'release' version of UCCNC to test with, but was hopping someone can point out a stupid error I'm making....

regards
Eric Brust

[dezsoe]

Hi Eric,

Did you try UC.Codesync instead of UC.Code?

[eabrust]

Hi Eric,

Did you try UC.Codesync instead of UC.Code?

Hi Dezsoe,

I did forget to mention, I had also given UC.codesync a try and it resulted in hanging UCCNC, requiring killing by taskmanager.

I'll fully admit, I'm a hack programmer (mechanical engineer by trade) but trying to learn

As Balazs mentioned long ago about creating a separate thread or background handler to implement using UC.codesync, I'm not really sure of how to implement without a small example of how that is handled/coded.

I guess I struggle with how easy it was to get it working as a macro (really no regard for timing/delays), and interfacing via the plugininterface is surprisingly difficult with timing, etc. I'm sure some will suggest just leaving it as a macro, but I do have a reason for trying to push this into a plugin with an interface. The routine I'm working has several 'pre-processnig' steps to filter out a grid to probe within a boundry outlinging a part, and it was very easy to make the plugin have an interface that plots results for visual confirmation.

Thanks for your help

regards
Eric Brust

[dezsoe]

You have to call MyProc and that will create a new thread and start it. You also have to be careful with the UC.Ismoving function, because in many cases it can hang. Call it from a new thread like in the sample.

Code: Select all

Imports System.Threading

    Dim IsMovingFlag As Boolean = False

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

    Private Sub MyProcThread()
        ' Your code here, e.g.
        UC.Codesync("G0X0")
        While IsMoving() ' <-- this is the private IsMoving()
            Thread.Sleep(5)
        End While
    End Sub

    Private Function IsMoving() As Boolean
        Dim thrIsMoving As New Thread(Sub() CheckIsMoving())
        thrIsMoving.CurrentCulture = Thread.CurrentThread.CurrentCulture ' Maradjon angol!
        thrIsMoving.Start()
        While thrIsMoving.IsAlive
        End While
        Return IsMovingFlag
    End Function

    Private Sub CheckIsMoving()
        IsMovingFlag = UC.IsMoving
    End Sub


[eabrust]

Thanks much Dezsoe,

This will be a big help to give me some education! I will give it a shot.

regards
Eric Brust