PV+ Trending and Parameter File String Usage

[firebird0095 0]

I am using a PV+ with a compactlogix L32E processor. 1) In my program I have created a user defined data type that contains several different variables relating to one piece of equipment. I need to data log and trend several of these variables, but when I try to do this FTView lets me compile and does not complain while the PV itself claims I have used an invalid tag format for the data log. With a little help file research, it says - "You cannot log data for string tags, array tags, parameters or expressions, and you cannot use tag placeholders in your data log model." I am guessing it is considering my variables inside my user defined data type as parameters. It will however let me trend the variables embedded in the PID data type. What is the difference? Is there any way around this aside from creating independent tags somewhere else and MOVing everything? 2) I have a screen in the PV+ that uses a parameter file so that I have one screen that accesses 20 different sets of variables depending on the parameters sent when I open the screen. I want the title at the top of the screen to change to display what machine the operator is currently looking at. How can I use a value from a parameter file in a string for a textbox? Example - I created a parameter as #2='11' and attempted to use parameter #2 in my textbox as a string variable to display as "DCM 11" and that did not work. There has to be a way. Thanks

[bikerdude 0]

Firebird, There are 2 ways I know of to get the data to the PV+ without hassle. 1> Create "Alias" tags of the UDT members & point the PV+ to the aliases. 2> Create regular tags & move the values from the UDT members to them, pointing PV+ to the new tags. I have never used the "Parameter" files. I always just make the umpteen different screens & keep it simple although repetitive. I have seen programs created by others like in the picture below. This is not what I prefer but it works. The target screen has multiple objects. Some are integer displays some are string, whatever floats your boat. These objects can show different values if the tags in the PLC are loaded with different data. Depending upon which screen navigation button was pressed, the PLC tags values are loaded with different values. The same screen can be called up many times from different places, each time the PLC tags are re-loaded with the proper values accordingly. Hope this makes sense, you just about have to see it before it makes any sense. The reason I don't like this method is because it seems slow & sometimes the "Stale" data is momentarily displayed before the "Real" data shows up. I'll bet a clever programmer can prevent the stale data display with some extra special sauce added to the PLC/HMI programs. Good luck with your project BD

[BobLfoot 302]

Not exactly what you are looking for and I have no parameter file experience either but what about this. Step 1 - Assume your screen being displayed is Screen number 3. Write your code so that if you're on screen 3 you do the following. Step 2 - Send a variable to the PLC which indicates the Paramter Set in use. Tagname DintParamSet for example. Step 3 - Use a DTOS Instruction and convert that DINT to a String Tagname StringParamSet for example. Step 4 - Create a Tag ParameterSetHeaderString of type String and preload it with the DCM and a space. Step 5 - Concatentate the Strings ParameterSetHeaderString and StringParamSet into Tagname ParamterScreenHeaderString. Step 6 - Display ParameterScreenHeaderString on your screen.

[firebird0095 0]

Thanks for the input guys. I like the idea of only creating one screen and switching variables on the fly purely for the reduced memory usage and reduced chances for me to type something wrong and screw it up. Since nobody seems to have much experience with parameter files I will tell you what I have done and maybe someone can use it. Assumptions - We have 20 different machines and we want to display the same info for each machine on each of 20 different screens. Your data from the machines is stored in arrays or even better, UDTs. This allows us to play with the array index to pick the machine we want. 1) Create 20 parameter files. Lets use the first machine (machine 0 in computer world) as an example. Under "Graphics", right click on "Parameters" and select new. A box will pop up with a header in it, and below the header type #1=0. Hit save and type 0 as the component name. You now have a parameter file 0 that contains only 1 parameter(I don't know why AB cannot be consistent and start parameters at 0) and that parameter is the array index for our machine 0. Now you need to create 19 more parameter files. File 1 will contain #1=1, file 2 will contain #1=2... The #1 is the parameter number and the part to the right of the "=" is what the parameter file will return for that parameter when called. 2) Now you create your universal screen that you want to use for all 20 machines - let's call it SuperScreen. Say for example you have a box on that screen where you want to enter temperature. The variable for temperature is in the format of Machine[X].temp since we created a UDT that defines each machine, or it could be just Temp[X] if you created an array of DINTs to hold your temps. Instead of making 20 screens and changing from Machine[0].temp to Machine[1].temp... All we have to do is use Machine[#1].temp as our tag address and make sure we specify which parameter screen to use at runtime and the value in parameter #1 of that parameter file will be substituted as our array index. 3) Now you want to use this screen. On your main screen create a Goto Display button and under Display Settings select SuperScreen as your display and 0 as your parameter file. This will open our universal screen and display the data for machine 0. My problem comes when I want to use a parameter for something other then an address. Otherwise it works pretty well. Hopefully that makes sense. It really does make life a lot easier using parameter files. Hopefully AB will continue to enhance these functions and allow greater flexibility in working with strings and creating more powerful code. Thanks again.

[AJZ 0]

It can be done. I am working on an application that is doing it but I copied the screens from somebody else. I think you have to create 20 HMI string memory tags. The tags name should be the same as the data of a parameter. In your example the tag name should be 11. And enter initial data for the string tag. Now you can use #2 in your text box. FactoryTalk View 5.1 added some additional features regarding parameter lists: support for parameter lists in selected graphic objects, project settings, startup and logout; parameter passing using parameter lists.

[hbamos 0]

OK I have done this but it has been a while so please excuse me if I tell you wrong. I'm almost 100% sure your problem is just in the syntax you using. let me see if I can elaborate. example: #1={shortcut\Tag_Name} you can also display a fixed value in this way. The above should work, and their is no doubt in my mind that it works with user defined data type because I've done it. If you can't get it let me know and I'll pull out some of the old projects that used this technique. Their is also another way, you could create one screen and one user defined data type and using indirect addressing and the plc ability to change the hmi screen to show you the data from different machines. The second idea is not my favorite but I sadly admit I've done it. Also go and read the user manual for FTView ME, all this is in their. You can test this on your local machine without having to compile and transfer to the PV all the time. I usually create an ME app. just for testing these little problems as I work threw them, and then delete it later. hope this helps.

[firebird0095 0]

The UDT and the parameters were two separate issues. As you said, they work just fine together and you do not have to use an entire tag address as in your example. You can use a parameter as just a portion of a tag. What I could not do is use a parameter as a string. I had already done the trick of creating string tags and using the parameters to go to the appropriate string tag, but I don't like it. The whole point of using parameter files is to reduce the hard coding and keep things flexible. Creating more tags goes against this when I should just be able to concatenate a string from a parameter onto the end of one of my strings. I still need to get the new software as was suggested and see if that fixes it. The UDT issue was with data logging a UDT in a PV+. It does not work for some reason. The UDTs I was trying to use were already in two places in the program for my PID, so I just logged them from the PID(.sp, .out, .pv) and that works. I am now having another data logging issue where it seems to log some variables and not others and I am not getting any error messages. Oh and by the way there are no troubleshooting tools built in, so you are just left to speculate and try different things until the allen bradley gods smile upon you and your PV+ begins to log data as if by magic. Keep the faith.