How to avoid a messy cross use of exception bits

General · 1 reply · 56 views · 2 followers

Taavi Koppel

12 months ago

An assembly process.
Lets say I have multiple stations... there is an error in the first station and I want the behavior of the next stations to change because of it.
Fine... I can create an error bit based on some conditions and use this bit in the next program steps and stations to alter the normal flow. Do some of the things like during normal flow but not others.

The problem is that it gets messy. There is the normal behavior and a completely different behavior and they exist together in the same networks... logic in the same networks increase and the complexity increases exponentially.

Is there a good "best practice" method to keep things nice and clean?

Scott S Mod

12 months ago

Taavi, great question! There are a number of ways to proceed, but this one seems to work well, is scale-able, and does not become too much more complex as the system grows.

The best way to do this is to designate one PLC (or other type of CPU) as the Master Alarm Station. In each of the many CPU's used for control, set aside a long integer (or multiple integers) that will represent the alarms for that particular CPU, one bit per alarm. So, a single DINT would represent up to 32 alarms. Also, set aside another DINT (or more) to receive commands from the master alarm station.

Then, in the master alarm station, read the alarm word(s) from each of the individual CPU's. Then, in the Master Alarm Station, provide any logic necessary to develop bits for instructing individual stations on what action to take.

For example, if the infeed conveyor belt faults, Station 2 Alarm Word 1 Bit 4 is set, and the Master Alarm Station will read this alarm status when it reads the alarm word from that station. Then, based on any applicable logic, the Master Alarm Station may set Alarm Command Word 1 Bit 2, instructing Station 3, the next operation downstream to go to a HOLD condition.

In this manner, the complexity of what to do is handled by an external station. That way, only the Master Alarm Station needs to know the alarm status in each station, rather than trying to cross-communicate among multiple stations. The Master Alarm Station also gives the abnormal state commands, freeing the individual stations to concentrate on control of their local equipment.

1 Like

Taavi Koppel

12 months ago

Thank you for your reply.
I understand the concept of the Master Alarm station but I struggle to apply it to my stituation.

First of all, I have a single CPU and different stations are different FB-s... with their own FB-s for outputs and reset steps.
Parts are handed over from one station to another... If a part was bad, a robot moves it to a red bin... if it is good, it is moved to another place. Different parts have different bad features... so I end up with a lot of comparisons... if part nr is this... and there is this error... load this program. If this error and this part nr, and this program step and its all over the place.

I don't know enough to even ask the right questions...
I came across the term "spaghetti code"

So an alternative approach I came up with goes something like this:
- a FB (Function Block) is only written to do one task. One with many steps but just this one task. But there is an error condition in front of one task... and this condition will stop the normal flow.

- A different FB is written to do the tasks that solve this error. Like throw away the bad parts, bring new parts and then reset the error bit.
the first program doesn't know anything about it... it just waits because the error bit is still active.
The very last thing on the error solving program resets the error... and therefor the first program can continue from the place it stopped... like nothing ever happened... it just waited.

Is this approach wrong? Is it scalable? Am I causing a new set of problems in the long run?