Program structure

  • 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):

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

    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.

  • Place your Ad here!
  • 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.

  • 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:

      ; 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:

    WHILE NOT Done
      ; if 'Done' is True before reaching WHILE, none of this code will execute
  • 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:
    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)

    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.

  • 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:

    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.

  • 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.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now

Advertising from our partners