Crimson Gurus: Setpoint program in a G308

TConnolly

Lifetime Supporting Member
Join Date
Apr 2005
Location
Salt Lake City
Posts
6,152
I'm trying to set up a setpoint program in a G308 for a vacuum furnace. I want to allow the user to have up to 20 program profiles to select from, and each program profile has 25 segments (See graphic for example). Each segment contains 9 parameters.

attachment.php


I've attached a basic Crimson 3 DB (not a complete project DB) to give a general idea of what I'm after but I don't want to create folders for each segment and I'd rather not create folders for all 20 programs so I'm looking for suggestions from the Crimson Gurus on the best way to structure the tag DB. Obviously arrays are probably the best way to go but then how is the best way to handle multiple program profiles?

Also since not all segments will fit on one screen the operator is going to have to scroll through them - I'd rather use just one screen - I've worked out how to do this with an array on a dummy project but being able to do that will probably affect how to structure the database.

I'm entertaining the possibility of storing the program profiles on a CF card, in which case the 20 program capacity becomes moot.

TC121212-1.JPG
 

Attachments

  • VacuumFurnace.zip
    18.1 KB · Views: 14
I'm trying to set up a setpoint program in a G308 for a vacuum furnace. I want to allow the user to have up to 20 program profiles to select from, and each program profile has 25 segments (See graphic for example). Each segment contains 9 parameters.

attachment.php


I've attached a basic Crimson 3 DB (not a complete project DB) to give a general idea of what I'm after but I don't want to create folders for each segment and I'd rather not create folders for all 20 programs so I'm looking for suggestions from the Crimson Gurus on the best way to structure the tag DB. Obviously arrays are probably the best way to go but then how is the best way to handle multiple program profiles?

Also since not all segments will fit on one screen the operator is going to have to scroll through them - I'd rather use just one screen - I've worked out how to do this with an array on a dummy project but being able to do that will probably affect how to structure the database.

I'm entertaining the possibility of storing the program profiles on a CF card, in which case the 20 program capacity becomes moot.


Why not go ahead and buy the HC900 and do it right?
 
Using the CompactFlash would be my choice. I'd probably make a separate CSV file for each profile; each file would have 25 rows and 9 columns (or vice versa) for the segments and parameters. Selecting a profile would read in the corresponding file to a series of arrays, say one per segment. If you want to show the segments in groups of three, you'd probably have to have another set of arrays for display purposes.

Another option would be to create one big array for all the data, and break it into three dimensions in software. For example, profile#15 segment#18 parameter#8 would be index 15*18*8=2160 of the array. Crimson appears to support retentive arrays with up to 16,000 elements but everything would have to be the same datatype. Lots of fun coding with this option, however it would keep your number of data tags and arrays to a minimum.

Does the operator have to be able to modify the parameters?
 
I made changes to the original cd3 file to show one example of how to use array tags and get the segments scrolling. I moved and manipulated the tags in the original, and made them into arrays, so the formatting should be the same, and added a couple of tags to keep track of the profile number and the segment number being displayed, and a derived tag to calculate the offset when you scroll to a different segment number or profile.

Basically, what I did was make an array where the displayed segment index is equal to the profile number multiplied by the number of spaces reserved for each (tag set to constant 25) added to the offset for how far you have scrolled.

I added some ramp (scroll) buttons for both the profile and the segment numbers. It would probably be useful to reset the segment number when the profile number is changed. On the other hand, it might be useful to leave it alone and be able to compare, for example, segment 17 and 18 between two different profiles.

Anyway, I used two sets of array tags. One is for the parameters that apply to the whole profile, and the other set is for parameters that apply to each of the possible segments.
 
Last edited:
I moved and manipulated the tags in the original, and made them into arrays, so the formatting should be the same

Except for the first two or three tags. I think I "remade" those and didn't make the labels identical. Nonetheless, the concept and how to address them is the same.

The drawback to using array tags come into play if you need unique properties for individual members, but aside from that, I just flattened your 2d array into a single dim for the segments with a calculated index right in the tag source, and kept the array tags for the profiles in a folder of their own.

Crimson editor tip: I renamed those index tags at the end of my edits. They were all single character so I could easily type, copy and paste them. If you decide to use that logic and build on it and find yourself writing a lot of expressions or complex code with them, change them back to something like i, a, and b.

When you are all done and want to make it more human readable, rename the tags with more beefy meanings.
 
Last edited:
While listening to the Thunder eek out a win...

I polished it up a bit more. I think I numbered the segments starting with 1 and the profiles starting with 0.

I made the scrolling more visual (color bands), and resized it a bit.

I added a program to initialize the (now retentive) tags on a one time basis with random numbers and made the string tags editable.

As long as you don't flush the emulator files or reboot your PC, the data is retained even in the emulator. . .which is painfully error prone in this newest build.
 
Thanks Paul. I wasn't expecting a whole app but thank you very much. 🍺 I had already moved ahead with creating a screen that allowed me to use just one screen to scroll through all the segments (here is what I had done, its similar to what you did) but I hadn't decided on how to structure the tags yet. Thank you very much for the suggestions.

ETA: I had to laugh at your recipes after looking at your second version. I even had considered adding a scrolling background like you did. Thanks again - If I'm ever in OK I'm buying you lunch.
 
Last edited:
ETA: I had to laugh at your recipes after looking at your second version. I even had considered adding a scrolling background like you did. Thanks again - If I'm ever in OK I'm buying you lunch.

I thought you might get a kick out of that. I needed some values so I could test the work. At that hour, I was struggling a bit with recipe names 🍺

More thoughts:
Are those segment records and profile data stored in a PLC at some point? If they are device tags, you may be able to use gateway blocks or direct reference a UDT tag with a nicer structure instead of a flat file of 500 or more records.
 
Last edited:

Similar Topics

Hey guys, hoping someone here could give me a little advice. I'm working with a CR1000-04000 in Crimson 3.1 and I was interested in adding the...
Replies
4
Views
99
Hi, I'm having an issue in crimson 3.0 when I create a programme using a case statement referencing a fault word that each bit needs to change the...
Replies
1
Views
85
How do you install update on Red Lion Crimson ver 3.1. Do I just need to run the exe file on the host server?
Replies
1
Views
103
Has anyone found a way to convert/replace/update the firmware on old Parker TS80xx series HMIs (i.e. TS8010, TS8006, etc) to accept Crimson...
Replies
0
Views
88
Has anyone setup communications with Red Lion 3.0 MODBUS to Baker Hughes Centrilift GCS VFD? Thanks
Replies
0
Views
86
Back
Top Bottom