Red Lion Crimson 3.1 - Data tags with complex code

Hello,

I have 6 RTUs all with the same program load. I am trying to setup my HMI with one set of data tags and one set of screens and use a pointer or variable that will reference the RTU. I was hoping to set this RTU variable when they push the button to navigate to the screen. I am not sure the syntax or how I am supposed to configure my data tags to achieve this.

RTU would be my variable so I was hoping something like this in a complex code expression would work: return [RTU.000600];

Values for RTU would be sep01, sep02.....sep06

I am trying not to have 6 different sets of data tags and screens with the only difference being the device. Any tips or best practices would be greatly appreciated. I am new to these Red Lion HMI's.

Thanks.

Welcome to the PLCTalk forum community !

What exact model of HMI and RTU devices are you using ? What networks and protocols ?

Crimson 3.1 is marginally newer, and there's less experience here with the Sixnet RTUs and the modern Graphite and Core/Edge controllers than with the classic G3 and DataStation products.

I think that the way to do this would be to make the network address of your RTU a Tag instead of an explicit address (like an IP address), and set the value of that Tag when you switch screens.

The concern is how fresh your data would be when you switch screens; if the HMI is happily polling whatever-RTU-was-last-addressed in the background and you switch to an RTU detail screen and update the address to a new RTU, you're going to have stale/incorrect data until the updates from the new RTU complete.

Alternately, I don't know if you can programmatically change a Tag Folder in Crimson. Whenever I pose a Crimson programming question to the Forum, I end up leaning quite a lot that's not obviously in the manuals.

jt__ said:

Hello,

I have 6 RTUs all with the same program load. I am trying to setup my HMI with one set of data tags and one set of screens and use a pointer or variable that will reference the RTU. I was hoping to set this RTU variable when they push the button to navigate to the screen. I am not sure the syntax or how I am supposed to configure my data tags to achieve this.

RTU would be my variable so I was hoping something like this in a complex code expression would work: return [RTU.000600];

Values for RTU would be sep01, sep02.....sep06

I am trying not to have 6 different sets of data tags and screens with the only difference being the device. Any tips or best practices would be greatly appreciated. I am new to these Red Lion HMI's.

Thanks.

Click to expand...

I think you are going to spend more time trying to figure out how not to build six sets of data and six screens than you would just doing it.

I've lost count on how many Crimson 2.0, 3.0 and 3.1 systems I have done, and here is how I would do it.

1. Create a single RTU (i.e. RTU1) and then a Folder (named RTU1_Tags, for example) to contain the data tags.
2. Add all the data tags to that folder.
3. Save the file and then save it with a new name.
4. Open both configurations
5. In the original configuration, add all 6 RTUs RTU1 to RTU6
6. In the second configuration, rename RTU1 the name of your second RTU (i.e. RTU2) - that will make all the tags look for RTU2.
7. Rename the folder RTU2_Tags
8. Drag and drop the Tag Folder into the first configuration - since it will find RTU2 in the communication section, they will remain linked to RTU2.
9. In the second configuration, rename the RTU2 to RTU3 and the Folder from RTU2_Tags to RTU3_Tags and drag it to the original configuration.
10. Continue doing this until you have all 6 created. Note: it took me longer to type this than it would have taken me to do it.
11. Now that you have all 6 sets of tags in your original configuration, you can create a single display with all the tags you want to show, turn it into a widget with folder binding (check the manual on how to do this) and save it.
12. Copy it 5 more times and bind the widget to RTU2_Tags, and then the next screen bind to RTU3_Tags, etc.
13. If you don't want to deal with the widget, you could go back to the beginning and add a step to the process. Before copying the configuration, build the RTU1, RTU1_Tags folder, and then the screen to show everything (i.e. RTU1_Page). Copy your configuration and open both.
14. In the second configuration and in this order, rename RTU1 to RTU2, rename the Folder RTU1_Tags to RTU2_Tags, rename the screen RTU2_Page, then drag them to the original configuration in that order.
15. You will need to add buttons to navigate between the screens.

Seriously, it took me longer to type this out that it would have taken me to create all six RTUS, Tag Folders, and Screens.

This is a little trick I learned a long time ago...

In the time it took JHarbin to describe his experience and the alternative Widget and Copy/Folder methods, I came up with a more difficult and complex way to do part of the challenge with the FindTagIndex() and GetIntTag() functions, using a String Tag as a Folder Name.

That has happened to me a few times with this Forum and specifically with Red Lion Crimson software, where I came up with something difficult and time-consuming, and somebody else posted "nope, that's baked into the software already, here's how it works".

:site:

One thing I have done a few times to reduce my time editing is to use tag arrays.

Instead of assigning all the Crimson tags to PLC addresses like [ML.N090:0000] where ML is the device name of my Micrologix, N90:0 is the address, I will create an array of tags named "D" with that as the data source. So "D" is assigned a data source of [ML.N090:0000] and given an array length of 100. I will also set the Read Mode of the array not to read the entire array in most cases (I usually pick read 2 either side).

Then say i have four water wells. They all have the same data structure and follow a pattern all stored in that N90 integer file...

I will "folderize" my tags...Example:
"Well_1.Offset" is an internal tag that represents the starting element for Well 1 tags. I will make its data source internal and set it to "10".

"Well_1.Status" will have its data source set to "D[Offset]"
"Well_1.GPM" will have its data source set to "D[Offset+1]"
"Well_1.Hours" will have its data source set to "D[Offset+2]"

Then I copy and paste the Well_1 tag folder five times. Now i Have 6 folders of tags named Well_1 through Well_6. I edit the internal value of the offset for each of them, and now I am done...Suppose there are 10 elements for each well, I assign N90:0 to N90:9 for Well_1, N90:10 through N90:19 for Well 2...

By making the Well_2.Offset = 10, the rest of the tags in its folder are based on that offset, so they automatically get assigned in the right part of the file.

This extra work to set things up like this is only handy if you have more than a small handful of objects to repeat. I also use widgets with folder binding...it took me a lot of effort to wrap my head around how widgets work...I had to build one for myself and play with it in the Emulator in 3.0 to get the concept down.

Sidenote: the latest versions of 3.1 have the Emulator button and Emulator items in the Link Option, but they are grayed out. They are teasing me. Hopefully this means that 3.1 will soon be getting a working emulator...

OkiePC said:

One thing I have done a few times to reduce my time editing is to use tag arrays.

Instead of assigning a tag to [ML.N090:0000] where ML is the device name of my Micrologix, N90:0 is the address, I will create an array of tags named "D" with that as the data source.

Then say i have four water wells. They all have the same data structure and follow a pattern all stored in that N90 integer file...

I will "folderize my tags...Exsmple:
"Well_1.Offset" is an internal tag that represents the starting element for Well 1 tags. I will make its data source internal and set it to "10".

"Well_1.Status" will have its data source set to "D[Offset]"
"Well_1.GPM" will have its data source set to "D[Offset+1]"
"Well_1.Hours" will have its data source set to "D[Offset+2]"

Then I copy and paste the Well_1 tag folder five times. Now i Have 6 folders of tags named Well_1 through Well_6. I edit the internal value of the offset for each of them, and now I am done...Suppose there are 10 elements for each well, I assign N90:0 to N90:9 for Well_1, N90:10 through N90:19 for Well 2...

By making the Well_2.Offset = 10, the rest of the tags in its folder are based on that offset, so they automatically get assigned in the right part of the file.

This extra work to set things up like this is only handy if you have more than a small handful of objects to repeat.

Click to expand...

Yea, I thought about Arrays and have done this also with great success, but since he has 6 RTUs, the data is in the same registers in different devices. Arrays wouldn't work in this case.

Thanks for the tips. I will probably just go with the folder/copy method and have 6 sets of tags and screens. Too bad there was not easier way to template and re-use screens in Crimson.

jt__ said:

Thanks for the tips. I will probably just go with the folder/copy method and have 6 sets of tags and screens. Too bad there was not easier way to template and re-use screens in Crimson.

Click to expand...

I discussed this with Mike Granby years ago, sort of a "late binding" on widgets. I think it is easier to describe than implement.

As has been described earlier, I've used the FindTagIndex() and GetIntTag() functions in Crimson 2.0 to work around the limitation, but working with Widgets and Tag Folders seemed so easy, I decided to use that method.

Really, the primary thing you lose is that if you decide to change one screen, you have to change all 6. That's why I would make the screen a widget. If I need to make a change to all the screens, I update one of the widgets and copy them to the other screens and re-bind. Not elegant, but it works.