Red Lion Crimson, tag source expert required

BryanG

Member
Join Date
Feb 2005
Location
Manchester
Posts
1,972
I am working on my own recipe system using Red Lion Crimson 3/3.1 which is going fine. The bit I am trying to get around is the requirement to have a tag on screen, before you can get a value in a Program with an instruction like GetIntTag(index). So if I have a tag called 'PaintColour' and I want to read its value within a program, I have to have the 'PaintColour' tag on the current screen or the value isn't read.

I noticed that in specifying tags you can set the source as another tag, so if I create 'doItAllTag' and set its source as 'PaintColour' then I don't have to have 'PaintColour' on screen to get the 'PaintColour' value to update, so long as I have 'doItAllTag' on screen.

So the next step from there, is there a way to have a variable tag name as my 'doItAllTag' tag source, so that I only have to have one tag on screen but can change its source name within the Program. Nothing I have tried has worked, but I am very much a beginner with Crimson and I may be attempting the impossible.
 
As a Crimson beginner I have been asking Red Lion support quite a lot of questions recently. In my mind I can see them saying 'oh heck, not him again'. So I thought I might ask the experts here first.
 
Hi Ben

Thanks for the reply. I can't send you the full database but I will put together a sample over the next few days.
 
I see some trees, but having a hard time identifying the forest.

What do your recipes look like?

Do you need them in csv format on the memory card for some specific reason?

Have you investigated using arrays?

Will these tags be associated with hardware (like a PLC)? If so, please provide some details.
 
Thanks for the interest guys.

In your real database, are the tags getting their data from a comms driver?
Yep, Siemens S7-1200. I didn't use any PLC tags because I didn't know which PLC you might have access to. There will obviously be an increase in time to collect the data but I think that in the Red Lion system a tag is a tag is a tag. So what applies for internal tags should still work with external ones, I think, but as I said I am very much a beginner with Crimson.

I see some trees, but having a hard time identifying the forest.
Should have gone to spec savers!! But if you haven't ever seen the TV advert it will mean nothing.
icon7.gif


What do your recipes look like?
Exactly the same as the master file but with an extra comma and data value tacked on the end of each line. And in reverse order.

Do you need them in csv format on the memory card for some specific reason?
CSV is a standard so I used it. I put the data on the card because it is the only storage device that I aware is available without using arrays.

Have you investigated using arrays?
Red Lion tech support sent me a copy of their sample recipe database that uses arrays. It is OK for a few tags but we store all the settings for a machine in a recipe and so we have over 200 tags. To me the array method is ugly even for a few tags, you have to create a new Program for each new recipe. With the system I am trying to write there would be one reusable program and as many master recipe files as you need.

I still need to write a file picker because each recipe is a new file. I don't have to set a limit beforehand for the number of recipes they can use, the limit is the size of the memory card.

I need to add strings to the existing system and test it with PLC tags and the big thing: see if there is any way to avoid the duplication of work in having to have all the tags on the screen and in the recipe. I did ask tech support if there was a way for me to know what tags are on a screen because then I could have used the Beijer old method of putting all the tags needed in a recipe on a screen and then adding a 'Create Recipe' button. Tech support said 'No'.
 
Do all your recipes exist in the PLC?

I can envision a method that would not need programs at all, simply array tags for each recipe element.

See attached example for Crimson 3.0
In my example, all the recipe tags are array tags. Point each one to the first element in your PLC, and it will read/write to 200 consecutive elements as needed.
Also, all the recipe tas are retentive. This is handy when working with the emulator and no PLC is connected yet.
I used the pattern of data based on your file, but I don't know what each item represents. In "real life" I would include that in each tag Label.
I do have a startup program that will populate the tags with noise if the first tag name is empty.
I normally don't recommend using string tags tied to a PLC unless there is some requirement that the PLC "know about" the recipe name or do some other processing with them.
 
Last edited:
I am pretty sure I know what’s going on. The way the Red Lion coms engine works is that it only populates data to tags that it thinks you need. When you put the tags on the screen, the Red Lion device knows that you want data for those tags so it populates them.


The reason it’s not working when you don’t have any tags on the screen, is because of what you are doing here:

cstring tagName, tagType, tagLength, tagValue;
int tagTypeAsInt, tagIndex;
tagIndex = FindTagIndex(tagName);
tagValueAsInt = TextToInt(tagValue, 10);
SetIntTag(tagIndex, tagValueAsInt);


You are not actually passing tag “data” you’re just passing a tag “index”. Then when you do try to get data from the index, the Red Lion just gives you the data currently in the tag, without first populating it.
 
I am pretty sure I know what’s going on. The way the Red Lion coms engine works is that it only populates data to tags that it thinks you need. When you put the tags on the screen, the Red Lion device knows that you want data for those tags so it populates them.
Absolutely that is what is happening and that is the bit I am trying to get around. I could just put 200 tags on to the screen, but it is extra work and more room to make mistakes. That is why I was exploring the fact that you can have a tag as source for another tag. So maybe I could have one tag on screen but cycle it through all the tags that I want to know the data for. There would certainly be a time penalty because it would take time for each tag to grab a value, but it would be a neater solution.

In my example, all the recipe tags are array tags. Point each one to the first element in your PLC, and it will read/write to 200 consecutive elements as needed.
Going to have to think about this, I seem to learn by osmosis, information kind of seeps in bit by bit, but when I have got it I have got it. Will have a play with the sample file.

I have been re-reading the manual and realised that I am not working with tag names but rather tag labels. Tag names are fixed but tag labels can be altered, for instance in a multi-language system. So a recipe on an English system wouldn't load on to a French system, if the tag labels had been translated.

There doesn't seem to be a way to access tag names or tag descriptions through a program.
 
I've been following this thread with interest but I'm not totally following your problem. I've implemented recipes in Crimson with several different methods but have never encountered the tag update issue you are experiencing. It seems like the problem stems from your use of the FindTagIndex() and GetIntTag() functions as BenDruck pointed out; I have no experience with these.

But... have you tried using Gateway Blocks? These are set up in the Communications area. Basically it allows you to do large transfers of data from an external comms device to your Crimson tags (or vice versa). You would configure your tags as Internal, then set up Gateway Block(s) to transfer the data into them. It can get a bit convoluted if your PLC data is not in consecutive registers, but the key feature for you is that you can force these updates to happen with the Request/Acknowledge actions.
 
Hi Kolyur

Sorry I am not always as clear as I intend. I have two problems, the first is a dislike of the Crimson recipe method, perhaps I should explain that one.

For my application I would have to create 200 new tag arrays, one for each of the PLC values I want to store, that in itself is a lot of wasted time. Then if I want to store all those values to a memory card I end up creating a single line in a file that is 200 tags long plus commas. Programming for each entry on the line is something like:

Code:
+ RecipeParam2[i].AsText + ","
To read that data back from the card I have to use 200 of:
Code:
    delim1 = Find(myLine,',',1);
    delim2 = Find(myLine,',',2);
    RecipeParam1[i]=TextToInt(Mid(myLine, delim1 + 1, delim2 - delim1 - 1), 10);
And I can't reuse the programming, it is specific to this one recipe. To me that is an ugly system.

So I looked to make my life easier, I have been around PLC and HMIs for many years and have seen two good ways of creating recipes. One was to put all the values you wanted in a recipe on one screen and then adding a Save Recipe button. I checked with tech support and that won't work because there is no function in the Program that knows what tags are on a screen. The second way is that you drag and drop tags in to a recipe function to create a master recipe, but I can't program in the drag and drop.

HMIs that I know well are the Beijer ones, not the newer IX developer where they took everything that was good about I/E Designer and threw it away. The old Beijer method of stroing recipes to memory card involves using one line of a semicolon separated file for each value in a recipe. Like this:
DB1.DBW62;A ;ST;2

Starting at that point I looked for an easy way to create a master recipe myself and I found that by exporting the Crimson tag database then importing in to a spreadsheet I can easily create rules that would give me a master recipe with very little time input. Then I moved on to the programming where I have posted a Program above. So far so good I have a simpler recipe system with code that can be reused.

The second problem and the one that is annoying me is that tag values are only updated if they are displayed on screen. So if I write a recipe program that reads tag values those tag values are zero unless I also have the tags on a recently displayed screen. So my nice simple recipe system gets more complicated because I also have to put 200 tags on to a screen. I am pretty sure this is a known issue and has been commented on a few times before on this website. But that doesn't mean I won't try to find a way round it, that was why I was playing with using a tag as a reference for a tag.

As Ben mentioned it is the GetIntTag, GetRealTag and GetStringTag that cause the problems, they only seem get data if it also exists as an on screen tag. Strangely SetIntTag, SetRealTag and SetStringTag do seem to work without having to have tags on screen.
 
Sorry to sound like an idiot but I'm still confused as to what you're trying to do. This is what I think is going on in your program: Your WriteRecipe program is going to read the MasterRecip.csv file which you created separately and basically has a list of tags in it. It then creates a second CSV file which contains the current data values of these tags. (I take it this is where your problem is--the tags don't necessarily contain current values from the PLC.) Your ReadRecipe program loads one of these recipe files, parses the contents and writes the data values back into the corresponding Crimson tags. Am I correct so far?

I'm still puzzled as to your intention here. You mentioned creating one program or set of programs that handles any recipe situation, but in the end the tag names still need to match the tags set up in Crimson. So I don't see what all the extra complexity is gaining you.

The array method is really quite simple. One array tag for each recipe element. The extent of the arrays would need to meet or exceed the number of different "products" you intend to have. You seemed hesitant at the thought of creating 200 array tags, but it can be done easily in Excel and imported. (I've created 1000+ alarm tags in this manner.) You also mentioned needing a separate program for each recipe--I don't see why. One program would transfer the array element data to the PLC tags, and one would go the other direction. Yes there would be 200 lines of code but so what? (You could probably generate these in Excel too.)

The arrays could be stored in retentive memory and you wouldn't need any other storage, but you could transfer them to the memory card in a variety of ways. In cases like yours where there are a lot of array elements, I typically create one file per "product" with a line for each array element. This makes the reading and writing simple as there are no commas to parse.

You are clearly an experienced programmer and probably wouldn't be doing all this if it wasn't necessary, so I feel like I'm still not understanding your requirements.
 

Similar Topics

Hi, I am trying to increase the size of the user login pop up using a Red Lion CR1000 7” HMI with Crimson 3.1 software. The login pop up is very...
Replies
2
Views
654
Hello, We are currently running a bunch of g310's connected to their SLC5 PLCs through ethernet. I've attempted to upgrade the program from 2.0...
Replies
1
Views
1,069
Hi I have been using Red Lion products for some time, I had a thought over the bank holiday weekend, As you do. It would be nice if whenever a...
Replies
4
Views
976
Well, I have yet another question for the great minds on this forum! We have a red lion HMI for one of our machines and every time I hook my...
Replies
11
Views
1,602
Yes it's very legacy.. but sometimes it's necessary to use old stuff for fun.. and because it's so much cheaper. Crimson 3.0 had the ability to...
Replies
4
Views
1,573
Back
Top Bottom