ONE Robotics Company

TP programs should be readable. If an operator can step through the code and understand it, you might be able to avoid a phone call when the robot inevitably misbehaves. Lately I’ve been simplifying complex conditionals into unique flags to keep my programs short and simple.

Let’s say you have an application where the robot needs to unload one machine and then load another machine. The part out of machine 1 is hot so you want to wait until both machines are ready before unloading the first machine. You might have a line of code that looks like this:

  WAIT (DI[10:Machine 1 in auto] AND DI[11:Machine 1 service request] AND
  DI[12:Machine 1 part present] AND DI[20:Machine 2 in auto] AND
  DI[21:Machine 2 service request] AND !DI[22:Machine 2 part present])
  TIMEOUT,LBL[500] ;

It’s very clear that all 6 conditions need to be true before machine 1 gets unloaded, but it’s a little long. Why not simplify these conditions into a couple flags?

I wrote about FANUC’s BG Logic option earlier this year. It basically allows you to create programs that are constantly scanned in the background, kind of like ladder logic. Flag IO ports are simple ON/OFF boolean states that don’t go anywhere unless you map something else to the same rack/slot/port.

Here are a couple lines of BG logic code you could write to simplify the case outline above:

  F[1:Machine 1 ok to unload]=(DI[10:Machine 1 in auto] AND
  DI[11:Machine 1 service request] AND DI[12:Machine 1 part present]) ;

  F[2:Machine 2 ok to load]=(DI[20:Machine 2 in auto] AND DI[21:Machine
  1 service request] AND !DI[22:Machine 2 part present]) ;

…and here’s how the updated TP program might look:

  WAIT (F[1:Machine 1 ok to unload] AND F[2:Machine 2 ok to load])
  TIMEOUT,LBL[500] ;

Your code is now simpler and easier to read. Semantically, it’s easy to understand that you’re waiting to unload machine 1 until 1) machine 1 is can be unloaded and 2) machine 2 can be loaded. If you ever want to unload machine 1 regardless of machine 2’s status, you can simply remove the condition on F[2]. There’s a little bit of indirection here, but hopefully you list the underlying DI signals in the error HMI screen that pops up at LBL[500].

It’s always a balancing act between duplication and indirection, but as long as your program is still readable and the intent is clear, you should be ok. If you plan out the BG logic in advance, you’ll probably even save yourself a few keystrokes while programming the rest of the project.