is there any function or method in kuka that can forbid a command.

[soft8]

hi,all. is there any function or mothed  in kuka that can forbid a command.in fanuc robot,we can use the "remark" command to let a command become a comment.then the robot will not execute that remarked command. we can use this function to reserve the old command or points,but not delete them.

[mookie]

semicolon will ignore everything on the line after it.

[soft8]

i tried  it before.but  i  could not insert semicolon in the command line.

[kr16_2]

Lines that were created with inline forms you can not comment out.
Reason for it is that they are folders that are already comments that include multiple instructions.
You cannot comment out multiple instructions with single ";"

Exmaple:
inline form like that:
LIN P1  Vel=2 m/s CPDAT1 Tool[0] Base[0]


In a real code looks like that:
;FOLD LIN P1  Vel=2 m/s CPDAT1 Tool[0] Base[0];%{PE}%R 5.6.11,%MKUKATPBASIS,%CMOVE,%VLIN,%P 1:LIN, 2:P1, 3:, 5:2, 7:CPDAT1
$BWDSTART=FALSE
LDAT_ACT=LCPDAT1
FDAT_ACT=FP1
BAS(#CP_PARAMS,2)
LIN XP1
;ENDFOLD

What you can do here is after you open that folder you can comment out LIN XP1 and robot will not move (you comment out motion instruction. However anytime you modified this inline form (by changing point velocity  for example) your comment will disapear

[soft8]

thank  mookie and kr16_2.no other method to realize the function expcept jump?

[MeanRobot]

Wrap the section of code with an IF FALSE THEN statement and it will never be run:

Code:

IF FALSE THEN
;the code you don't want to run
ENDIF

GOTO (jump) is evil and should never be used.  It is even worse then putting WAIT statements in the submit.

[Draconic1287]

GOTO (jump) is evil and should never be used.  It is even worse then putting WAIT statements in the submit.

Would you be able to explain why GOTO is evil?

The reason I ask is that I've used it several times and I've never once had a problem with it working.

[MeanRobot]

I have used a GOTO command before and I was not attacked by raptors nor did the world suddenly end (much to my surprise).  But they are considered bad practice by most.

This is not because they don't work, but because they have a high potential to cause mysterious (memory) issues.  And exponential detriment the readability (diagramming) of the program.  (This can even include the original programmer if it has been a while since they wrote the code.)  This all gets amplified with poor commenting or more than one programmer being involved.

My first aversion came from a Professor who clearly stated that if we ever used a GOTO in his class we would received an automatic F.

Some external reading:
http://www.dotnettoad.com/index.php?/archives/20-when-not-to-use-the-goto-keyword.html
http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html

[py_programmer]

I haven't seen much, but I saw some programs that were based solely on GOTO statements, like "GOTO merker137" all the way down. I think this is standard by this company. I will not name it publicly. This program was horrible to understand or follow whats going where.

Plus obligatory xkcd reference.

[Tuipveus]

But we have to remember that goto-statements are normal and needed in Assembly languages and cpu likes those. 

In KRL,
I program in a way, where IF-statements are describing the special case that is normal, instead of that I would try to trap every single error with number of if-statements. If I have if under each other, in each "if" I add some integer for debugging. This way it is easy to keep track that what condition is not true and I can trigger error for user directly from integer-value.

I have used goto in Quickbasic, Assembly (JZ, JNE for example) and Visual basic. When programming with visual basic (currently excel-macros), there is usefull "on error goto", where goto is necessary part.

In KRL I have never used goto, and never will. Have you heard about KISS-principle: "Keep It Simple Stupid".

So in my opinion goto is sometimes needed, but usually not.

I dont like this either:

IF FALSE THEN
;the code you don't want to run
ENDIF

That makes you think while monitoring with the KCP in the middle of the long code that it is beeing run, but it is not. If you have a lot of lines which you dont need, comment those with ultraedit column mode for example. If you have only couple of lines that might be usefull sometimes, make a boolean variable with definition that variable remembers its value over cold boot and make condition where you can switch parts of the code on or off.