Program structure

robot_newbie_101 · April 11, 2016 at 1:03 PM

I have a question..

New to robots and used to program other things I have a certain way to structure my programs..
Usually I do my non robot programs as a state machine for example (Siemens SCL language below):

Code

case state of:


0: //Init
//Do something
//Change state
state := 10;


10: //Done
//Last state set done flag wait for Ack
done := TRUE;


end_case;

Display More

I was thinking about structuring my robot program something like this (Please disregard the faulty syntax)

Code

Repeat


Case state of:


0: //


10: // do movement
PTP xxx
if sensor then state := 20
else state := 40
end_if




Until done

Display More

I dont se why it wouldn't be possible but is there any flaws or disadvantages doing a robot program this way.
I will refresh my memory with some manuals later but i thought you pros had some suggestions.

ljuba · April 11, 2016 at 9:39 PM

Definitely you do not have enough memories to reserve 1 for each sensor. I think that the part of your structure is fine. Like if sensor=true then...
But not set the memory when the state of sensor change.

**SkyeFire** · April 11, 2016 at 11:29 PM

Not clear on what you are trying to do here. Is this supposed to be a loop? Or are you placing this SWITCH statement inside of a loop that's not visible in these examples?

In your second example, "done" never gets set anywhere, so that won't work.

If you're looking for loops, you want to grasp the difference between rejecting and non-rejecting loops. A non-rejecting loop checks the loop condition at the bottom, and will always execute at least once:

Code

REPEAT
  ; even if 'Done' is True before reaching REPEAT, this will execute at least once
UNTIL Done

A rejecting loop checks at the top of the loop, and may not execute at all:

Code

WHILE NOT Done
  ; if 'Done' is True before reaching WHILE, none of this code will execute
ENDWHILE

robot_newbie_101 · April 12, 2016 at 4:17 AM

Quote

Not clear on what you are trying to do here. Is this supposed to be a loop? Or are you placing this SWITCH statement inside of a loop that's not visible in these examples?

Yes in a loop. Sorry for incomplete examples just trying to explain the concept of what I wanted to do. (English isn't my native language either so having a hard time explaining).

This is a good example of a state machine design:
http://m.eet.com/media/1174905/f-gomez.pdf
And I want to use a tecnique like this to implement my robot programs. As this is what I am used to compared to flowcharts. The Case switch would be an easy approach if there isn't any disadvantages having the robot program inside a case statement inside a loop.

The question in short is- I want to place my robot program inside a case statement inside a loop when certain transition conditions are met I change my state and execute another "choice" in the case. Are there any disadvantages to this approach?

So if there isn't any disadvantages doing something like my example for an easy state machine I would be glad.
The state machine should always be executed until the program is done, the state machine could call subprogram containing state machines in them as well.
A little better Example of code: (Please disregard syntax errors and only see this as a concept example)

Code

State = 0
Done = false
Repeat
   Case state of
      0:
      ;Go to pre POS
      Ptp pre
      State = 10


      10
      ; if part detected grab it
      If part_detected then
         Grab_part()
         State = 20
      Else
         ;All parts taken do something before done
         Do_something()
         State = 100
      End if


........
........


      100:
      ; Program done
      Done = true
   End switch
Until done

Display More

Hope this clears things up a bit if not I should do a complete example with state diagram and code to show clearly what I mean.

**SkyeFire** · April 12, 2016 at 3:49 PM

Ah, state machines. Okay, that clears things up.

Yes, implementing a state machine in KRL is possible. I've done it more than once. And yes, usually I use the SWITCH statement inside of a loop. As with most other functional languages, the biggest issue with coding an SM in KRL is ensuring that your loop never stops, or gets "hung up" in one particular step. A very simple KRL state machine might look like this:

Code

DECL BOOL StateMachineExit
DECL INT StateMachineState
StateMachineExit = FALSE
StateMachineState = 0
REPEAT
  SWITCH StateMachineState
  CASE 0
    PULSE ($OUT[1],TRUE, 1)
    IF NOT $OUT[1] THEN
      StateMachineState = 1
    ENDIF
  CASE 1
    IF $IN[1] THEN
      StateMachineState = 2
    ENDIF
  CASE 2
    PULSE ($OUT[2], TRUE, 1)
      IF NOT $OUT[2] THEN
        StateMachineEnd = TRUE
      ENDIF
   DEFAULT ; unhandled CASE values
     HALT ; error -- state machine should never get here
   ENDSWITCH
UNTIL StateMachineExit

Display More

That's a very simple SM -- once started, it would pulse $OUT[1] for 1 second, stay in State 1 until the pulse was complete, jump to State 2, stay in State 2 until the input $IN[1] went True, then jump to State 3, pulse $OUT[1] True again, and remain in State 3 until the pulse was finished, after which the loop would exit. The key factor here is that the program pointer never stops moving -- there are no WAIT statements, or inner loops, or other conditions that could ever cause the program pointer to stop cycling through the entire SM from top to bottom.

**panic mode** · April 12, 2016 at 3:58 PM

that will work fine, i use it all the time to make sequencers in KRL. you may have an issue with robot stopping at each point (advance run pointer stops). this can be remedied the conventional way as presented in programming courses.

robot_newbie_101 · April 12, 2016 at 4:35 PM

Great. My life just got so much easier..

Yes the advance run I need to print out the document which instructions stop the advance run so I don't forget to handle those cases.

Thank you all.

Program structure

Advertising from our partners

Anyware Robotics is hiring!

How to see your Job Posting (search or recruit) here in Robot-Forum.com