Red Lion Crimson 3 Data Tags

[Elcan]

We are ready to play!
Thank you in advance!

 

[MikeGranby]

Here it is...

http://www.crimson3.com/redlion/r2/redlion/c3b205.exe

The server it is on isn't our main download server, so it might be a bit slow. The command you need is the Create Data Tags command on the device page. It's supported on all AB drivers that use N7:0 style addressing. Let us know what you find.

 

[Elcan]

For me it works! I'm getting some errors that I will try to debug for you later, but it seems that most of the addresses (if not all) are imported.
If you want to go the extra mile, I would prefer to use the data description as the tag name in Crimson, not the address, i.e., "Start_Motor_1" instead of "B3_0_1").

Crimson customer service ROCKS!!!

 

[MikeGranby]

Elcan -- Can you let me have your CSV file and let me know which aren't importing? Re the tag naming, that won't work with some CSVs where the tag names would end up ridiculously long, so I think we're headed towards a dialog box to configure the import process.

 

[OkiePC]

. . .I think we're headed towards a dialog box to configure the import process.

That's a great idea, Mike.

I have some ideas for you:

A checkbox for "use symbol names as tag names."
A checkbox to use "PLC addresses as tag names (with special characters replaced with "_")"
A checkbox for "use address description line 1"
A checkbox for "use address description line 2"
A checkbox for "use address description line 3"
A checkbox for "use address description line 4"
A checkbox for "use address description line 5"

And a field to enter a prefix, and perhaps a field to enter a suffix...

You may also want some way to increment a trailing value if, for example the user only chooses the "Use symbols" box, and supplies a prefix, but there are multiple addresses with empty symbol name fields.

There are probably other good ideas along these lines, but these came to mind quickly and would give me all the versatility I would need.

Paul

 

[Brijm]

Elcan -- Can you let me have your CSV file and let me know which aren't importing? Re the tag naming, that won't work with some CSVs where the tag names would end up ridiculously long, so I think we're headed towards a dialog box to configure the import process.

Mike,

I downloaded the update, and tried it on a recent project. Using SLC 5/03... Everything imported nicely with a few errors. U file types (ladder address... not needed in HMI), M1,M0 files (buffer for Remote I/O again not needed), and some pfiles (not sure what these are, but not needed for HMI). These where all easy to find, with the error indicator in C3. Great work... and the quick response to a customer request is much appreciated.

-Brian

 

[MikeGranby]

Brian, can you send me the CSV with the errors so that we can at least stop those being imported? It will be a bit cleaner that way... Mike.

 

[OkiePC]

In addition to those listed, you may also want to ignore "Q" items in the PLC address column. Those are program labels, used with JMP and LBL pairs, and they will show up in the .csv export from RSLgogix5/500.

I don't know what the P files might be. Perhaps they are specific to one or more of the micrologix models?

 

[Brijm]

Brian, can you send me the CSV with the errors so that we can at least stop those being imported? It will be a bit cleaner that way... Mike.

Mike, I should be able to get you the file tomorrow...

-Brian

 

[Brijm]

Brian, can you send me the CSV with the errors so that we can at least stop those being imported? It will be a bit cleaner that way... Mike.

I'll send the file to Jeremy, since I have his E-mail address. But essentially, I think you would only want to look at the following file types.

(O)utput, (I)nput, (S)tatus, (B)inary, (T)imer, (C)ounter, st(R)ing, i(N)teger, and (F)loat

Micrologix also uses (MG) message, (L) long, (PD) PID, and (PLS) programmable limit switch instructions

Anything else can be ignored, (but someone else may.
You should be able to look at the file structure to see if the address is a bit or a word. Anything addressing a word, should be an integer, except for addresses prefixed "F" and "L".

-Brian

 

[DanYost]

Brian,

Can you send the file to me (dany) as well, Jeremy is out this morning.

Thank you,
Dan

 

[MikeGranby]

And how should we treat the L files? What do they contain?

 

[Brijm]

And how should we treat the L files? What do they contain?

Actually, I haven't used them much, L file would be a Long Integer. I believe all other integer files in AB are 16 bit.

 

[Clay B.]

And how should we treat the L files? What do they contain?

L Files contain "Long Words" or double integers or as some know it a DINT. I was just looking at the C3 and I did not see double integers in the pull down list for Treat As. I see floating point and signed integer but no double integer.

BTW... I really appriciate you guys working on this so fast. I had to travel right after I posted this thread and today is the first time I have got back to it. Nice job!!!!!

The C3 rocks... C2 was not bad once you got used to it but I really like the layout of the C3.

 

[MikeGranby]

The options in Treat As depend on the size of the item selected in the comms driver. If it's a 32-bit item, it can be treated as a signed integer or floating point. If it's 16 bits, it can be treated as either signed or unsigned. So, what that all comes down to is that we do support ready L registers as 32-bit values, the import ought to handle them. Thanks for all your help on this stuff, guys. It's good to hear from people who are actually using the product in the field.