How to evaluate conditions for sequence progress?

Bartech

Member
Join Date
Jul 2012
Location
Italy
Posts
14
Hi all,

I'd like to know your point of view on this aspect of PLC programming, the example I use is simple, but the concept can be applied to more complex systems.

I have a simple pick and place system which moves the objects from a position A to a position B.
The hardware is:
- a cylinder for horizontal movement
- a cylinder for vertical movement
- grippers


The sequence should be like this

Step 0 (evaluate conditions for start the sequence):

- object present in position A
- grippers open
- grippers over position A
- grippers up position


Step 1:

- grippers go down
- Wait for sensor down

Step 2:

- grippers close
- Wait for sensor grippers closed

Step 3:

- grippers go up
- Wait for sensor grippers up

Step 4:

- Translation of grippers to position B
- Wait for sensor position B reached

Step 5:

- Check if position B is free (no object present)

Step 6:

- Grippers go down
- Wait for sensor down

Step 7:

- Grippers open
- Wait for grippers open

Step 8:

- Grippers go up
- Wait for sensor up

Step 9:

- Translation of grippers to position A
- Wait for sensor position A reached

Step 10:

- End of cycle

Ok now the question:
We are on step 2, and we must control the closing of the grippers. What conditions have to evaluate?
(grippers on position A) + (grippers down) + (grippers open)

or only evaluate the condition of grippers down, as the other conditions we had tested during the step immediately preceding?

What I'd like to understand is this: to control a single movement of a cylinder must evaluate
ALL the conditions to do so at that moment, or I take for granted that if I arrived at that step conditions are present surely?

Again, to exit from step 2: I have to evaluate (grippers on position A) + (grippers down) + (grippers closed),

or I have to evaluate only (grippers closed), because I already evaluate (grippers on position A) + (grippers down)?

thanks a lot, sorry for confusion!

Bartech
 
Nice question!

Good job on laying out your sequence. If only everyone would think things out this far prior to coding.

I personally make each of my steps check for one and only one condition. This is because of how I dermine my fault codes.

There is merit to checking all of the necessary conditions each step, and there may be certain instances where it might even be necessary. I usually just make a special case out of these.

In your above sequence I would also have checked for leaving the source prox switch prior to looking for the destination prox. I would also have check for part present to have transitioned OFF after starting up vertical to make sure the part traveled with the grippers.

I am interested myself to hear the others philosopies on this. Of course if there is risk of damage or the consequences are severe you will want to re-check all your conditions in those situations.
 
You should indeed monitor every sensor that were previously conditions in the sequence.
You have to make an evaluation for each single state, because the previous conditions change for each state.

I think that you should decide a strategy what to do if a previous condition goes out of its proper state.
There are two possible strategies (as far as I see it).

1. Force the operator to reset the machine and start the sequence all over. This will maybe mean that one part will be lost, which again may be a big deal or not. This is fairly easy to do:

Code:
(init) <--(reset)
|
|[condition 1]
|
(state A) ---[condition 1 OFF]-->(request operator reset)
|
|[condition 2]
|
(state B) ---[condition 2 OFF]-->(request operator reset)
| 
(etc ...)
2. Go to in intermediary state, where the operator can be allowed to fix the problem, and then possibly decide to continue from state x.
It would mean that you should have a "faulted" state for each "normal" state. Something like this:

Code:
(init)
|
|[condition 1]
|
(state A) ---[condition 1 OFF]------------------->(faulted A)
(state A) <--[condition 1 OK + operator start]----(faulted A)
|
|[condition 2]
|
(state B) ---[condition 2 OFF]------------------->(faulted B)
(state B) <--[condition 2 OK + operator start]----(faulted B)
| 
(etc ...)
In the above, not all conditions may actually mean to be a fault if they go off. You have to evaluate that for each state.

edit: One might complain that it gets awfully complicated, and that a nice linear step diagram becomes a tangle of states. But thats what separates a merely functional program from a good program.
The functional program works well as long as nothing goes wrong.
The good program catches and handles all the abnormal situations without falling over.

Has anyone ever heard about operators having to remove all power from the machine, clear the program and read in the eprom, and move the actuators back to the initial state, before starting again, only because the program cannot handle the abnormal situation ?
 
Last edited:
One additional "feature" could be to allow the operator to move back and forth with the actuators, for example to open up for being able to get in and pry a stuck part loose. This should be allowable only from a faulted state.

In the above example, if state A is "moving down", and state B is "in down position", then there should be for example a "state C - move up" with transitions from both "faulted A" and "faulted B", and with transitions to states init, A and B.
 
I always add a timer for each step to make sure the sensor's change of state occurs within an expected timing window. It's another fault that will require operator intervention and you can alert them to "fix it" faster since sometimes they are not paying close attention to the process.
 
We are on step 2, and we must control the closing of the grippers. What conditions have to evaluate?
(grippers on position A) + (grippers down) + (grippers open)
A simple method is to set a Step Relay for each step. When entering that Step, turn on the Step Relay for it. When leaving turn on the next Step Relay, and turn off the current Step Relay. Then say when Step 2 Relay is ON, you only have to worry about the gripper close output and the gripper closed sensor.
 

Similar Topics

Hi there, I have never used Citect before and have a few bugs to fix. I have 2 questions: 1. How can i view the tag database as a whole...
Replies
10
Views
3,437
Does anyone know how to do this logic in Contrologix?
Replies
3
Views
1,565
Hello I need to know how many input are true from at 5-bit pattern. The True/False sequence is random. The evaluation has to be in every scan...
Replies
3
Views
1,680
Hi I am having som problems evaluating if the value in an integer created in the Static area, is Odd or Even. As far as I remember, Odd integer...
Replies
17
Views
8,390
Hello, I wrote some vba code for a Factorytalk View Studio SE application display. The code should be around 100 lines long using something...
Replies
2
Views
1,961
Back
Top Bottom