forum.cncdrive.com

Hi Balazs,

successfully did hooked up tests on the G28.1 command, all good. Now I'm writing a simple macro for my TOUCH OFF screen button.

I've noticed many people put put exec.wait(200); after while(exec.IsMoving()){}

Code: Select all

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


Sometimes wait() is there and sometimes it isn't. When would it be necessary and when would it not be. Is it normally used only when there is some physically moving equipment that has weight, inertia, etc, or is it sometimes necessary with "software only" code.

Keith

I am not Balázs, but...

In a loop it is good programing practice to let other tasks in while you wait for the trigger. It does not matter if moving is involved or not, but especially in an event that can take some time to execute, like moving, it is good to let Windows in and not block execution of other tasks.

Hi Keith,

The wait like it was written in your post is not really required, because when the movement stops that flag comes back the same time to the PC side as the axis coordinates update, so even if you want to work with the current coordinates in the next command is still fine without the wait.

There can be cases though when the wait is needed, e.g. if you command a movement and wants the macro to wait while the axis is moving.
If you place a loop which checks the Ismoving right after the motion command then it is not guaranteed that the motion already started when you start the Ismoving loop,
it is possible that the macro code execution already left the ismoving loop before the motion even starts.
This is because when you command a motion then the software has to send the command to the motion controller, so there can be upto 20msec delay between you executing the motion command and when the motion starts, so you will need to wait a bit there. If you wait more than 20msec before checking the ismoving in a loop will be always fine.
Another solution would be to do a while(!exec.IsMoving()){} and after a while(exec.IsMoving()){} , then your macro will wait only the required time and no more, but the problem with this is that if before the !Ismoving loop the macro is stopped by the user and so the motion does not starts at all, then your code execution will stuck inside that loop.
The solution is to place another loop inside and look for the macrostop variable and break out of the loop if the macro gets stopped, so the loop will never wait infinately.
Placing a wait is ofcourse simpler and the code is shorter and in most of the cases if the macro waits for 0-20msec more with using the wait command than it is really required is not a problem.

Also there can be cases when you just want to wait, because you don't want things to happen too fast, e.g. wants to observe the happenings.

Thanks Guys (great detailed explanation Balazs),

A_Camera,
you lost me with your explanation, when you said while in a loop it's good to let other tasks in while you wait for the trigger. The Wait() comes AFTER the loop so has no effect on the loop, it's just a subsequent piece of code.

And are you saying a while loop in a macro will block any other Windows tasks. I thought the multi-threading in Windows would mean that didn't happen.

Or have I misunderstood you.

Keith.

Keith,

And are you saying a while loop in a macro will block any other Windows tasks. I thought the multi-threading in Windows would mean that didn't happen.

Well, actually you could overload the computer from any threads in a Windows program, but the Ismoving function has a short Thread.Sleep is why overloading can't happen.
But if you create a loop which do something continously without a Sleep then that will overload the CPU, at least it will overload one core of the CPU.
However the purpose of the Wait is not there for this reason...

Terry,

What the .Codesync differs in from the .Code is that it will not execute if a Codesync call is already running.
If I recall we needed this function when writting the 3D printer plugin.
And no it does not replace the possible need for a wait.

The Ismoving reports false (not moving) if the motion controller is in idle and the motion buffer is empty, so there is no future codes to be executed.
And things depends on what you updating, e.g. if you updating a DRO which has nothing to do any motion then there is absolutely no need to seport a moving,
because a DRO can be updated e.g. from a macroloop while motion can happen asyncronously and possibly that DRO has nothing to do with the motion.

beefy wrote:
The Wait() comes AFTER the loop so has no effect on the loop, it's just a subsequent piece of code.

My mistake. I thought that it was a typo and the wait timer was inside the loop. Normally I set a wait timer inside the loop to prevent the loop to be repeated far too often, but that is not always necessary, though it is good practice.

beefy wrote:And are you saying a while loop in a macro will block any other Windows tasks. I thought the multi-threading in Windows would mean that didn't happen.

Windows is OK without wait() in a macro, you should not be able to lock it.

Thanks again Balazs & A_Camera,

to anyone reading this, another thread that has similar info is:

viewtopic.php?f=14&t=84&p=340&hilit=CODESYNC#p340

Keith