Forward or forward?

[TimothyMoulder]

Ron :

First, I apologize. I picked a lousy example Classic case of over-simplification.

In plain english, it goes something like this :

1. No activity. Cylinder is home, on Return LS.

2. Cycle Start State is latched (not shown). This, in turn, energizes output A. Note that output A is not latched, only the state.

3. With the above condition active, watch for Forward LS. When this is seen, turn off Cycle Start State and turn on Forward State, indicating that the machine is now, this instant, in a Forward Condition.

Note that when Cycle Start State is turned off, Output A is also turned off, and the piston begins returning to it's original position.

Hmm...should have specified I was using a single-acting solenoid. Might have been less confusing. Or included a second return valve.

4. When the cylinder, de-energized by the above state change, reaches it's Return LS, turn off Forwad State and turn on Return State, indicating the machine is now, this instant, in a returned condition.

>>Cycle starts but the Forward LS has to the made before the Forward state is latched, this is backwards to me. Maybe its the terms that are throwing me? Is the Forward LS actually the 'home" LS or LS that is at the back of the device that moves forward? If this is so it is backwards to my way of thinking in general.<<

I understand the confusion... heck, it confused me. That's why I brought it up, just sharing the pain

I don't like this approach, because there is a disconnect between the state and the outputs it watches. The output is energized and de-energized in the state PREVIOUS to the active one, which confused the heck out of me.

My reason for posting was, I am all alone in this over here, and I wanted to make sure I wasn't missing something by abandoning this approach.

>>When I looked at Example 2 the ladder and the terms matched actions..to me with the exceptions as follows.
1. What is Output A doing? <<

See above Go ahead, smack me with the "poorly-framed question" stick. But in my own defense, this was a bear of a concept to frame at all.

Eric :

The Nelsons live up to their reputation again You are absolutely right, it is best to program to detect a switch in fail-closed condition as well. My approach would be something like the followng.

I like this method because it keeps the code compact while still simplifying troubleshooting. Simply put, if I know it was trying to do something, why didn't it finish it (advance to the next state)?

Note: the latches are for demonstration purposes only. I use interger sequencing. But all those interger boxes are a #$%$ to draw like this

I    State 1           Output Forward

I------I I----------------( )

I

I    State 1    Forward LS    Return LS     State 2

I------I I--------I I------------I/I---------(L)

I                                      I   State 1

I                                      I-----(U) 

Thanks again!

TM

 

[Eric Nelson]

Compact? Yes, but you now have TWO conditions that must be met to move from state 1 to state 2. Therefore, you still only know that 1.) The cylinder was commanded to move (state 1), and 2.) when the cylinder has reached end of stroke (state 2). Both static conditions. If this is all you need, then that's fine. You've improved the logic by checking that the return LS is OFF, which is always a plus!

Personally, I would take advantage of the fact that there are THREE possible states for the cylinder... State 1.) the request to move, State 2.) cylinder MOVING forward (return LS turns off) and State 3.) cylinder reached end of stroke. This just makes it easier to write the fault detection part of the program. Now you know exactly where the problem is simply by looking at which state you're in. If you're sitting in State 1, then the return LS is staying ON. Sitting in State 2, the forward LS is NOT ON. With your method, if you're sitting in State 1, it might be EITHER switch, so you have to also query the switch(es) status to determine the fault.

Basically, I'm just saying you should take advantage of ALL the information that's available to the PLC. There are even MORE possible states if you look closely. With the above example, if you're sitting in State 1 (waiting for the return LS to turn OFF), the problem could be the switch is staying on OR the cylinder failed to move. BUT, if you're sitting in State 1, and the forward LS turns ON, you can be pretty sure that the return LS is defective, and NOT the cylinder (since it seems to have reached the forward stroke).

This only applies when you make the machine troubleshoot itself (which you should). IOW, you should NEVER have to go online with your laptop to figure out what's wrong with the machine. The machine should TELL you what's wrong with it...