RSLogix 5000 asyncronous I/O - HMI comms too?

[rupej]

It's pretty well known that RSLogix 5000 processors update the physical I/O asynchronous to the program scan. It is often suggested to copy the inputs to "mapped" bits at the beginning of the program to make them update only once per scan.

Is this asynchronous update also true with data comms, like bits or data manipulated by an HMI? If so, and you want to make those updates synchronous as well, do you have to map each of those bits too? Seems like that could be an incredible amount of work, given how many "PB_Start_Pump_A" type bits can be on an HMI.

 

[Ken Roach]

Yes, communications updates from unscheduled sources are asynchronous to the program scan.

For simple HMI data elements that are used in only one place, I don't do anything special. Like the "Start_Pump_A" pushbutton in your example.

For complex HMI data exchanges like tables and arrays and things that need to follow a sequence, yes, I use buffers and other methods.

 

[ASF]

I always always always "map" my HMI PB tags. Not only for the reason that you describe, but because when you press a HMI button, it's not just continuously sending the PLC a message that the button is pressed, which it stops sending when you release the button - it sends one message when you press the button (set tag to 1) and one message when you release the button (set tag to 0). If that second message gets dropped, hey presto, stuck button!

So for every single PB on my HMI I have a line like this:

    HMI_PB_StartPumpA                       HMI_PB_StartPumpA     HMI_StartPumpA
|--------| |--------------------------------------( U )----------------(  )-------|

And then I use the HMI_StartPumpA tag wherever I need that button in the code. The "PB" tag never gets used again.

This method makes all PB's a "one shot" operation, and means I never have to worry about stuck buttons.

As far as being time consuming, you'd be amazed what you can do with excel and copy/paste...you can generate the code for 100 buttons in 5 minutes with minimal effort

 

[Tharon]

I ran into this just recently when I migrated some HMI alarm text code from Micrologix to Contrologix. I was aware of the asynchronous I/O scanning, but didn't put two and two together to see that HMI comms was also.

My Micrologix alarm message code was written with "last one wins" in mind, and when I started it up on the Contorlogix, my alarm banner would be flashing, very quickly, between multiple messages. An undesired effect.

I also just moved my HMI message number into a buffer at the end of the program once, and then addressed the HMI to that buffer location.

A couple user defined datatype tags, one for use in the program, and another for use directly addressed in the HMI, and a COPY instruction would make the amount of work a little less daunting. The info to and from the HMI would only be updated once per scan.

As far as being time consuming, you'd be amazed what you can do with excel and copy/paste...you can generate the code for 100 buttons in 5 minutes with minimal effort

I've just wet my toes in the Studio 5000 pool. I used to be able to use notepad to copy/paste and modify large sections of repetitive 500 code, but haven't found out how to do it in 5000. 5000's exported excel data is a bit confusing, and copy/paste into a text format doesn't seem to work correctly.

 

[ASF]

I've just wet my toes in the Studio 5000 pool. I used to be able to use notepad to copy/paste and modify large sections of repetitive 500 code, but haven't found out how to do it in 5000. 5000's exported excel data is a bit confusing, and copy/paste into a text format doesn't seem to work correctly.

Copy each line of the below into separate cells in excel, one under the other:

XIC HMI_PB_1 OTU HMI_PB_1 OTE PB_1
XIC HMI_PB_2 OTU HMI_PB_2 OTE PB_2
XIC HMI_PB_3 OTU HMI_PB_3 OTE PB_3
XIC HMI_PB_4 OTU HMI_PB_4 OTE PB_4
XIC HMI_PB_5 OTU HMI_PB_5 OTE PB_5

Now, select the five cells and Ctrl+C

Open RSLogix 5000/Logix Designer and double click on an empty rung. Ctrl+V and enter.

I have to say it's a lot of fun when instead of 5 rungs it's the whole input mapping table for 5 remote I/O racks

 

[Tharon]

Hmm, that works. Works in Notepad too. And it's pretty much the exact same thing I was doing in 500.

I think I know what I did wrong my first try. In 500 I could just copy the rung directly and paste it in Notepad. But if I do that in 5000, it gives me this:

XIC(HMI_PB_1)OTU(HMI_PB_1)OTE(PB_1);

I actually have to double click and copy the text of the rung.

XIC HMI_PB_1 OTU HMI_PB_1 OTE PB_1

Then I can paste that over and over and make repetitive code. The rung copy with the extra parenthesis will not paste correctly.

Edit:
And sorry to rupej for a little bit of hijacking there. Didn't mean to.

 

[Paullys50]

I have to say it's a lot of fun when instead of 5 rungs it's the whole input mapping table for 5 remote I/O racks

I used to do that, now I have VBA code in my Excel IO list document to create all the tags, descriptions, and .L5X files that I can import for IO mapping and other "standard" logic.

 

[ASF]

I have VBA code in my Excel IO list document to create all the tags, descriptions, and .L5X files that I can import for IO mapping and other "standard" logic.

My template spreadsheet does also allow me to automatically generate tags, code and comments for all of my alarming, sensor filtering, scaling, etc. as well as I/O mapping. But I haven't got quite as far as the VBA yet

Anyway I hope rupej has got what he/she needed because we've well and truly derailed this thread

 

[Tim Ganz]

I always always always "map" my HMI PB tags. Not only for the reason that you describe, but because when you press a HMI button, it's not just continuously sending the PLC a message that the button is pressed, which it stops sending when you release the button - it sends one message when you press the button (set tag to 1) and one message when you release the button (set tag to 0). If that second message gets dropped, hey presto, stuck button!

So for every single PB on my HMI I have a line like this:

    HMI_PB_StartPumpA                       HMI_PB_StartPumpA     HMI_StartPumpA
|--------| |--------------------------------------( U )----------------(  )-------|

And then I use the HMI_StartPumpA tag wherever I need that button in the code. The "PB" tag never gets used again.

This method makes all PB's a "one shot" operation, and means I never have to worry about stuck buttons.

As far as being time consuming, you'd be amazed what you can do with excel and copy/paste...you can generate the code for 100 buttons in 5 minutes with minimal effort

I don't understand how your rung could work? How would the pump ever come on if you are unlatching what is making the rung true before the OTE for the pump?

 

[mk42]

I don't understand how your rung could work? How would the pump ever come on if you are unlatching what is making the rung true before the OTE for the pump?

I don't think coils affect the status of the rung. The contact evaluated as true when it was checked, the fact that it changes later on in the rung doesn't matter. It isn't evaluated again until next scan.

 

[ASF]

Tim, the rung executes once from left to right. Here's how the PLC sees this rung:

Element 1: XIC. Rung in condition: TRUE (connected directly to "power rail").

XIC will set rung out condition to TRUE, if tag is TRUE. Assuming operator has pressed button, HMI_PB_StartPumpA is TRUE, so rung out condition is TRUE.

Element 2: OTU. Rung in condition: TRUE (from previous element)

OTU will, if rung in condition is TRUE, set the attached tag to FALSE.
OTU will set rung out condition to match rung in condition. Since the rung in condition is TRUE, the rung out condition is TRUE

Element 3: OTE. Rung in condition: TRUE (from previous element)

OTE will, if rung in condition is TRUE, set the attached tag to TRUE.
HMI_StartPumpA is set to TRUE.


The PLC never goes back - it's decided that the rung in condition for the OTU is true, so that's what it is. For it to realise that the rung in condition is now false, it would have to scan the start of that rung again. It doesn't do that.

The next time around, of course, it will see that the XIC's tag is FALSE, so the OTU will do nothing to it's tag, and will change it's rung our condition to FALSE. The rung in condition to the OTE is now FALSE, so it sets it's tag to FALSE. Hey presto - oneshot PB!

Try it out - but as I've put hundreds of these rungs in every PLC program that has a touchscreen attached to it, and they work - I'm fairly confident