Thread Content
Recently, I learned from a configuration specialist at a system integration company that they rely solely on textual descriptions for implementing interlocks, believing this to be the clearest approach – it’s sufficient to clearly state which pressures or temperatures are too high, and which valves should be closed or pumps stopped. There are tons of lines flying around in the logic diagram, which is troublesome to look at. They don’t pay attention to whether the RS flip-flop operates in reset-priority or set-priority mode; for each valve, they have provided an interlock activation button – pressing it sets the mode to set-priority, while not pressing it sets it to reset-priority. The user can choose the mode according to their needs.
It depends. Some logically well-structured diagrams require little thought; they can be implemented directly. Even those poorly structured ones aren’t that bad—basically, there’s a high minimum standard; As for the written instructions, it really depends on the individual; especially in cases of complex interlocks. If someone doesn’t understand automation in terms of process engineering, and you ask them to provide written instructions for configuration, you’ll face troubles during debugging
The key is to specify the requirements; if the process interlock instructions are very clear, and include specific instrument tag numbers, trigger conditions, actions, etc. The manufacturer should be able to do it. If the process is described in words, repeated discussions are required within one’s own design institute regarding automation issues; presenting it to the manufacturer only leads to confusion. In fact, if it is provided to the manufacturer by the process team, creating a cause-and-effect table is quite straightforward; it also gives the process team an opportunity to organize their thoughts.
The manufacturer doesn’t need to look at the drawings, but a chain diagram is still required. After installing the interlocks, the manufacturer must conduct interlock tests.
The type of trigger used should be specified in the description. In reality, there are many ways to carry out an action; the logic diagram is merely one way of representing it. Whether or not the configurer looks at the logic diagram has no effect on their ability to perform the actions required by you – only the sequence of actions differs. Ultimately, all actions can be triggered based on certain conditions. For example, some people are used to using RS flip-flops directly, while others prefer to use gates to implement the RS functionality
Such manufacturers should be blocked and eliminated as soon as possible.
It’s not that it’s impossible; it’s just that when the final product is produced, verification becomes a hassle. If we verify it by comparing it to a logic diagram, the process would be much faster. Of course, it’s possible that the logic diagram might be quite complex, making a textual description simpler instead
Based on your description, this manufacturer is by no means professional – they can’t even understand the drawings, so how can we be sure the products they produce will be of quality? Is it reliable?
For very simple systems, it doesn’t matter; but for complex systems, a logic diagram is definitely the clearest way to represent them
Yes, without looking at the logic interlock diagram, simple problems are not an issue; for more complex ones, if bugs occur, it’s a problem with the configuration.