Flashing Bits and non-flashing output - RSlogix

[Eric Nelson]

A quick 'patch' to make it work the way you want would be to add an XIO O:2/0 in series with the upper branch of rung 2 (in post #14). This would simply disable the green lamp while the amber lamp was on. Just a patch though. I would probably rewrite some of the logic in the final version.

That said, I agree with Lancie that forcing the operator to acknowledge self-clearing alarms would become annoying, but in the end, it's your decision. There may be a good reason behind doing this...



-Eric

 

[mitureg]

Thank you Lancie for all the work and Eric for your help.

I eliminated the latch/unlatch for a internal memory relay B3 bit at rung 3.

If I were an operator I would be digging out the giant Operator All-Purpose Fixer Tool (10-lb sledge hammer) and do a little work on this dinky irritating system!

LMAO

The green lamp indicator has to be part of the work even though it seems annoying for an actual plant, since the operator would need to acknowledge for Plant Alarm Conditions that are no longer active.

Perhaps you need to create an Alarm History file, and save all alarms as they occur. That is the usual way.

I like the idea! Is that complicated to do within the rungs of this program? I would love to add it if you could give me guidelines Lancie.

The updated version of the program is in attachment.

Cheers!
Alex

 

[Lancie1]

There may be a good reason behind doing this...

Eric, I suspect that the purpose is PLC programming training.

I like the idea! Is that complicated to do within the rungs of this program? I would love to add it if you could give me guidelines Lancie.

First, allocate some memory words to save a record of WHICH alarm bits occurred. Normally an alarm light and horn system functions for many different alarms, each with a PLC input or logic condition. You simply save the NAMES of each alarm bit, either in a String file, or if the alarms are in similar Input addresses, simply use an Integer file to save the bit Input number address of each alarm.

In your case, you appear to only have one alarm bit, so you could not store alarm events without more information about what caused each alarm.

You set up X-number of PLC memory storage locations, say for the last 20 alarms. Each time a new alarm happens, you copy all previous alarms downward in the file, eliminating the oldeset and adding the newest. Then you can display or view or print out the last 20 alarms at any time. Sometimes additional memory locations are added to also save the date and time for each alarm. Many operator interface programs such as Factory Talk View or RSView have built in alarm history file set-ups that work with the PLC to save the alarm history.

Here is the problem description:

For future use, it is best to start off your questions on this site with the exact problem description. Your Post #15 is the FIRST place where you made it clear how the alarm lights are supposed to work. Normally for an alarm, a person like me could and did make certain assumptions about missing data, but in your case, your alarms are not normal or usual, so those assumptions are useless for a non-standard case.

 

[mitureg]

Thank you Lancie.

 

[mitureg]

Hi Lancie, I think this program is done.*I just need to reference each rung. I just wanted to check with you if I got the proper terminology in my comments. I am a bit confused with the terminology for "flags" , "contacts" and such.

Maybe you (or someone else?) would have some advice on how to communicate better the purpose of each rung in a technical vocabulary that is concise and clear.

Much appreciated,
File in attachment.

 

[Lancie1]

I think your comments are mostly okay, for a student problem, as they are. At this stage in your training, more commments and bigger comments are better than the usual student comment (none at all).

About "flags", that is just a name for a bit that signals that some condition is ON or OFF. Signal flags were used many years ago by armies on the battlefield, and by navy ships at sea. I thing that is where the term originated. A PLC bit flag is just a stand-in to record a condition so you can use it later (after the state that caused the flag may have gone away).

The only thing I see that might not be "professional" is that you put a Title on each rung. That works okay in viewing the program on your computer, but when you print it out to a printer or a PDF file, the titles cause a new page for each title, which results in a lot of pages and a lot of empty space.

About titles, if you want to keep the info in titles, but not cause extra printed pages, you can simply move the title into your first comment line, then skip a blank line and start the real comment. You can have up to 500 lines in a comment, depending on the number set in the "View, Properties, Comment Display" menu screen.

 

[mitureg]

The only thing I see that might not be "professional" is that you put a Title on each rung. That works okay in viewing the program on your computer, but when you print it out to a printer or a PDF file, the titles cause a new page for each title, which results in a lot of pages and a lot of empty space.

Thank you Lancie, I didn't know that. I didn't really understand why the pdf pages had gaps.

Much appreciated,
Cheers!!!

 

[Lancie1]

You can have up to 500 lines in a comment, depending on the number set in the "View, Properties, Comment Display" menu screen.

I have never used 500 lines in a Comment, but I have used 20 to 30 lines on the first program rung to set up a Table of Contents for the entire program. That is useful where you have electricans and instrument technicians doing troubleshooting that have little PLC experience, and need to be able to quickly find the different steps in the PLC program.

 

[mitureg]

Great tip for communication. Thanks