Crimson 3.0 - automatically map a set of display fields?

Hello all, I've been enjoying learning by lurking on this site and am hoping for some help going in the right direction.

Working with crimson 3.0, I am displaying many data variables from an engine controller that spits out data in a uniquely formatted string over serial. I'm new to the software and am picking up where another left off. The database has a pretty complete set of programs for parsing the string and passing variables to array tags, and those are displayed on a status screen (over 60 variables; 20 cylinder engine with sensors for temp, pressure, etc.)

Okay, so my task is to come up with an efficient strategy for duplicating these programs and display screens to report data for multiple different engines. I know enough now to be able to re-map all the tags and data primitives, but am hoping for a concise way to streamline or automate this process.

One idea I have is to group the tags, make a group id tag, and refer to the tag in all the data source fields I have. One data source is Unit1.C_EGT.C_EGT[4] and I want to replace <Unit1> with the value of a tag named unit1.unitid. I can't seem to get the syntax right. Help? If this works at least I can update all the data sources in one spot. Thanks!

Can you share your work? If allowed, you will have to zip it first to be accepted by the forum as an attachment to a post.

How to go about this will depend somewhat on how the data sources are divided...different devices on the same driver? Different areas of one controller?

In either case it is possible to set up the sources for your screen so that the fields reference array tags so you can use a pointer to look at different sets. The question then becomes how efficiently can you assign the data sources for those tags.

If your parsing programs are taking the data right off a serial port with a custom protocol, you should be able to handle the indirection there to populate the correct array element.

I would not do what you describe in the last paragraph, rather, I would make arrays of all the tags, and on the screen inside the array reference would be an internal tag representing the engine number.

So each element of the whole package is made into array tags, the array index represents the engine number you are viewing at a given time. If you are already using arrays for some of those elements, those would have to be broken back down unless that breaks a whole bunch of code...

I would have to know a lot more about how the data is collected and see the programs to help much more.

Paul

EDIT:
Here's a similar topic with examples for thought food.

Thanks for the response! I've witnessed your humility in other threads but it sure seems like you're the crimson badass.

Here's a stripped down copy of the database. The 'detail' page is the one with the bulk of the data boxes. I omitted a detail when I said it was a serial stream; we're using a serial-to-Ethernet device which assigns each ecu its own ip address. So there will be different protocols/drivers for each device monitored.

I think the last guy to work on this was headed in the direction you indicate about moving all the tags to arrays. I have a few different array tags for one engine and I'm confused about how to roll 'em all into one.

Maybe I don't have the right vocabulary here. When you say 'array' are you talking about the tag type or a particular way of displaying data with multiple values per primitive element?

It still sounds like I would have to update this pointer value for every individual display element- but I'm assuming I'm missing something.

I'll take a minute to look at the example you mention. Thanks again.