Sign in to follow this  
Followers 0
Michael Lloyd

String Tags in an Add On

16 posts in this topic

I started creating Add On's a few years ago by converting some routines that I had written in structured text (like gas and liquid flow). My original UDT had two string tags in it. One for Tag Name and one for Description. I used the tags in faceplates in whatever HMI package that I was using (saved redundant typing). When I switch the routines to Add Ons I couldn't figure out how to make the string tags show up in the tag array. It's either impossible to do or really easy to do. I'm working on a tank rate of change Add On (to predict time to high level shutdown and low level shutdown) and I would like to add a string tag for increasing and decreasing. Was I missing something or is it impossible? Edited by Michael Lloyd

Share this post


Link to post
Share on other sites
A string, like any array in an AOI, must be an InOut type parameter. The AOI won't hold it as a local parameter.

Share this post


Link to post
Share on other sites
I'll give that a try. I had just started making Add-Ons and I didn't put a lot of effort into trying to figure out why my string tags weren't showing up in the array. <edit> Nope... that doesn't work... The Add-On doesn't like it. The tag doesn't display it.

Share this post


Link to post
Share on other sites
Please expand on those two statements - "The Add-On doesn't like it" - There are no issues in declaring STRING tags as In/Out parameters to Add-On Instructions. "The tag doesn't display it" - what tag? who is trying to display it? Tags don't display anything, they are the holders of the data that is displayed somewhere. Can you see the AOI STRING tag data with RSLogix5000? Presumably your HMI is having trouble addressing the AOI tags : What HMI are you using? What driver?

Share this post


Link to post
Share on other sites
The HMI is not the problem. the string tags are not in the tag structure. I haven't gotten to the HMI part but I anticipate that we won't have any trouble using the string tags if I can just get them to show up in the tag array since we already use them in other tags that I defined (User Defined).

Share this post


Link to post
Share on other sites
It all works The AOI will never have the UDT or Array as Input or Output parameters (only BOOL, SINT, INT, DINT, REAL) I think you are confusing the AOI tag with the InOut Tag

Share this post


Link to post
Share on other sites
Perhaps a tag export and examination of the visibility properties would help explain?

Share this post


Link to post
Share on other sites
I may not be explaining my problem very well but I'm not confusing AOI / UDT. I don't have problems with any other data type. I thought that you were on to something... I checked and I had put the string tags in the local tag section of the Add-On instruction definition. I'm not too sure how I managed that. I moved them to the Parameter section. Required and Visibility are both checked and greyed out. When I drag the Add-On into an FB routine I get an Argument Required error. I need to be able to uncheck the Required box and I prefer to be able to uncheck the visibility box but they are greyed out. I'm probably still doing something wrong but I can't figure out what it is.

Share this post


Link to post
Share on other sites
Maybe these will help Edited by Michael Lloyd

Share this post


Link to post
Share on other sites
I have no first hand experience creating AOI, and very little with UDT, but I have read threads which explain that once a UDT definition is edited outside of RSLogix5k, that you will no longer have access to some of those editor features while inside the Logix editor. http://www.plctalk.net/qanda/showthread.php?t=38560 I am not sure if something similar applies to AOI or whether you have done any importing...just something I read that seemed similar and may shed some light for you.

Share this post


Link to post
Share on other sites
An 'Input' parameter in an AOI is a tag space which may have an initialized value. On calling the AOI you supply, via the arguments (which may be constants) on the left hand side, a value. This gets copied into the internal 'input' tag. You can view this value within the functioning AOI. An 'output' parameter is a tag within the AOI into which the code places a computed value. You can view it. At the end of execution it gets copied to the tag supplied on the right side of the AOI. An 'InOut' tag DOES NOT EXIST WITHIN THE AOI. It is always external to the AOI. By giving a tag reference the AOI knows where to get information (the 'In' part) and where to store information (the 'Out' part). But the tag itself never directly enters the AOI. No internal tag is generated. All the information remains outside of the AOI. To see the results of the operation of the AOI you will have to monitor the external data which has been supplied as an InOut parameter.
1 person likes this

Share this post


Link to post
Share on other sites
That's what I was afraid of. I really don't think I can use a string tag in an AOI the way that I want to use it. The way that I want to use it, it's neither an in or out. I just want 2 string variables that I can write data to from the tag editor once the AOI is created and it's tags are generated. A string can't be an in or out. Edited by Michael Lloyd

Share this post


Link to post
Share on other sites
Why does the STRING tag have to be a parameter to the AOI. Just have a numeric "In" parameter that points to the string in a Controller-Scoped STRING array. The HMI can get the string data from there, instead of from the AOI's local tags. Or, if it has to be a parameter inside the AOI, declare a STRING local tag, first instruction COP the string from the controller-scoped array to the local parameter.

Share this post


Link to post
Share on other sites
Personal preference. I don't like to scatter needless code and tags throughout my programs. I like things to be streamlined and clean. That's why I use AOI's and UDT's in the first place. For me having to add code to compensate for something that can't be done within the AOI almost defeats the purpose of the AOI. I don't "need" string tags for the HMI, I would "like" to be able to use them. But not at the expense of cluttering up the program.

Share this post


Link to post
Share on other sites
All. Not sure if this will help anyone? But i have found a way of doing what the OP wanted to do and thought I would share. I had the same issues the OP had. Developed an AOI to control a SFC routine and wanted to use a couple of STRING's to annotate the current step of the sequence on a Citect super genie and didn't want to have to create different equipment types, wanted it all in one structure. After a lot of research I found a power point presentation that stated that local AOI tags can be referenced by a HMI if you know the address. eg - my_aoi_udt_instance.local_tag. To get it to work the following is required. To use a STRING, as stated previously pass it in to the AOI as an input/output then inside your AOI copy the IO STRING tag to the AOI local STRING tag. In structured text. COP(io_string, local_string, 1); Next you have to set the local tag for external access. You don't have the ability to set external access through the AOI definition window only input and output parameters, what you have to do is open the tag editor for the AOI and select the edit tab. From there you can set the local tags external access, by default it's set to none. I have only tried read only. Now all you have to do is edit the STRING externally to the AOI and that data is copied to the local STRING tag which can then be accessed through the HMI. I have only tested this using Citect using the built in ABCLX driver and it works like a brought one, not sure about Panelviews, etc. I also suspect that this method will work for other structures such as Array's, etc to be accessed by a HMI. Anyway hope someone else can benefit from this. cheers Mitch.

Share this post


Link to post
Share on other sites
And since I've just gone through the same process and had the same headache, here's the powerpoint presentation mentioned in the above post: http://www.rockwellautomation.cz/applications/gs/emea/GSCZ.nsf/files/SessionsmatroomB/$file/PPT_BW4.pdf :) It's useful for me (and probably Michael too) because then the whole popup can just call for Motor_1 to replace #1, and then it can be #1.Start, #1.Stop, #1.DescriptionString etc, rather than having to create #2 and every time point the popup to the motor AND to the string Edited by ASForrest

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0