Advance Logic comparaison / Multiple Bit Scan Check

They list BLK.x in OP2 (the 'from' register), but not OP1 (the 'to' register). Let's hope that's NOT the case.
I named each %SBRi as a symbol block "SBR0" to "SBR6" and that seemed to work to move the bits into the shift registers. The thing I do not know is if a bit range will be pulled out of each block, so that all 16 bits of each SBR are loaded with a range from %M100 to %M200.

Eric, you are correct, if you can get each bit into 60 words, and then rapidly compare each word to 0, that will do the job.

Hi Lancie, I am trying to understand your SBR program and its quite hard for me to wrap my head around.

My idea was to put the 100 bits into six cascaded 16-bit shift registers, then using internal clock bit %S4, shift for 100 times as measured by the Counter 0. The result for all 6 SBRs (in this case) should come out at SBR6.5. Because each SBR only handles 16 bits, for 100 bits you need to use 7 SBRs (SBR0 to SBR6). You tie them together by first shifting the last SBR6, then take the last bit of SBR5 and move it to the now-empty SBR6.0 You do that for every SBR after it has been shifted, so that no bit between %M100 and %M200 gets lost. Then every time that SBR6.5 is ON or a "1", you ADD 1 to word %MW1, and when the Counter is done (= 100), you move that result to %MW2. The count to 100 at 0.01 seconds requires 1 second, so you will get a new result every 1 second, which should be often enough to upgrade a fire alarm HMI page.

I did not do the comparison instructions that would be needed to select your HMI pages.

Because you did not state the actual bit range of your real program, then you will have to adjust the Operations in Rung 17 to move the correct bits into the SBRs. For 60 bits, you probably only need about 4 SBRs.
 
Lancie said:
My idea was to put the 100 bits into six cascaded 16-bit shift registers, then using internal clock bit %S4, shift for 100 times as measured by the Counter 0. The result for all 6 SBRs (in this case) should come out at SBR6.5. Because each SBR only handles 16 bits, for 100 bits you need to use 7 SBRs (SBR0 to SBR6). You tie them together by first shifting the last SBR6, then take the last bit of SBR5 and move it to the now-empty SBR6.0 You do that for every SBR after it has been shifted, so that no bit between %M100 and %M200 gets lost. Then every time that SBR6.5 is ON or a "1", you ADD 1 to word %MW1, and when the Counter is done (= 100), you move that result to %MW2. The count to 100 at 0.01 seconds requires 1 second, so you will get a new result every 1 second, which should be often enough to upgrade a fire alarm HMI page.

GREAT! Now I understand. Thank you Lancie. So I guess that was what you guys called "a loop". So it implied using SBR. I get the idea of the program now. Will try it on monday using a %S5 to be able to follow the values in real time in the Animation Table.

Lancie + Eric said:
Eric, you are correct, if you can get each bit into 60 words, and then rapidly compare each word to 0, that will do the job.

Thank you for confirming the validity of Eric's idea. It's very clever in its simplicity, will have a try on monday using these commands: %M100 := %MW1, then input condition on a flag for %MW100 = 0. Repeat for all memory bits (total of 60).

Cheers Lancie & Eric Nelson!
Alex
 
%M100 := %MW1, then input condition on a flag for %MW100 = 0. Repeat for all memory bits (total of 60).
Er...I think it would be the other way: %MW1:=%M100 to assign the word MW1 to the value (1 or 0) of bit M100. Then you just compare the value of %MW1. Then if %MW1 > 0, then you have at least 1 fire alarm. But to do it that way will require 60 Operation blocks to make all the bit assignments.

I think there is a way to assign one word to the value of 16 successive bits, something like %MW1 := %M176:16, where %M176 is the nearest 8-bit boundary to your first alarm bit at %M179. If you can figure out how to assign a word to a collection of 16 %M bits, then that will reduce your number of assignment rungs or branches to only 4 (60 bits/16 = integer 4)!
 
Last edited:
I think there is a way to assign one word to the value of 16 successive bits, something like %MW1 := %M176:16
Based on the clip I posted from the manual, this will work.

Using double words would simplify it more, but I think the length :)L) is limited to 16, meaning you can't load a double word with 32 bits, like %MD0 := %M96:32 assigning bits %M96-%M127 to %MW0-%MW1. :(

🍻

-Eric

P.S. I have made myself a note to turn down any Twido programming jobs... ;)
 
Lancie said:
%M100 := %MW1, then input condition on a flag for %MW100 = 0. Repeat for all memory bits (total of 60).
Er...I think it would be the other way: %MW1:=%M100 to assign the word MW1 to the value (1 or 0) of bit M100.

Yup, it's the other way around. Thank you

Lancie + Eric said:
Quote:
Originally Posted by Lancie1 View Post
I think there is a way to assign one word to the value of 16 successive bits, something like %MW1 := %M176:16
Based on the clip I posted from the manual, this will work.

Thank you for that. Will give it a try and post back.

Cheers.
 
Thank you for that. Will give it a try and post back.
Reading the Twido Software User manual some more, there is apparently NO WAY to move bits into the SBR shift registers with this version of the software! It seems silly to have a bit-shift register with no easy way to put data into it!

Anyway, using Eric's method, you can do the job IF you can do (1) or (2).

(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.

P.S. I have made myself a note to turn down any Twido programming jobs... ;)
Eric, that seems a smart move based on what I see now. If there easy ways to program this beast, they sure do not show up in the poorly-written manuals.
 
Last edited:
I'm not sure I agree with your logic, Lancie (or maybe I don't understand it?). The value in the words will not be the number of bits that are on. It will be the word representation of the bits. For instance, if bit %M146 turns on, the value of %MW2 would be '4' (0000000000000100), not '1'.

We want to look for a change from zero to 'some other value' to detect that one alarm has occurred. After that, we remember what value it changed to, then look for a change to a different value. That would mean a second alarm has occurred.

🍻

-Eric
 
I do like your idea of adding the words together. I didn't think of that.

I think just replacing rung 3 with the following should do the trick. I don't have Twidosoft, so here's the text version. Hopefully I have the syntax right.

LD %M1 'If one alarm is already present
[%MW10 <> %MW9] 'and sum (MW9) is different than last scan's value
S %M2 'SET "Multiple Alarms Present"

LD [%MW9 <> 0] 'If sum (MW9) is not zero
S %M1 'SET M1 "One Alarm Present"

[%MW10 := %MW9] 'Move MW9 to MW10 (Remember MW9's value for next scan)

[%MW9 = 0] 'If no alarms are present
R %M1 'RESET "One Alarm Present"
R %M2 'RESET "Multiple Alarms Present"

Note that M1 will remain ON even when M2 is on, so it might not be able to directly control page display. For the 'One Alarm' page to display, it would be M1 AND NOT M2.

🍻

-Eric
 
Hi Lancie, could you explain me your last program?

I am not sure that I understand RUNG 2 (see snippet) and the relationship with the "NEW" tag.

How is it possible to combine 2 memory words together? Does it become a double-word (32 bits) ?

Eric said:
I thought you could use the <> operand.

This operand seems to work on my system.

Could you simplify RUNG 3?

Cheers guys,
Alex

BitCounting1.jpg BitCounting2.jpg
 
Last edited:
Lancie is simply adding together the values of all the words the alarm bits were mapped to, so you only need to compare one word, instead of each individual one. When there are no alarms, all of them contain zeros, so the result will be zero. When an alarm occurs, one of them will change to a different value (value depends on which bit turned on).

For example, if bit %M165 turns on, word %MW4 will have a value of '32' (0000000000100000). The other words will still be zero, since only 1 bit turned on. Therefore, when words 1 through 5 are added up, the result is still only '32'. Rung 3 compares that value to zero. Since it no longer equals zero, we know an alarm occurred.

%MW10 just 'remembers' the value that %MW9 changed to, so we can determine when a second alarm occurs. When %MW9 changes to a different value from the value when the first alarm occurred, we know another alarm bit turned on.

🍻

-Eric
 
I thought you could use the <> operand.
Yes, that works too.

Could you simplify RUNG 3?
Yes, I think it could be simplified some. I thought about it and came up with this version with a shorter Rung 3 and 4 replacing the old Rung 3. It depends on using a timing bit (S6 is 1 second), so that when that bit is off, the %MW9 NEW can be copied to the %MW10 PREVIOUS. I have not tried it, so it may need some tweaking.

One thing that I notice is that no direction is being given for the condition of 0 alarm bits. What should the HMI do then? With the current logic, neither HMI Page 1 or Page 2 will be selected when there are 0 alarms.

Multiple Bit-Scan- Rungs 3 & 4.jpg
 
Last edited:
Nice elimination of the set and reset, Lancie... (y)

I see one issue with rung 3 (which is also present in my logic in post #24). 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. This may not be an issue, but it does happen.

I would not use a timing bit. All of these rungs should be fine executing every scan. In fact, I think using the timing bit will only exacerbate the issue I explained above.

To solve this issue, I would add a one-shot in parallel with %M2, and use that to inhibit the 'NOT EQUAL TO' comparison of %MW10 and %MW9 during the initial alarm detection scan. That would eliminate the erroneous trigger of %M1.

Personally, I don't see the need to simplify, but the move instruction on rung 4 could be paralleled with the bottom branch of rung 3. We only need to update %MW10 while there is at least 1 alarm, and the %MW9 <> 0 would keep it active.

🍻

-Eric
 

Similar Topics

I'm a bit stuck again... See the redacted picture. At the moment, pressing F7 saves the "live" laser measurement into the boxes indicated by the...
Replies
9
Views
1,096
I have 2 TIA Wincc projects. One project is in TIA V17 Wincc Professional and other project is in TIA V15 Wincc Advance. How can I copy the Wincc...
Replies
1
Views
1,268
Is it possible to convert the project in Wincc Professional to Wincc advance?
Replies
6
Views
1,829
I have a tia v17 project in laptop. I prepared a PC to be used as HMI. In Tıa projecy there is wincc advance. How can I transfer this wincc...
Replies
1
Views
1,372
Does anyone know where I can order a T9110 SIS processor from? Seems like the availability of them online is scarce.
Replies
4
Views
1,935
Back
Top Bottom