Rslgx 500 help

MICROLOGIX 1400'S
FTSE 8.2

I need to set a bit or change the value of a word so that I can read the tag in FTSE and cause the screen to change to the display that pertains to the alarm or event. I have this working now by having 16 rungs each with a NO contact, ONS and an OTE is series then 16 corresponding NO contacts in parallel to a bit that FTSE reads and makes the screen change. So to read one word B3:1 I have 35 rungs.
I would like to find a better way and have been trying by using B3:1 NEQ to 0 to trigger FTSE and also moving the value of it to another word and using that as a memory of B3:1 last value with a NEQ or GRT so I can also re-trigger the screen change on a second followup alarm or event if the first one has not restored yet. That part has not been working. If I use the NEQ then I get screen changes when alarms restore to normal also. If I use GRT the memory bit can be holding a higher value and not trigger at all if the next event/bit is a lower value than the previous alarm.

Bill

Cannot make out the detail in that picture. Can you clarify please: B3:1 is a word which contains 16 alarms? And is it each alarm word or each bit within the word takes us to a specific page?

Can you do NEQ to previous value and NEQ to zero?

Yes 16 alarms. Each bit represents 1 They all go to same display. Displays have a little idledetect code that returns it to home page after 1 hour of no mouse movement. Even if one bit still in alarm state but silenced or shelved I want 2nd or third to go back to that display. I tried the NEQ. That also caused page to switch when alarm bit restored to normal because it wasn't equal.

Did you try cmothebean's suggestion? Adding a NEQ B3:1 0 after, and in addition to, your existing NEQ should prevent triggering your alarm screen when all bits are reset (B3:1 = zero).

To clarify, your rung would look like:

NEQ B3:1 B?:? NEQ B3:1 0 ---> Display Alarm Screen

Where B?:? is whatever you used as your memory of 'B3:1 last scan value'



-Eric

That still makes screen switch when a bit is reset if there is still another bit Hi. This is common as some of the events are not alarms, like tanks hitting the full level when the truck fills them. I don't want to be switching screens through out the week just because they are using product and the level dropped. I am having trouble making a .bmp image clear enough and still under the 488k limit. This is what I have.

SOR MVM B3:1 00DBh N7:6 EOR
SOR NEQ N7:6 0 NEQ N7:6 N7:7 ONS B3:2/10 OTE B3:4/0 EOR
SOR BST XIC B3:4/0 NXB XIC T4:0/TT BND BST OTE B3:2/11 NXB TON T4:0 1.0 5 0 BND EOR
SOR XIC B3:2/11 MOV N7:6 N7:7 EOR

[/IMG]
[/IMG]

Perhaps something like this would work. It's basically a 16-bit wide one shot. The MOV at the bottom updates the inputs to reset the DELTA word.

Oddly, this logic does not work on the micro emulator in RUN mode. It does work in single scan mode.

why do you latch the alarm_current B3:4 bits

bdoutney said:

why do you latch the alarm_current B3:4 bits

Click to expand...

B3:4 holds the bits which represent the alarm state. For instance, bit /0 might drive your HMI to present the screen for X. They are latched so that the alarm state persists even if the cause goes away.

Thank you Doug, That worked great. I never would have known how to use XOR that way. I didn't use the OTL's because these are not being used as alarms by FTSE. Im using it to change to a display if any one of these goes high and then release control of screens. So I have a rung that holds for a few seconds at the bottom. If I was using the OTL's is there a way to unlatch all of them in that word at once instead of 16 rungs?

until Doug gets back -

If I was using the OTL's is there a way to unlatch all of them in that word at once instead of 16 rungs?

Click to expand...

yes, a simple MOV command would work - if you use a value of 0 for the Source ...

DISCLAIMER: I'm not following this thread closely - so I apologize if my answer doesn't "fit" everything that you're trying to do ... Doug may certainly have a better answer when he comes back around again ...

Ron Beaufort said:

yes, a simple MOV command would work - if you use a value of 0 for the Source ...

Click to expand...

As Ron states, the workhorse MOV instruction will serve well. My personal preference in this case though is the CLR. With CLR there's no chance of somebody inadvertently changing the MOV parameter to a non-zero value. CLR loads zeroes only and always.