Advance Logic comparaison / Multiple Bit Scan Check

[mitureg]

(1)The safetest method is to change the range of your fire alarm bits to have a starting point on an 8-bit boundary (the first bit number is evenly divisable by 8) such as bit M128, instead of M131. This will make sure that someone in the future does not corrupt your program by using M128 to M130.

(2) If you cannot move the alarm range down by 3 bits from M131 to M128, then you must make sure that M128, M129, and M130 are not used for any other purpose, because that will cause your fire alarm bit count to be incorrect. This is because of the method that TwidoSuite uses to move 16-bit "bit strings" into 16-bit words. Here is Revision 2 with only 4 rungs.

Here is my list of memory bits:

First Segment:
%M131 to %M179 inclusively (I will make sure M128,M129 & M130 are not used, and will also put a tag in order to avoid any future confusion)

Second Segment:
%M205 to %M215

I think I should move these last 10 to a better location, there are bits right before and right after. However I am running out of %M bits and I can't find any space for 10 consecutive bits.

Would you advise me to use %MW instead for these last 10? I might have other problem with my HMI readings though if I do that. We've had problems reading %MW from the HMI using Easy Builder Pro.

Any suggestions greatly appreciated.

PS.: The %M bits right before these last 10 fire devices bits are used for the Horn System (Lancie). LOL

 

[Lancie1]

When the initial alarm turns on, %MW10 will not be equal to %MW9 (bottom branch). It hasn't been updated yet. Therefore, %M1 will be turned on, although it would only be on for one scan.

Adding one more instruction as shown on Rung 3, 3rd branch, should inhibit Page 1 until %MW10 is loaded (because %MW10 = 0 the first scan, and that sets Page 2).

I would not use a timing bit. All of these rungs should be fine executing every scan.

Yes, but when Alex gets everything planned loaded on this PLC, then moving all of the fire alarm bits on every PLC scan may cause it to slow down noticably. Is it likely that anyone will be able to respond to the alarm in less than the current 1-second update time?

First Segment:
%M131 to %M179 inclusively (I will make sure M128,M129 & M130 are not used, and will also put a tag in order to avoid any future confusion)

I think that very few of your addresses are set into concrete, so why not do some housekeeping and rearrange (or move them around in memory) so that your fire alarm bits start at M128 and extend to M189? That will make it easy to convert the fire alarm bits into consecutive MW words. Most good PLC programs have a function called "Search and Replace" where you can select an address to be replaced with another, then have it replaced on every rung in the program. Unfortunately I don't thing this little egg beater of a program will do that for you. You would have to do the swaps manually. Make sure you have a print-out of the program before you start, so you can mark up each address to "what it should become".

If you can't or won't do that, then at least move the horn bits to M211 to M215, making room at M200 to M209 for 10 fire alarm bits. You need to start your fire alarm bits on an even 8-bit boundary so you can move them into a MW word. If you really have only 10 more bits, then change Rung 1, 5th branch Operation addresses to be "%MW5 := %M200:10". The range M200 to M209 will get you your last 10 fire alarm bits.

 

[Eric Nelson]

I know it's kind of late in the game, but ideally, you should remap the bits. Based on your info and picture, this is your current layout:

128-130 - Free
131-179 - First Segment
180-197 - Used (I don't know if ALL are used)
198-199 - Free
200-204 - Used
205-215 - Second Segment

My first thought was this:

If you make the first segment start at the 128 boundary, you will free up 177-179. Then move the 'Used' bits from 180-197 to 177-194, and the 'Used' bits from 200-204 down to 195-199. Now the second segment can also start on the 200 boundary.

New layout:

128-176 - First Segment
177-199 - Used
200-210 - Second Segment

This can't work though, because 176 is the start of a boundary, so 177-183 can't be used for non-alarm bits. You will have to move the second segment to this area. I would move 200-210 to 180-189, and the 'Used' 177-199 to 193-215.

Final Layout:

128-176 - First Segment
177-179 - 3 spares for First Segment
180-189 - Second Segment
190-191 - 2 spares for Second Segment
192-214 - Used (Originally 180-197 and 200-204)

Now you can map 128-191 into Lancie's 4 words and do the comparisons.

I don't know the search and replace capabilities of Twidosoft. Based on what I've seen, it's probably not easy. Probably tough to do on the HMI end as well.



-Eric

EDIT: I see Lancie responded while I was typing this, and was thinking the same thing...

 

[Eric Nelson]

...moving all of the fire alarm bits on every PLC scan may cause it to slow down noticably.

I can't seem to find a list of instruction execution times, so I don't know how much of a hit this would cause. Why the bits aren't natively word-addressed is silly. Bits %M0-%M15 should already be sitting in something like word %MW1000, like most other PLCs I've used.



-Eric

 

[Lancie1]

EDIT: I see Lancie responded while I was typing this, and was thinking the same thing...

Yes indeed. I think most of the previously-used bits are under Alex's control, and are used as stand-alone bits that are not dependent on the word boundaries. Then it should be no big problem to re-map them as desired.

The two separate fire-alarm ranges can be and should be combined into one consecutive bit range. There are 49 + 10 = 59 fire alarm bits, so those can be remapped into M128 to M187. These 59 bits can then be moved to 4 consecutive memory words as follows:
%MW1 := %M128:16
%MW2 := %M144:16
%MW3 := %M160:16
%MW4 := %M176:11

The last word %MW4 should be made to contain the less-than-16 bits of the last 11 alarms, simply because the Length parameter after the colon will limit the number of bits that are moved into the last 16-bit word.

Why the bits aren't natively word-addressed is silly.

The more I see of this thing, the more silly things I find.

 

[mitureg]

Hi Lancie & Eric, I did the modifications for my general %Mbits architecture and entered the rung. I also ran simulations to see if everything is working like it should.

Memory bits:
There are 59 fire devices. I used as prescribed the %M128 to %m187

Simulations:
The %MW + %MW SUM function works well. The values are transfered to the %MW407 which is the one I used (see snippet).

However, what doesn't seem to work is the condition for the multiple alarm page.

Notice that we might have inverted our mutual comprehension of which page means "only one alarm", and which page means "more than one alarm".

%M188 is for only one alarm​

%M189 is for multiple alarm​

From what I understand, maybe a retentive system should be used to keep in memory that the condition for multiple have been seen once in the scan. Or maybe I am way off, and the problem is something else beyond my comprehension...

If %MW408 is copied in %MW407 every second, how is it possible to simulate properly the system, in order to verify the "more than one alarm" condition?

Cheers.,
Alex

 

[Eric Nelson]

First off, I think the length of the last word should be 12, not 11. Yes, 187-176=11, but that does not include 187.

1 - 176
2 - 177
3 - 178
4 - 179
5 - 180
6 - 181
7 - 182
8 - 183
9 - 184
10 - 185
11 - 186
12 - 187

(One reason why I hate PLCs that use sequential numbering. n0-n7 or n0-n15 is so much simpler)

I think we're on the same page with the single and multiple alarm bit names.

I question the %S0 contact. Shouldn't this be %S13 (first scan)?

I'm still not convinced we need the timing bit. This may be screwing up the comparisons. That bit has a 50% duty cycle, so it will be ON for 1/2 second and OFF for 1/2 second, so it really only helps improve scan time for a 1/2 second at a time (using a one-shot triggered by %S6 might work better?). I would compare the scan times with and without the bit mapping and see how much difference there really is.

Visually, the current code looks like it should work. I don't have this hardware, so I can't help with debugging.



-Eric

 

[Peter Nachtwey]

if the PLC can't count bit the efficient way like jamesau suggested, I would simply look at each bit and increment a counter if set. Problem solved days ago.

 

[Lancie1]

Notice that we might have inverted our mutual comprehension of which page means "only one alarm", and which page means "more than one alarm".

If anyone inverted anything, it was YOU in your original post:

..-Page 1: IF the number of memory bits %M, for example between %M100 and %M200 returning a "1" is more than 1 (aka.: several bits AT THE SAME TIME)

If %MW408 is copied in %MW407 every second, how is it possible to simulate properly the system, in order to verify the "more than one alarm" condition?

It did need a little more work. Here is a better version that I tested on the LogixPro Simulator. The results were when one alarm bit goes on (any one in the range, then %M3 goes on and that seals in %M188. Use %M188 to go to whatever HMI page you desire. When a second bit goes on, %M4 goes on and seals in %M189. Now if other bits also go ON, nothing else happens until all alarm bits again go OFF, when the system resets itself, or it can be manaully reset with a HMI pushbutton %M6.

You will have to set the various memory addresses as you need. NOTE: The rung order in this type of program is important. For example, I tried swapping places with Rungs 4 and 5, and then it will not work at all. This is because you are using which event happens first to make the program work.

The bottom line: you are wasting a lot of your small PLC memory to merely switch from Page 1 to Page 2 in your HMI program. Most of us simply put some menu buttons in one corner of the HMI screens:

[ MAIN SCREEN ]

[ OTHER SCREENS ]

[ PAGE 1 ALARMS ]

[ PAGE 2 ALARMS ]

When you press any button, bam! the HMI goes to that screen and stays there until the operator presses another screen! Like Peter said, it is pretty wasteful of time and effort to do all this on this particular small-bore PLC.

 

[mitureg]

The bottom line: you are wasting a lot of your small PLC memory to merely switch from Page 1 to Page 2 in your HMI program. Most of us simply put some menu buttons in one corner of the HMI screens:

[ MAIN SCREEN ]
[ OTHER SCREENS ]
[ PAGE 1 ALARMS ]
[ PAGE 2 ALARMS ]

The design is more complex. There is a total of 9 pages that shows different maps comprising 36 zones and 59 fire devices.

The system we've just successfully designed will return a bit indicating either a "single" or a "multiple" state of fire device. This bit will be used in conjunction with Memory Word Bits (%MW x:bits) returned through a central fire device main panel using Modbus Communication. These will indicate in precision 1. which device is ON, 2. which zone has an active fire.

The design order required either a map in the case of only one alarm to be shown, or the main area page in the case of multiple alarm.

Now if other bits also go ON, nothing else happens until all alarm bits again go OFF, when the system resets itself, or it can be manaully reset with a HMI pushbutton %M6.

I've tested the other scenario where several alarm sensors for a "multiple alarm" state returns back to a state where there is only one fire alarm device triggered. The results is that the "multiple alarm bit state" is still returned.

In other words, the interlocking N.C contact system at rungs 7 & 8, which is intended to disengage coil sealed-in, works only for a state of "Single Alarm to Multiple" but not from "Multiple to Single Alarm".

On the other hand, this is perfectly fine, as in the case of multiple fires getting one by one "put out", the operator would probably keep an eye on the Main Fire Alarm page which contains all the name of the different pages (map) where all the different fire devices are show with a RED dot, indicating the state of each device (ON or OFF).

PS.:

First off, I think the length of the last word should be 12, not 11. Yes, 187-176=11, but that does not include 187.

1 - 176
2 - 177
3 - 178
4 - 179
5 - 180
6 - 181
7 - 182
8 - 183
9 - 184
10 - 185
11 - 186
12 - 187

Thank you for this one Eric. I did the correction. As expected the last alarm memory bit wasn't copied previously.

 

[Lancie1]

The design is more complex. There is a total of 9 pages that shows different maps comprising 36 zones and 59 fire devices.

It would have been best if you had admitted the truth at the beginning. You have a history of doing that. I do not know what you hope to gain by only stating PART of the problem in just about every one of your posts. It is aggravating, and until and unless you stop that habit, this will be the last post of yours that I will bother to answer.

I should have suspected that you would have multiple zones, because I have installed several fire alarm panels, and every one had multiple zones. Dividing your bits into the 36 zones with a a %MW word for each zone would have made the program much more useful. Then if any of the 36 words was <> 0, that meant an alarm in that specific zone and location in the ship, and the control operator could easily and quickly switch the HMI page to that zone, no doubt about which area and what alarm point. The zones then could be combined into another location word, many "Decks" becauses this is a ship, then from the 1 to 10 decks, combine into an Above Waterline %MW and a %MW Below Waterline word, and finally combine those two into one master word that indicates if there is an alarm or not. Now you would have multiple manual ways to view the fire alarms, but NOT by automatically switching HMI page views.

One thing you should consider is that in a fire situation, often there are multiple alarm points, very rarely only one. With your planned system, your HMI may switch rapidly from page to page at a dizzy speed, so fast that the operator has little chance to read the pages!

For most HMIs, it is best to have an alarm page that has an on/off dot for each alarm point, and then let the operator switch the pages manually to what he needs to see. Trying to automate the page switching is a foolish task. I doubt if anyone will be pleased with the results.

Besides, your PLC brand and model really does not have the capacity to allow automatically handling 59 alarm points (along with all the horn controls and other stuff you have planned).

Also a standard off-the-shelf PLC is not properly rated and tested to do any type of fire alarm control.

 

[mitureg]

Lancie, sorry to disappoint you. Keep in mind that this is the first professional job I ever that. I got my first job in the field less than 2 months ago... the vital design DETAILS are not clear to me first off when I have a new challenge. I just try to do my best to wrap my head around the whole thing, bits by bits.

It would have been best if you had admitted the truth at the beginning. You have a history of doing that. I do not know what you hope to gain by only stating PART of the problem in just about every one of your posts. It is aggravating, and until and unless you stop that habit, this will be the last post of yours that I will bother to answer.

I started my post like that because it is easier to explain, read and understand to my eye. My mistake, I will state the whole problem from now on. Hoping that you will still answer my future posts

Dividing your bits into the 36 zones with a a %MW word for each zone would have made the program much more useful.

This is a good program design idea. I am fairly new to PLC programming, I just started to have a better picture of Memory, Memory Words and Memory Words BITS. Before this program, I had no idea what to do with them, I was just using Memory Bits and there are a limit of 255 in TwidoSuite. So I had to resort to find some other means to store bits.

One thing you should consider is that in a fire situation, often there are multiple alarm points, very rarely only one. With your planned system, your HMI may switch rapidly from page to page at a dizzy speed, so fast that the operator has little chance to read the pages!

You will have an automatic popup page for ONE ALARM with a "Close" button that will act like a alarm wake-up clock snooze. When a popup will show up containing the map with the blinking red dot, the operator can hit close and the popup will come back 10 minutes later IF there is still a fire AND IF there is ONLY ONE fire. Otherwise, if there is multiple alarm points, I will probably leave a scrolling !!FIRE ALARM!! message that will prompt the operator to go manually to the MAIN FIRE ALARM PAGE that contains all the 9 maps of the ships, with a red dot besides the name, blinking IF there is an active fire alarm in that particularity section of the ship.

That being said, as you suggest, it's probably best not to change the page manually to the main alarm page in the case of multiple fires. That will confuse the operator. My task (this is an order from the engineer in charge of the project) was to have a popup for one alarm OR a main alarm page for multiple alarms. I think a popup will do for one, but for multiple alarms a scrolling message will do, not impeding the browsing or the reading on the screen. I will talk to the engineer in charge and make the recommendation.

Besides, your PLC brand and model really does not have the capacity to allow automatically handling 59 alarm points (along with all the horn controls and other stuff you have planned).

Also a standard off-the-shelf PLC is not properly rated and tested to do any type of fire alarm control.

Maybe not, but I am not the engineering in charge. I will keep you updated later of the stability of the system once it's on the ship.

As a reminding, the PLC will only READ the fire alarm from a fire alarm main panel device through Modbus Communications and return them on the HMI. The control is done by that standalone piece of hardware device: http://www.marinelec.com/modules/kameleon/upload/PHOENIX_FP_GB_REV_0.1.pdf

Cheers,
Alex