Tips on general setup of program structure

Kreddit

Greetings.
Let me start off by saying that, while not a novice with robotcs, I am new to the ABB environment.
So I am just looking for some recommendations from you more experienced users with regards to the structure of a RAPID task.
My use-case is fairly common, I reckon: One robot services one machine that produces a few different items that should be handled slightly differently, depending on an operator input.
I will use ScreenMaker to have the operator choose what item will be produced, how many, etc.

But how would you recommend I structure the program? I am not using MultiMove, so I gather I have just the one task (T_ROB1), but would you recommend I make one module for each item? Or one procedure for each item? Or a single procedure with a large CASE statement?

I also have some interaction protocols with other equipment that will be the same regardless of the item currently being processed, and would like to be able to call the same "function" (procedure?) to handle this from everywhere.

I'm also curious if you define your variables and positions globally in the "Program Data" menu of the Flex Pendant, or locally inside your modules or procedures.

In short, I am just hoping for a few words on how you usually structure your own programs, and why.

graemepaulin

I think you will get a different answer from each person, as everyone does it slightly different.

Modules can be loaded and unloaded but procedures can not - so that may dictate the use of a module over a procedure.

How complex the code for each item is would determine if each has its own module or just one procedure.

That said breaking the code into small logical procedures makes it easier to follow, and then grouping the procedures for an item (or other task - eg PLC communication) into a module.

I tend to make all my variables global but you can make them local if you want to -where the data is actually stored and if it is local or global is part of the data declaration when you create the variable from the teach pendants "program data" (different if you are using RobotStudio).

lemster68

Just because you do not have multimove does not mean that you have only one task.  If you have the multitasking option then you can create other tasks if you need them.  In some cases, very useful.  I worked a job years ago that had one procedure per module, a real pain to follow in the pendant.  Routines all related to one part or style declared in one module is good.  Functions and PLC comms can go together in a System module.  Data declaration can be global or local to the module for each part.  At times it is necessary to have data local to a routine or function to make it work right. I would not go with the large CASE statement, use a Main (you have to have main, of course), but in the main call out procedures resident in each part module, and work your way through with that.  Learn about ERROR handlers, don't make spaghetti code with a bunch of labels and goto.  You will be one step above many if you do that much.

nomad5t5

lemster68 said:

Learn about ERROR handlers, don't make spaghetti code with a bunch of labels and goto.  You will be one step above many if you do that much.

Agreed!

EricH

I try to uncouple functionality into different independend modules with high cohesion. Also try to break complex problems into smaller ones.