To be or not to be, that is the question, and stick with it.

[Ausman]

OK all, so I got your attention with the odd title.

Santa Aus has a Xmas tip for you.  🎅

I recently had to work on a very old program of mine, done when I was in my PLC infancy.  (Yes, they did have PLCs back then......they ran on a pedal generator.  The machine itself worked from 5000 mice running on a wheel).

One thing that struck me, and caused me some angst, was that I chopped and changed my methods of controlling things via bits throughout the program.  I am talking about the decision that must be made at the start of a project.... "which way will I switch MBs (or the same thing on other PLC brands) to do further control elsewhere".  This decision should likely be made for the rest of your PLC programming life, anyway.

Decide on either having the MB turn ON or OFF for a true or false condition, and religiously stick with this concept throughout the project.  It gets very confusing when dealing with a piece of ladderwork where you have both methods in place, especially when working with an entire rung of MBs that all work together to do something else. 

Sometimes the way this all works initially seems wrong, but think it through logically, Mr Spok.  🚀 In  my case these days, in an OK condition, the MB is ON.  Same thing if an error is happening, it is ON.....but this means that the contact doing further control is Inverted, so that when the error is NOT happening, the MB allows flow as there is no error.  Anything meeting the required parameters turns ON.

Here's a quick copy of my self-recording dialogue during finding such inconsistency, severely edited for public consumption.

"Hang on.  That makes no sense.  Is that meant to be on or off?"   Hunt through the rest of the program to find what controls the culprit.

"Ohhh, this one's OFF for OK, but the next one is ON for OK."

"You dumbcluck, Aus.  Talk about making it hard for yourself!" 

😖

Cheers, and enjoy your Xmas time.

Aus

[Flex727]

I think we all struggle with this from time to time. Complete and careful operand descriptions are the only real solution.

[kratmel]

Recently I had to modernize the  well-known Swiss company machine control .

It was built when ...

2 hours ago, Ausman said:

PLC..... ran on a pedal generator.  The machine itself worked from 5000 mice running on a wheel)

So to my great surprise, the start signal of the motor converter is done by opening the electrical circuit with one of the closed contacts on each of the buttons that control the movement.

My brain exploded in surprise.

While my new PLC starts - the motor will turn a little.

My task of modernization has turned into a struggle between closed and open contacts.

No changes in buttons possible, NC contact must be open for RUN.... How to implement  Emergency Switch and Safety relay.

 

P.S. PLC programmed, machine in working condition.

But in a few years someone will say - Who built such nonsense on the PLC. He can't guess that mice used to run here ...

 

[Flex727]

24 minutes ago, kratmel said:

But in a few years someone will say - Who built such nonsense on the PLC. He can't guess that mice used to run here ...

Some of my programs have that issue. Programs that I wrote from scratch, but no one would see or know about the changes requested by the customer after the basic framework of the program was complete. Sometimes you just have to do what will work without regard to how elegant the solution ends up being.