MSG Instruction in Guardlogix 1756-L72S (I can't send a larger string)

[ABTracking]

I am trying to send data from my Guardlogix 1756-L72S to a Leibinger JET3 UP PI Printer trough a MSG instruction, I can send information if the sitring is not above 504 characters, but if the string is grather than 504 characteres I can't send any data, or in other words te printer doesn't recive the string command and the MSG instruction doesn't show any error code or message.

I have the same configuration in a ControlLogix 1756-L72 to do the same with the same Printer make and model and in this processor works fine, it send string avobe 504 chatacters without problem.
I have changed the printer thinking that the problem was the printer configuration but nothing, the printer configuration is the same, basically I switched the printers and the printer used with the GuardLogix where I have the issue recive all the data with a ControlLogix, and the printer used in the ControlLogix working fine doesn't recive all the data with a GuardLogix when the String is larger than 504 characters size.

I have the MSG instruction configured as follows:
Message Type: CIP Generic
Service Type: WriteSocket
When my string sended is a 504 characters string size...
Source element: Printer_MsgData.Write_Source
Source Length: 520
Printer_MsgData.Write_SizeSent

When my string size is 505 or above...
Source element: Printer_MsgData.Write_Source
Source Length: 521 (Depending of the string size)
Printer_MsgData.Write_SizeSent

I don't know why only in my GuardLogix I can't send data above 504 Characters in a String, maybe I think the processor is a little different than a ControlLogix, but I have the question if I can't send a bigger string with my GuardLogix and why with my ControlLogix I can do that?

 

[Timbert]

I vaguely remember running into a limit with the size GuardLogix produced safety tags. Are you sending this message from within the safety task?

 

[ABTracking]

Thanks for the information Timbert but no, the MSG instruction is within the main task outside of the safety task, but yes I have considerably many safety tags all used in the processor.

 

[Contr_Conn]

This has nothing to do with Safety task, this was a ~500 byte limitation of the CIP message.
It was addressed since the initial Sockets release.

Take a look at the Communications tab, then check "Large Connection" box.
This will allow to send much larger strings, up to 4000 bytes.
See
http://literature.rockwellautomation.com/idc/groups/literature/documents/at/enet-at002_-en-p.pdf
Page 17

 

[Geospark]

More specific info can be found here...

586061 - Large CIP Generic Message Support (Mostly For Open Sockets)
Access Level: Everyone

Take note of the minimum project versions required and limitations with the CompactLogix controllers. Also note the reference to the configuration used for the newer L8 controller's embedded Ethernet ports.

Regards,
George

 

[ABTracking]

Thanks for your support folks,
Contr_Conn, I had already configured the Large Connection box checked, I did a test unchecking the large connection box but when I did that, the MSG instruction send me an error code 16#006 (Insufficient packet space. Request too large). So I put it back to check. The problem is that te MSG instruction doesn't send me any error but doesn't send information to my printer (or my printer doesn't receive the information) when the string is above 504 characters or bytes. Neither the printer nor the PLC send me any error just doesn't send or receive data.

Also I tested changing the Ethernet module from 1756-EN2T to 1756-EN2TR Revision 10.001 but still with the problem. I am using a Studio 5000 Logix Designer V28.12, I checked all the configurations but the issue persist.

Geospark, Thanks for the information, very detailed information and very helpful but I still with the problem.

I breaked the string in two parts and I sended the information by parts, it works for now but I am not convenced about the correct function of the MSG instruction. Maybe the GuardLogix 1756-L72S has a problem specially with this instruction but I think that is so rare.

 

[Contr_Conn]

It's been more than 2 years since I touched this functionality.
It was fully functional then.

I would do Wireshark trace to see what is on the wire coming out of EN2T first.

What is the revision of your EN2T module (from RSLinx)?
This may be also problem because EN2T needs to have this support as well.

I would recommend that you open a ticket with Technical support and let them look at your application.

 

[ABTracking]

The revision of the EN2T is 10.007, I saw in the information that you shared with me:
(1)Large connections are supported only by 1756-EN2xx ControlLogix modules in RSLogix 5000 software, version 20 or later.

So I reviewed that and made test with other EN2T Module and I reviewed the revision but everything seems fine.

I'll contact Technical Support for this issue.

Thanks again

 

[Contr_Conn]

EN2T 10.007 supports is and Controller V28 supports it too.
Hard to say what is wrong without seen your code and Wireshark trace.
I am not sure what Sockets skills LA techsupport has, so ask then to escalate it to US techsupport right away.

If you can post you application snippet here, then I can take a look.

 

[ABTracking]

Thanks for your support Contr_Conn, you will not believe me!
It was a big error in my data type tags, damn!
I had the tags "Printer_MsgData.Read_Data" and "Printer_MsgData.Write_Data" used in the Socket as data type "STR_500" in my GuardLogix while in my ControlLogix these was configured conrrectly with the data type "STR_1000".
Now everything is working fine.
Thanks for your support guys.

 

[Geospark]

For the sake of clarity for any readers not quite sure what you are referring to here with regard to using the wrong data type...

The predefined STRING data type is 82 bytes in size, not including any overhead used. Each byte holding one string character. So that is a maximum of 82 string or ascii characters. This is sufficient for most applications but in some cases, such as here, a greater number of characters is required to be exchanged simultaneously with a device. In these cases, a user-defined string data type (UDT) may be created, containing a larger, or indeed smaller number of characters...

50650 - Custom STRING data types and copy to/from standard STRING tags
Access Level: TechConnect

The above data types - STR_500; STR_1000 have undoubtedly been user-defined as string data types to store 500 and 1000 characters respectively. The user-defined tags, assigned for the MSG read and write data, were incorrectly created as data type STR_500, instead of STR_1000. This, of course, restricted the MSG instruction to only reading or writing 500 characters per execution.

The other danger, with making this kind of mistake, is if a tag of a larger string data type, or SINT array, is initially copying character data into a string data type that holds less characters. Here, erroneous data may be unexpectedly copied to memory beyond the intented destination tag. Example: 1000 characters into 500. A COP instruction, with a length of 1000, will blindly copy 1000 bytes of data to the destination tag of 500 bytes, and beyond into the next 500 bytes of contiguous data in memory. This memory could contain data related to other important functions within a control system. This could simply be troublesome, but could also result in unintended operations.

Always try to remember to check your data types when creating tags. The software, or controller, can't always tell you when you've gone wrong.

Regards,
George