Output on until Input is off

[flatcurve]

No matter how many times I tell my controls guy that it's not ideal for me to program a fanuc to leave an output on until it sees an input turn off, he still manages to do this to me with every workcell he puts a PLC in.

Right now I do it like this:

1: DO[1]=ON
2: RUN CLEAROUT

and the CLEAROUT program (non-motion, ignore pause) is:

1: WAIT DI[1]=OFF
2: DO[1]=OFF

Is there a better way that won't interrupt motion?

[cobenson]

As a PLC guy myself, I would tell him he needs to do it or it will slow down cycle time.
Not sure how critical to the rest of the job if this input doesn't come on. What will it affect for the robot?
Otherwise I would just pulse it to the plc and tell him to do it in the plc.
  I don't think I would call up the other program. You are still just waiting for this DI to be on anyways. So I would just put those 2 rungs after the DO1=ON. Unless you are doing it multiple times in the program.

The only other option is a background program.

[flatcurve]

Well the robot is loading a machine that we built. It goes like this:

- Robot picks part from infeed conveyor

- robot brings part over to machine and waits for the "ready to unload" input to turn on (it will normally be on by the time the robot gets there)

- robot unloads finished part with other side of tool

- robot loads new part, retreats and turns on "part has been loaded" output

- PLC on machine waits for that output to turn on before it turns off the "ready to unload" input and begins work on new part

- while that's going on, the robot takes the finished part to the outfeed conveyor and cycle starts over


So the robot has stuff to do. It can't just sit around waiting for the PLC to turn off that input, unfortunately. It's a very quick cycle. I told him that I just wanted to pulse the ouput, but he doesn't want me to do that.

[cobenson]

All the more reason not to do it in the robot.

I would surely think you could convince the plc guy that he has to do it in the plc.

Why hold you up???

[Jim Tyrer]

You could use two OPs, and strobe first OP to set a latching PLC rung true, and strobe the second OP to set it false.

Or get the PLC to send you status of the sensors, and control of the tooling, and do it all with the robot.

You could also set robot outputs false in the recovery routine.

[Professor_J]

Well, when I worked with robots, which I don't anymore - I was the PLC guy and the robot guy! Problem solved..!

[potis]

in my opinion the plc guy is doing it the right way. you should avoid using pulses for safety reasons. imagine that one machine stops and the pulse is lost then you might have collision. using a run program is ok but i suggest like cobenson to write a backround logic program to control these signals. if i remember correct you cannot write a wait instruction but you can use if instruction. it is better to do it that way but remeber that if you do it that way the backround logic continues to run even if the robot stops.

[flatcurve]

you mean like a condition monitoring program?

[fanuc_insider]

So you're waiting for him to acknowledge your loading of the part or did I miss something? If this is the case not sure why the robot would have to do this. I've done many jobs like this and always pulse output. PLC has to latch pulse in. Usually turn a an output loading "specific machine" once the loading process is done turn off loading output and pulse a clear. I would use the same clear of machine output but would use specific outputs for loading and unloading when multiple machines were involved. Why does the plc guy need to do this?

[potis]

you mean like a condition monitoring program?

search for backround logic in manuals. it is a robot program without moves and waits that just controls i/o's, registers, making calculations etc and runs continuously like a plc. you can control fe a complex gripper, exchange variables with a plc  etc even if the robot program is paused or stopped.

[Professor_J]

If I were to hazard a guess I would suggest the PLC program is some sort of weird step / sequential type program (instead of a continual cyclic scan) and the PLC may not be looking for the offending signal at the time you send it... He therefore needs you to hold it on until he acknowledges he's received it.........

Poor PLC programming in other words...

[flatcurve]

you mean like a condition monitoring program?

search for backround logic in manuals. it is a robot program without moves and waits that just controls i/o's, registers, making calculations etc and runs continuously like a plc. you can control fe a complex gripper, exchange variables with a plc  etc even if the robot program is paused or stopped.

Thanks for this advice. BG Logic is something I haven't used yet, and I am already going through some old stuff and revising the programming with it. However IF assignment statements will only work if the condition is true... i.e. I can't tell it to turn off an output once an input is off, or false in other words. Unless there's an elegant way around this that I just haven't seen yet. Ideas?

If I were to hazard a guess I would suggest the PLC program is some sort of weird step / sequential type program (instead of a continual cyclic scan) and the PLC may not be looking for the offending signal at the time you send it... He therefore needs you to hold it on until he acknowledges he's received it.........

Poor PLC programming in other words...

I agree... however he's one of those "I've been doing this for 30 years" guys. I've been programming one language or another since I was in 1st grade, but I don't brag about it or use it to convince people that I'm right. I'm not above trying something different or learning something new if it works better. Heck, I just learned about BG Logic. (although to be honest I feel like I should have known that.)

[flatcurve]

I can't tell it to turn off an output once an input is off, or false in other words. Unless there's an elegant way around this that I just haven't seen yet. Ideas?

wait, I think I figured this out...

1: R[1]=1
2: IF (DI[1]), R[1]=(0)
3: IF (R[1]), DO[1]=(OFF)

That should work, right?

[JonnyRotten]

I've written background monitoring programs to do this.
Basically one line should do it.

DO[11:RH ESCP B STATION]=(!(DO[10:RH ESCP A STATION]))


I had an escapement on a pneumatic turn table. I couldn't fire the A station without turning off the B station, and vice versa.
Since they didn't line up in the outputs so that I could make them complimentary, I had to resort to this.

[flatcurve]

But that logic would have my output always complimentary to the input, right? The issue is I can't just turn the output on when the input comes on. The output is the signal for the machine to start running. So there's a window there when the part is being loaded that my output needs to stay off. I think my logic will work, because my output can only come on after it sees the input on. So it won't get turned off by the BG logic until after that input turns off, because while the input is on, R[1] is being set to false, preventing it from turning off the output.

At least, that's how I hope it works. I'm about to try it out in roboguide right now.