Do you really want to be able to do recursive functionality within the worst debug-able programming language that was ever created?
Think what happens when an error occures and you end up with an infinite loop - only WOV could help you on cleaning that up.
My suggestion is this - use a while true loop and write a method that accepts generic position and returns true/false or whatever return values you need
I'd also add an interrupt that will run every couple of seconds making sure nothing got stuck in the while true loop.
Good luck,
Aval Hen:)
I don't see why not but keep in mind that call stack is 20 layers deep.
Let's see...
DEF FactTest()
MsgNotify("Factorial of 5 is %1","PanicMode",Fact(5))
END
; local factorial function, for example
; 5!=1*2*3*4*5=120
DEFFCT INT Fact(x1:in)
DECL INT x1
IF X1>1 THEN
RETURN X1*FACT(X1-1)
ELSE
RETURN 1
ENDIF
ENDFCT
... the worst debug-able programming language that was ever created?
.. only WOV could help you on cleaning that up.
hmm, I needed to think about these two... 
there is a variable monitor, variable overview, Motion-Step and Single-Step mode, HALT command, caller stack and interrupts view.... that is pretty
worst debug-able? I don't know, I've seen and worked on quite few things, some have pretty long wound way of seeing result, VHDL comes to mind.
I guess WOV is WorkVisual, I am not sure how that would help since it does not execute code, it does little more than check syntax. can you elaborate?
hmm, I needed to think about these two...
there is a variable monitor, variable overview, Motion-Step and Single-Step mode, HALT command, caller stack and interrupts view.... that is pretty
worst debug-able? I don't know, I've seen and worked on quite few things, some have pretty long wound way of seeing result, VHDL comes to mind.
I guess WOV is WorkVisual, I am not sure how that would help since it does not execute code, it does little more than check syntax. can you elaborate?
Zeev is planning on writing a program which is part of a system that cannot be facing major bugs - every little bug is crucial - and will probably run on AUTO. so any debugging within the smart pad are nearly impossible.
Sorry if that insulted you but compared to modern programming language - KRL - is not programmer friendly - the fact there are external monitors for variables and interrupts that is the actual problem - you can't run code with break points and see dynamic, local, global variables during the actual break point and change the code in run-time.
Regarding WOV - I wanted to let Zeev be notified of the fact that incase of a recursive dead-lock he must use WOV to load new fixed code (ofcourse after he succeded in finding the bug)
I was in no way offended, merely curious about what you meant. have you run into case where deploying WoV project was the only way to recover?
Dear Hen,
Debug? Hmm....
what i wanted to do is using a technique called "BACKTRACKING" using recursive function.
in that way i can find the best way to take two or one box in palletizer method.
i think i will try what PANIC said, and wrote the method 
I have not tested posted code but I am pretty confident that it would work since it is so simple.
as far as my programming knowledge extends, deadlocks are only issue when multitasking, kuka robot program is a single task.
some things are easier solved with recursion but use your judgement, note that there are always one or two interrupts in every INI, call stack is only 20 levels etc. test the code. I always include my own diagnostic in everything I code or I make sure that things are solid. good luck...
recursive deadlock occrues when a certain state does change in the recursive state machine and causing the recursive function to be called infinite time with no way of breaking it.
yes - WOV is the only way to repair such a bug - ofcourse you can just halt the process using the smart pad but only with WOV you could change the code that is causing the recursive lock.
Zeev - let us know what you ended up doing - i still think using a loop will be a better solution
yes - WOV is the only way to repair such a bug - ofcourse you can just halt the process using the smart pad but only with WOV you could change the code that is causing the recursive lock.
Why use Work Visual? Why not just change the code using the smart pad? I always do that, when I don't need to make big changes... You can even connect mouse and keyboard to the smart pad [emoji1]
In that way you can also modify the program while it is running...
/RoboticsMan
Why use Work Visual? Why not just change the code using the smart pad? I always do that, when I don't need to make big changes... You can even connect mouse and keyboard to the smart pad [emoji1]
In that way you can also modify the program while it is running...
/RoboticsMan
Sweet. never tried it - will try it next 
Hi RoboticsMan!!!
I am curious to know how we can change the program while it is running. Never did so.
Thanks
Hello RS
Not all changes will work, but recently I added a call to a gripper-control function while I was running a program. I was running the program one movement at a time. I typed in the name of the function, block-selected the movement above the new function call, and continued the program. It worked fine, as far as I remember. More advanced things, like if-statements might not work (not until you close and restart the program).
I guess that it is also possible to insert new movements in the program while it is running. Can't remember if I ever did that.
Note: the changes probably won't work if the advance pointer is too far ahead in the program.
/RoboticsMan
(pedantic voice) Point of order: that's not changing the program while it's running, it's changing the program while it's selected. The distinction is important.
But, yes, RM is correct: you can do this, under some circumstances, but there are limits. Basically, if you change anything in the SRC file while the module is selected, as soon as you move your cursor off the line you just edited, the program will undergo an immediate re-compile. Which is why you can't do multi-line statements (Like IF/ENDIF) -- as soon as you try to move down to type in the second line, the re-compile will fail because you'll only have half of the pair.
Regarding WOV - I wanted to let Zeev be notified of the fact that incase of a recursive dead-lock he must use WOV to load new fixed code (ofcourse after he succeded in finding the bug)
No, WorkVisual would not be required. Program code be be modified on the SmartPad directly, or offline using a text editor and the modules re-loaded via network or USB. WorkVisual is only required for robot configuration changes, like setting up external axes.
(pedantic voice) Point of order: that's not changing the program while it's running, it's changing the program while it's selected. The distinction is important.
Yes, You are right, and actually I also thought about specifying that when I wrote my post. Changing the code of a running program is probably difficult, no matter which language it is written in. You have to finish making the changes, before the program pointer catches up with you
/RoboticsMan
Yes, You are right, and actually I also thought about specifying that when I wrote my post. Changing the code of a running program is probably difficult, no matter which language it is written in. You have to finish making the changes, before the program pointer catches up with you
/RoboticsMan
Now I got it. I was bit surprised to read that. I experienced this that we may change the motion commands and some other stuffs while the src file is selected but not command line statements.
Thanks
