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?
Line break in WorkVisual
-
pavlan1 -
April 6, 2021 at 4:04 PM -
Thread is Unresolved
-
-
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.
-
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.
-
Program lines in Kuka robots are in the form of FOLD. Do you know what that means?
But If statements usually aren't Folds.
-
I would like to have a line break here. for example, because the line is so long
Is it possible? -
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).
-
Ok. It seems I have been using too many editors and languages, and I thought it had worked in OrangeEdit.
But I have just tried in OrangeEdit, it didn't give me an error message but I believe the robot compiler will.
Still, if it cannot line break it the big disadvantage of editor or language -
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
-
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
Code
Display MoreDEFFCT 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:
CodeGripper2_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):
Code
Display MoreSIGNAL 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...
-
-
Code
Display MoreSIGNAL 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
But I liked this solution
I would make so
Case 'b011','b101','b110', 'b001' ,'b000'
and use it later
After the gripper is closed it must be "closed" or middle
else it gives "err_GRP2_sensors_DO66" -
yes, this is probably the most flexible solution.
i guess you are only checking steady state but still... 'b111' is allowed but not 'b000'?
-
i would not want to read that...
I would say so too, but I have to read it
I think this will be the best -
Original version
Code
Display MoreGripperHasBox1 = FALSE GripperHasBox2 = FALSE ;Check the gripper sensors Gripper1_Open_OUT_1101 = FALSE Gripper1_Close_OUT_1102 = TRUE Gripper2_Open_OUT_1103 = FALSE Gripper2_Close_OUT_1104 = TRUE Wait sec 3 ;Gripper1 sensor check IF ((Gripper1_opened_IN_1101 AND (Gripper1_closed_IN_1102 OR Gripper1_middle_IN_1103)) OR (Gripper1_closed_IN_1102 AND Gripper1_middle_IN_1103) OR (NOT Gripper1_closed_IN_1102 AND NOT Gripper1_middle_IN_1103)) THEN err_G1_sensors_DO_65 = TRUE MsgQuit("Gripper sensors are broken", "GRIPPER 1") HALT WAIT FOR FALSE ENDIF ;Gripper2 sensor check IF ((Gripper2_opened_IN_1104 AND (Gripper2_closed_IN_1105 OR Gripper2_middle_IN_1106)) OR (Gripper2_closed_IN_1105 AND Gripper2_middle_IN_1106) OR (NOT Gripper2_closed_IN_1105 AND NOT Gripper2_middle_IN_1106)) THEN err_G2_sensors_DO_66 = TRUE MsgQuit("Gripper sensors are broken", "GRIPPER 2") HALT WAIT FOR FALSE ENDIF ;Save gripper state IF (Gripper1_closed_IN_1102 and Gripper2_closed_IN_1105) THEN GripperHasBox1 = FALSE GripperHasBox2 = FALSE ENDIF IF (Gripper1_closed_IN_1102 AND Gripper2_middle_IN_1106) THEN GripperHasBox1 = FALSE GripperHasBox2 = TRUE ENDIF IF (Gripper2_closed_IN_1105 AND Gripper1_middle_IN_1103) THEN GripperHasBox1 = TRUE GripperHasBox2 = FALSE Gripper2_Open_OUT_1103 = TRUE ENDIF IF (Gripper2_middle_IN_1106 AND Gripper1_middle_IN_1103) THEN GripperHasBox1 = TRUE GripperHasBox2 = TRUE ENDIF
Tomorrow I show an improved
-
yes, this is probably the most flexible solution.
i guess you are only checking steady state but still... 'b111' is allowed but not 'b000'?
The idea in this.
After a robot Init, you don't know if it has a box in the gripper.
You close the gripper and check, if "closed" sensor or "middle" worked
The middle sensor means that box is in.
Of cause all other sensor combinations are wrong, 'b000, b001, b110, b111, b011, b101'
Now, If you know the gripper has no box in the gripper, you open it and check if the gripper opened.
Wait sec 2
If (gripper2_opened_DI_1105) THEN
ELSEENDIF
But OK. Here we got lucky and we can combine Input signals
How to solve it if we need to check combinations of simple boolean variables? -
You could checkout $FLAG[] and $CYCFLAG[].
goes something like this:
$CYCFLAG[1] = $IN[1] AND $IN[2] OR $IN[3]
Fubini