Unexpected motion during a macro.

[A_Camera]

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?

[dezsoe]

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. )

[cncdrive]

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]

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.

[Robertspark]

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?

[cncdrive]

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.

[Robertspark]

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)

[cncdrive]

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.

[Derek]

Great and I'm heading out of town for a week Nice timing.

[cncdrive]

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.