Line break in WorkVisual

if you have something that works and equivalent that does not, why not compare them?

and why not post example here?

btw it does not matter what some offline editor tells you if things are possible or not. KRC is the ultimate judge. don't break line. enable line break on smartPad or restructure your code.

Quote from pavlan1

If I try to break the line in IF statement
I get an error message
16:53:13 Unexpected character string 'Newline' was found.
How can break the line to see entire code in a window?
In OrangeEtid it works well. How does it work in WorkVisual?

Program lines in Kuka robots are in the form of FOLD. Do you know what that means?

that is, only one line appears like "IF" line, but it has bottom lines. it is expanded / collapsed by pressing the "+" at the beginning of the line.

Quote from hydra

Program lines in Kuka robots are in the form of FOLD. Do you know what that means?

But If statements usually aren't Folds.

you still did not answer the questions... where is the "working" example from Orange edit? did you compare the two? how?

in IF statements, IF line need to be complete, not broken... you can use spaces or TABs to push part of the line out until it appears as if it is on a new line. but that is still one line....

this may look better on HMI but will look horrible in a text editor. im guessing that is what you may be observing with OrangeEdit, because OrangeEdit is trying hard to make things look like on HMI (or as close as possible).

that is what programmer need to take into consideration and manage...

for example

IF GripperBroken(2) then

MsgQuit("Gripper 2 is not ok, seem to be broken, take a break everyone")

ENDIF

Quote from pavlan1

Still, if it cannot line break it the big disadvantage of editor or language

Why? Professional programmers generally avoid overly-long lines in favor of function calls. Any time your line gets wider than the interface, that's a sign that it's time to consider greater modularity.

there are many ways to get the job done. this is on programmer to structure code the way it suits him and the application. one reason long lines are not welcome is problems with indentation and making code look nice. then there are things that are out of sight like functions so one can hide complexity (even if it means long lines and wrapping). this allows the real problem (main program) to look nice and clean.

for example you could try something like this

DEFFCT BOOL GripperBroken(GripperNumber:in)
DECL INT GripperNumber

SWITCH GripperNumber
  Case 1
    RETURN FALSE     ; whatever, could be long but this is one line, so what...
Case 2
    RETURN Gripper2_opened_In_1104 and (gripper2_closed_IN_1105 or gripper2_middle_in_1106) or (gripper2_closed_IN_1105 or gripper2_middle_in_1106) or err_G2_Sensors_DO_66 ; yes, this is long one
ENDSWITCH

ENDFUNCTION

btw your logic is not sound, should apply standard technique to minimize your code. any programming course starts with intoduction to basics and basics covers logic...

that includes topics on basic operators (AND,OR, XOR,NOT), DeMorgan's theorem, Karnaugh map etc.

in other words, your expression:

Gripper2_opened_In_1104 and (gripper2_closed_IN_1105 or gripper2_middle_in_1106)  or (gripper2_closed_IN_1105 or gripper2_middle_in_1106) or err_G2_Sensors_DO_66 

returns exactly the same result as

Quote

(gripper2_closed_IN_1105 or gripper2_middle_in_1106) or err_G2_Sensors_DO_66

although the later one is less than a half the length (first line is redundant).

so i would recommend to anyone that is going to program, to take the proper path to learn the fundamentals.

here is another example how one may structure this. i think line 5 makes it as short as possible while readable (purposely used binary form rather than 3,5,6,7):

SIGNAL Grp2 $IN[1104] to $IN[1106]
Decl BOOL GripperSensorsFailed

SWITCH Case Grp2
   Case 'b011','b101','b110', 'b111' ; invalid input combos
       GripperSensorsFailed = TRUE
   Default
       GripperSensorsFailed = FALSE
ENDSWITCH

If GripperSensorsFailed or err_G2_sensors_DO_66 then
   MsgQuit(“yeah, gripper sensors are mess...”)
ENDIF

i would not want to read that...

how about this

SIGNAL Grp2 $IN[1104] to $IN[1106]
if err_G2_sensors_DO_66 or ((grp2 B_AND -grp2)<>grp2) then
  MsgQuit("...")
endif

nice thing about it is that it is short and easy to check and... no end user will try to make a change.

yes, this is probably the most flexible solution.

i guess you are only checking steady state but still... 'b111' is allowed but not 'b000'?

You could checkout $FLAG[] and $CYCFLAG[].

goes something like this:

$CYCFLAG[1] = $IN[1] AND $IN[2] OR $IN[3]

Fubini