Using CONTINUE before a WAIT SEC instruction in a loop

Quote from mudanda

I am programming a while loop in a sequential program, which is used to wait for a mission request from a master plc.

so the signal you are evaluating is an input... controlled by PLC. unlike other variables, IO are evaluated by main interpreter to avoid risk of collision. of course programmer can influence this but care shall be taken to avoid mentioned pitfall...

Quote from mudanda

Is it useful to add a WAIT SEC instruction (with a very low time, such as 0.1s) to reduce the load on the processor?

maybe...

when programming multithreaded applications, it is common to place small delay into loops so that CPU resources would not be hogged. basically using something like Thread.Sleep(10) inside the loop would let the CPU catch a breath for 10ms rather than spinning in the loop. and if something else needs the resources, CPU could be processing those other things for the duration of those 10ms intervals before returning to original thread. this is particularly easy to see in GUI applications where in case of loops, UI becomes non responsive.

but... the thing is that implementation of WAIT command is not known. there are no tools for robot programmer to see CPU utilization, also this is running on RTOS anyway and robot interpreter seem to be a single thread.

the best way to see is something is useful or not is to compare results with and without it. i do not recall any observe difference... but... that does not mean that it does not exist.

Quote from mudanda

I have added the CONTINUE line above because the main run pointer may still be on the last motion instruction of the previous program, but I want motions between missions to be connected without stopping the robot.

as mentioned at the begin, this is for programmer to consider and implement safely.

Your question could also be interpreted that you are seeing non blended motions when changing from subprogram to subprogram and you want to fix this as Panic says by generating more calculation time inside the realtime system. Of course your problem can be a performance issue but it is not most of the time. If it really is the problem it should go away when you test the same routines with a small override e.g. of 10 percent. Most of the time the problem is an advance run breaking instruction inside your subprogams. How do your subprograms look like? If e.g . they start with a INI Fold you would get definetly an advance run break.

Fubini

Quote from mudanda

the subprograms do have a INI Fold...Does it really stop the advance run?

Absolutely Yes. As already told, why do you doubt.

In my experience a wait sec on a loop doesn't make sense on kuka bots. Has no effect, but stopping the advance pointer. On abb robots it's a different thing.

code only does something if executed. programmer can influence if and when INI fold is executed. having INI fold can be useful so removing it is not always the best choice. and there are times when INI fold should not be part of some routine (ISR for example). if INI fold is needed, one workaround is to wrap it into "IF $MOVE_BCO THEN"

Quote from mudanda

My original question was mainly referred to the possible effects of a WAIT SEC instruction in a continuous loop.

Following a CONTINUE with a WAIT command basically renders the CONTINUE moot. The only thing that CONTINUE does is prevent the next instruction from breaking the Advance Run Pointer, but a WAIT command always breaks the ARP, regardless of whether it is preceded by a CONTINUE.

So deleting that CONTINUE command would have no effect on the program execution.

As to running a continuous loop, I've never found KUKAs to have an issue with that, unlike some other brands. I've used a lot of

WHILE NOT bEndCondition

ENDWHILE

loops as "wait" conditions in KRL programs without any issues, with no code between the WHILE and ENDWHILE lines. Never caused a problem.

i would not say that... my understanding is that only instructions processed by main pointer may trigger advance run stop - instructions processed by advance run pointer do not stop advance run pointer.

consider one simple block of instructions - no branching or loops, just a list of instructions that is executed once.

well, in that case each of instructions in that block is also executed exactly once...either by main pointer or by advance run pointer.

when interpreter encounters CONTINUE in that block, it passes processing of the next program line (hopefully an instruction) to the advance run pointer. - even if that instruction is a WAIT command...

Hm... interesting. I'm honestly surprised -- I expected the WAIT command would still break the ARP.

Instead, it would appear that the CONTINUE lets the WAIT command start executing in advance, and if the WAIT time is small enough, the ARP doesn't get broken. I have to wonder what the relationship is between $ADVANCE, the WAIT time, and the motion time before that code starts breaking the ARP, though. Seems like it could get rather unpredictable, especially as the robot's speed varies.

In the OP's case, with the CONTINUE-WAIT inside a non-motion WHILE loop, I imagine its gets trickier -- if the WHILE is preceded by motion commands, the first few executions of the loop might happen in the ARP, but once the MRP catches up with the ARP (assuming that happens), then the MRP should get "hung" at the WAIT for the WAIT SEC value every run of the loop, perhaps minus one IPO cycle.

Quote from SkyeFire

... it would appear that the CONTINUE lets the WAIT command start executing in advance, and if the WAIT time is small enough, the ARP doesn't get broken.

yup... ARP does not stop on its own, it is always trying to stay ahead. it gets stopped by something that main pointer encounters. in this case motion planner is looking for next thing to process and if next motion data is not available, motion stops to give time to ARP... so ARP can finish whatever it is doing and return to its primary job - fetching data for motion planner. then main pointer can continue running.