Unexpected motion during a macro.

If you think you've found a bug post it here.

Re: Unexpected motion during a macro.

Postby A_Camera » Thu Dec 21, 2017 8:34 am

Derek wrote:
dezsoe wrote:Hi Derek,

I think I'm over the 100th run, and didn't have any problem with your code. I think it depends on some special constellation of stars... (I don't say I don't beleive what you wrote, just couldn't reproduce. I also have a jog issue, which happens cca. two times a year, so I could never reproduce it, but sometimes happens.)


Better try 101 times. That may work :)

These things are terrible to solve. I have run the M20001 hundreds of times and never had an issue. I have seen unexpected movement on probing macros before but it's pretty rare. One thing I will say is that when it glitches it stays glitched until you restart UCCNC. And it behaves the exact wrong way each time. This is a definite problem and macro related. I don't have to restart the computer just UCCNC.

Is there any log info I can save when it does?

Try replacing...

while(exec.IsMoving()){}

with...

while(exec.IsMoving())
{
exec.Wait(200);
}


I know it is a wild shot and is been said that it does not matter, but it is worth a try, isn't it?
A_Camera
 
Posts: 474
Joined: Tue Sep 20, 2016 11:37 am

Re: Unexpected motion during a macro.

Postby dezsoe » Thu Dec 21, 2017 9:38 am

OK, I'll give it a try. (In my macros I killed all exec.Wait-s, because I don't like to wait for them. :))
dezsoe
 
Posts: 571
Joined: Sun Mar 12, 2017 4:41 pm
Location: Csörög, Hungary

Re: Unexpected motion during a macro.

Postby Vmax549 » Thu Dec 21, 2017 3:56 pm

This bug has been around for a while. It seems to be a problem of teh macro having to have wait states just to keep problem in check. Then there are times that that does not work and it glitches. In teh CNC world you should NEVER have to add wait states just to keep control over code flow. You never see that in Gcode (;-) and you never see that in Macro B . With a CNC M code it should simply process each line in script order and not be able to get out of sync and it should NOT require teh use of wait to make it happen.

Now in normal scripting I understand teh need to have teh programmer control certain functions but NOT in Macros involving cnc motion. But in a Macro teh macro enviroment should be controlling teh wait until each line completes it's function.

A while back I spent almost 3 months trying to track it down. But without error scripting inside of UCCNC I was not able to track it down. Like Derek said once it starts it acts teh same way each time and it continues until you restart UCCNC. Then once UCCNC is restarted it will runs fine UNTIL teh sun and stars align again and it reoccurs. I stopped working on OEM advanced motion macros because of it.

And yes I understand IF they cannot reproduce teh error they can not fix it. But it IS real.

(;-) TP
Vmax549
 
Posts: 1379
Joined: Sun Nov 22, 2015 3:25 am
Location: USA

Re: Unexpected motion during a macro.

Postby cncdrive » Thu Dec 21, 2017 6:37 pm

You do not have to have a wait inside a while ismoving loop, because the IsMoving function itself contains a wait which let's the CPU to do other things even if the ismoving is inside a while cycle.
The ismoving also automatically keeps the datas (status LEDs) and the DROs in syncron with the Ismoving only giving back a false return value after a true when the motion stopped and the DROs were read once from the motion controller after that happened, so it does not allow unsyncronised data to be read by the user which was an issue earlier and was fixed months ago with making the Ismoving to properly syncronise things before switching state, so the user does not have to take care of it and so the wait is not required...
cncdrive
Site Admin
 
Posts: 2297
Joined: Tue Aug 12, 2014 11:17 pm

Re: Unexpected motion during a macro.

Postby Vmax549 » Thu Dec 21, 2017 9:50 pm

That is true BUT you still have to apply while Ismoving which is a wait state. Nowhere else in teh Commercial CNC world do you have to use wait states in macros (Mcodes) teh macro environment keeps in all in check without having to code in wait states.
I also have noted that you do sometimes have to add an additional wait() when doing something like read or write a DRO to give uccnc time to clear teh last line of code otherwise it may not retreive or write teh DRO value before moving on.

Just a thought (;-) TP
Vmax549
 
Posts: 1379
Joined: Sun Nov 22, 2015 3:25 am
Location: USA

Re: Unexpected motion during a macro.

Postby cncdrive » Thu Dec 21, 2017 10:31 pm

In most commercial CNC's the macros are only g-codes and then there is no need and not even possible to add waits other than G4 or the equivalent dwell/wait codes and also things are all in syncron, executes in a clear sequence just like a g-code file.
We could ofcourse do the same with the UCCNC, implement macroing like that (It would be especially much easier than how it is done now.), but then you would loose the ability to make many customisations which you can now in the UCCNC.

And there is no always need for wait states, you can decide if you want and need to wait in a macro for things to end or not. E.g. you decice if you have to and want to wait for a motion to end or if you want to do your next thing before the motion ends.
The while ismoving just waits for your previous motions to finish and let the DROs have updated values according to that state, but if you don't want to wait for that then you not writting a while ismoving loop and thats it. There can be cases when you don't want to wait, when straight sequential execution would be a problem, a limitation for the macro.
And yes, we could keep the control and not release it before commands finish, but as said that would cause limitations for what can be done with macros.
It is always a question what to allow and what not to allow for the user to do in macros and in their custom codes and it is always compromises, because if we allow less then the working is simpler and the workflow is clearer, but then the users complain that they want to have access to more and that they can't do certain things ... and if you allow to do everything then the users complain that the workflow is not clear and easier to make errors and then they think those are bugs in the software when they just don't understand and see the workflow clearly, because it is complex. So, it is a very hard thing to decide how to do it, we have tried to keep the balance somewhere in the middle with how it is done in the UCCNC.
cncdrive
Site Admin
 
Posts: 2297
Joined: Tue Aug 12, 2014 11:17 pm

Re: Unexpected motion during a macro.

Postby Robertspark » Fri Dec 22, 2017 9:59 am

2 cents / 2 pence....

as I understand it

"wait" is not good as everything stops until the wait is completed {time period / logic to change}

"while not equal" allows for other background tasks to complete at least you are not stopping the processor / programme.
___________________________
is this a debounce issue?

If the motion controller is set at 400khz loop for example, is the while{} not maybe allowing for some debounce or is being affected by potential signal noise?

what does the loop run at?

If the while loop runs at macroloop speed, then does the motion controller do some debounce according to match the macroloop {i.e. data passed back to uccnc application} to confirm that the signal has changed for a sufficient number of kernel loops before passing the signal to the uccnc application, or is the signal being passed point in time?
Rob
Einstein ― “If you can't explain it to a six year old, you don't understand it yourself”
...working my way through the 1000+ ways things don't work to find the one that does
UC400eth, UC300eth, UCCNC v1.2106, Neuron Lite
UCCNC v1.2105 Macro Manual
Robertspark
 
Posts: 1006
Joined: Sat Sep 03, 2016 4:27 pm
Location: Nr Liverpool, England

Re: Unexpected motion during a macro.

Postby cncdrive » Fri Dec 22, 2017 10:24 am

2 cents / 2 pence....

as I understand it

"wait" is not good as everything stops until the wait is completed {time period / logic to change}

"while not equal" allows for other background tasks to complete at least you are not stopping the processor / programme.


Yes, ofcourse a while and Wait is just a Thread.Sleep or Sleeps in a loop which actually not making the whole application to wait, just the current thread (the thread of the macro in this case) is suspended for some time, that does not block the software's other threads to work, ofcourse the GUI and everything else is still working and updating, just the thread with the macro code is waiting then in the loop or in the wait command.

How it works is that when a motion is applied e.g. with a g-code command then the motion buffer counter is immediately set, so even before the motion of the command physically starts the user knows from the ismiving check that there is a motion executed. And when it finished execution motion then the idle bit goes inactive when the motion stopped plus the DROs and inputs and flags read once by the software after that happened.
This way it is guaranteed that the user when checking the ismoving then they can get the proper datas, proper time when the motion really stopped and then when the macro or plugin is reading datas the proper position and other datas already exist on the PC side.
So with checking the "ismoving" it is guaranteed by code design that the datas are not lagging behind.

And if we talking about physical input pins signals state, those are sampled 3 times, a new state is only considered valid by the motion controller if 3 samples are the same. This is how input noise is debounced.
However in the next software release there will be an additional adjustable debounce filter which will be a digitally implemented RC filter with adjustable time constant.
This is already done, just not released yet.
cncdrive
Site Admin
 
Posts: 2297
Joined: Tue Aug 12, 2014 11:17 pm

Re: Unexpected motion during a macro.

Postby Robertspark » Fri Dec 22, 2017 10:38 am

Off Topic....

Is the new release a major issue / update as you seem to have a lot packed into it + the last development release is now the stable release?

Do we have an intended release date? (big kid at heart with hobby, like new toys) :D
Rob
Einstein ― “If you can't explain it to a six year old, you don't understand it yourself”
...working my way through the 1000+ ways things don't work to find the one that does
UC400eth, UC300eth, UCCNC v1.2106, Neuron Lite
UCCNC v1.2105 Macro Manual
Robertspark
 
Posts: 1006
Joined: Sat Sep 03, 2016 4:27 pm
Location: Nr Liverpool, England

Re: Unexpected motion during a macro.

Postby cncdrive » Fri Dec 22, 2017 11:40 am

Hi Rob,

The new release will have several new things including the G41/G42 which required major changes in code, as it requires 4 additonal FIFO buffers to work.
It also contains other changes like the mentioned adjustable inputs debounce filter.
The estimated release date is today or tomorrow, we want to release it prior to Christmas to let you guys play with it in the holidays. :)
cncdrive
Site Admin
 
Posts: 2297
Joined: Tue Aug 12, 2014 11:17 pm

PreviousNext

Return to Report a bug

Who is online

Users browsing this forum: No registered users and 2 guests