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: 638
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: 2049
Joined: Sun Mar 12, 2017 4:41 pm
Location: Csörög, Hungary

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: 4695
Joined: Tue Aug 12, 2014 11:17 pm

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: 4695
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?
Robertspark
 
Posts: 1892
Joined: Sat Sep 03, 2016 4:27 pm

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: 4695
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
Robertspark
 
Posts: 1892
Joined: Sat Sep 03, 2016 4:27 pm

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: 4695
Joined: Tue Aug 12, 2014 11:17 pm

Re: Unexpected motion during a macro.

Postby Derek » Fri Dec 22, 2017 5:57 pm

Great and I'm heading out of town for a week :) Nice timing.
Derek
 
Posts: 341
Joined: Mon Sep 05, 2016 9:57 am

Re: Unexpected motion during a macro.

Postby cncdrive » Fri Dec 22, 2017 11:05 pm

Hi Derek,

I will also leave tomorrow for the holidays, so I will push the software release out and will leave you guys playing with it while I'm away.
So, you are not late if you will only start testing after the holidays. :)
cncdrive
Site Admin
 
Posts: 4695
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 19 guests

cron