String data type within PROD_CONS

I am needing to transfer some prod_cons tags where the data type is a string[10]. Can you move a String data type?

Thanks in advance
RM

If you are using a a 5380 Compact Logix or a 5580 Control/GuardLogix on recent revisions the MOV command supports String types.

Otherwise use COP or CPS

I tried in an offline file but it says that "Produce/consume tags restricted to maximum size of 500 bytes." I reduced it to a 5 element array and it let me set it to produced with no problem.


Each string element is 82 characters plus a length. Each character is an 8-bit (1 byte) SINT element, so 82 bytes plus a DINT (4 bytes) gets you to 86 bytes. Times 5 elements in the array is 430 bytes.


Edited to add:
I haven't tried this with actual, live, machines so I can't verify that it would work "in real life", but it looks like you could split the data into 2 arrays and do it that way. Or, you could use an explicit MSG instruction.

plvlce said:

If you are using a a 5380 Compact Logix or a 5580 Control/GuardLogix on recent revisions the MOV command supports String types.

Otherwise use COP or CPS

Click to expand...

Not sure what that has to do with the OP's question

Strings are 88 bytes because of how Rockwell packs structs/UDT's. the LEN is 4 bytes, the data array is 82 bytes. The data array gets 2 additional pad bytes to align with 32 bit memory footprint. This begs the question, I wonder what drove them to choose 82 characters? They were throwing away 2 characters. An 84 character array would still consume 88 bytes.

Anyway, joseph_e2 has it right, it's the packet size limit of producer/consumer model. This is where MSG is handy, it doesn't have this size limit. If you don't need the data going back/forth at a continuous rate, just use MSG, otherwise, you'll have to setup multiple producer/consumers for this much data.

I wonder why Rockwell never implemented larger connection sizes for class 1 like they have for class 3 connections?

dmroeder said:

Not sure what that has to do with the OP's question

Click to expand...

Yes I paid too much attention to the second sentence and not enough to the first, and by the time I realized my mistake it was too late to edit.

Fortunately others came along to provide a proper answer.

plvlce said:

Yes I paid too much attention to the second sentence and not enough to the first, and by the time I realized my mistake it was too late to edit.

Fortunately others came along to provide a proper answer.

Click to expand...

Actually, I apparently didn't fully comprehend the OP's 2nd question. Your post makes more sense now. I took it as "moving between PLC's", I no longer see it that way. I'm going back to my corner to think about what I've done

dmroeder said:

Actually, I apparently didn't fully comprehend the OP's 2nd question. Your post makes more sense now. I took it as "moving between PLC's", I no longer see it that way. I'm going back to my corner to think about what I've done

Click to expand...

On a second read I interpret it as you first did, particularly given the existence of an actual issue with transferring a String[10] tag via prod/cons. I had read 'move' as referring specifically to the move (MOV) command, but he specifically mentions prod/cons so presumably there is transfer between PLCs somewhere. The actual question is not clear as to whether the 'move' he needs help with is intra- or inter-PLC however.

I guess we'll have to see if OP provides any clarification; I think a fairly complete answer has been reached regardless.

the 82 is a default but can be overridden in some environments, so if the 500-byte limit is indeed prod/cons, then it may be possible to use 44-character-length strings (so each string structure (object) uses 48chars), and then 10 would fit in the 500-element limit.

Sidebar: I would guess the 82-char default comes from the common/historical(/hysterical) 80-character terminal, plus carriage-return plus linefeed - why would anyone need any more than that ?

drbitboy said:

the 82 is a default but can be overridden in some environments, so if the 500-byte limit is indeed prod/cons, then it may be possible to use 44-character-length strings (so each string structure (object) uses 48chars), and then 10 would fit in the 500-element limit.

Click to expand...

The fine Dr. piqued my curiosity with this statement, so I had to try it for myself. I created a User Defined String tag with a limit of 44 characters in Studio 5000 V32. I then created the requisite produced and consumed tags in two PLCs, a 1769-L24ER-QB1B and a 1769-L24ERQBFC1B. I have never tried prod/cons with UDTs before so I wasn't actually sure if this would work or not. Turns out it does quite well. I don't get an error until I increase the limit of my UDString to a 45 character limit, which obviously exceeds the 500 byte limit.

I have to say, I never would have thought of doing this, but I also have never had the need to produce/consume large arrays of data. Usually a couple of DINTS and maybe the odd serial number or two.

MikeyN said:

The fine Dr. piqued my curiosity with this statement, so I had to try it for myself. ... I have to say, I never would have thought of doing this, ...

Click to expand...

It's just zeros and ones, it cannot be hard

- Jouni Ryno

Click to expand...

:heh:

dmroeder said:

Not sure what that has to do with the OP's question

Strings are 88 bytes because of how Rockwell packs structs/UDT's. the LEN is 4 bytes, the data array is 82 bytes. The data array gets 2 additional pad bytes to align with 32 bit memory footprint. This begs the question, I wonder what drove them to choose 82 characters? They were throwing away 2 characters. An 84 character array would still consume 88 bytes.

Anyway, joseph_e2 has it right, it's the packet size limit of producer/consumer model. This is where MSG is handy, it doesn't have this size limit. If you don't need the data going back/forth at a continuous rate, just use MSG, otherwise, you'll have to setup multiple producer/consumers for this much data.

I wonder why Rockwell never implemented larger connection sizes for class 1 like they have for class 3 connections?

Click to expand...

I’ve wondered about the string size question too.

The base Logix STRING type being defined to contain 82 characters could be the means of maintaining compatibility to the IEC-61131 type as other manufacturers implement it. There’s IEC STRING (1 byte length prefix, 1 byte char) and WSTRING (2 byte length prefix, 2 byte char). The de facto, default string capacity among manufacturers for the single-byte variant is 80, so the added 2 bytes could permit room for a simple COP into the .DATA portion of a Logix STRING if the length prefix is stored among the characters as 1 or 2 bytes. We as programmers are left to handle placing the returned content of a message into the appropriate nested .LEN and .DATA of what is actually a UDT-as-a-string. Despite being UDTs, they are marked internally as belonging to a family of type called "String". I suspect this is there as a hint for stuff like FTView to make heads or tails of how to handle and present tags it reads.

Example: try a GSV for the PATH of a given MODULE and then see the size of the length it returns. Also then look at the data type for a MESSAGE’s .Path attribute. It’s a STRING. You can’t directly apply the GSV against .Path; it always requires a bit of logic to handle the length being part of what’s really an array of bytes and its embedded length being a different size in bytes than the STRING’s .LEN contains. So cue a nested AOI I wrote to do so for device AOIs to set embedded message paths automatically.

One CIP shenanigan I wish were fixed in a new revision is the variable sizing of the connection to begin with. In my opinion, all conformant devices ought to produce and handle bidirectional 500-byte connection sizes, or the 4000-byte (?) large connection size. Nothing else. Also mandate that the required Identity Object attributes be embedded in each device’s produced data so that the consumer can more elegantly make decisions in code about how to handle consumed data: oh this is an OB16, I can extract point states in bytes x and y, or hey this is a PF525 so I will deliver its payload to an AOI parameter for unpacking and presenting its state, and so on. The packet size is always at least 512 bytes, so it isn't more efficient to only use 2 bytes as a connection size, for example.

Whenever possible, I make produced/consumed data sizes to be 500 bytes. If you ever have to add or remove in code what's being communicated, you can do so without bringing entire systems down for a download.

Sorry I have been MIA on this subject that I started. To clarify, we are passing data from a control logix plc to another control logix plc. We transfer an item number that is normally 6 characters (numbers). The common string data type we create is a STRING[10]. I was told by an integrator that you could not pass string data through PROD_CONS. By looking through the posts it looks like this is fairly straight forward. I would just need to create the UDT on both sides as STRING[10]'s. The reason for not messaging is we are transferring data from one company to another company where company A says that prod_cons are more secure. I am not 100% sold on that but here we are. Thanks!

remullis said:

Sorry I have been MIA on this subject that I started. To clarify, we are passing data from a control logix plc to another control logix plc. We transfer an item number that is normally 6 characters (numbers). The common string data type we create is a STRING[10]. I was told by an integrator that you could not pass string data through PROD_CONS. By looking through the posts it looks like this is fairly straight forward. I would just need to create the UDT on both sides as STRING[10]'s. The reason for not messaging is we are transferring data from one company to another company where company A says that prod_cons are more secure. I am not 100% sold on that but here we are. Thanks!

Click to expand...

To summarize the thread discussion:

• You can pass string data
• There is an upper limit of 500 bytes per tag when using prod/cons. Since the default String is 88 bytes, this limits you to 5 strings per tag. At a guess running into this limitation is why the integrator thought you couldn't pass strings.
• To get around this, either split your String[10] into two String[5] or (since you say your item number is 6 characters) you could define a smaller string size and use those for the prod/cons tags.

Or, if you can be certain the characters will always be numeric as opposed to alpha-numeric, you could extract the strings into a DINT[10], send it, and then re-pack it into strings on the other end.

plvlce said:

Or, if you can be certain the characters will always be numeric as opposed to alpha-numeric, you could extract the strings into a DINT[10], send it, and then re-pack it into strings on the other end.

Click to expand...

I thought immediately of the same thing; it's a bit of a rube goldberg/heath robinson, but definitely +1.

drbitboy said:

I thought immediately of the same thing; it's a bit of a rube goldberg/heath robinson, but definitely +1.

Click to expand...

The logic feels unnecessarily complex for just 'move data from PLC A to PLC B', but it avoids having to either use a non-standard String type or more than one tag so the actual prod/cons portion is straightforward.

In short, you can't just move a String[10] between two Logix PLCs using prod/cons. There's at least 3 different ways to actually get it done, but each may leave the next guy to come along scratching his head and wondering what you were thinking, just in different ways.

Whatever is done I'd recommend leaving some comments in the code.