5380 MSG Read UDT from itself?

Can anyone confirm that a 5380 with version 32 should be able to Read a UDT with a MSG instruction from itself?

I am trying to test some messaging code and I only have one 5380 PLC.




I am getting the a "Parameter Error in Module Configuration" error see screen shot.


I am new to messaging in AB so, maybe the issue is something else.

Goal Read a UDT from a remote tag, Goal for another instruction Write a UDT to a remote tag.

To my knowledge there's no loopback adapter; you can't literally transmit a message to yourself on a physical Ethernet network.

Try entering "1,0" in the CIP Path, to send a CIP Generic MSG to the controller itself. That's how it worked on 1756 controllers, though I haven't done it with a modern CompactLogix.

I never tried to use loop back over 5580 ethernet port.
But I know it works with 1,<slot number>, I am using it time to time.

For 5380 controllers Ethernet port loop back functionality was not present in initial releases, but I believe it started working in V31 and used in some sample code applications, including DLR faceplate.

I did quick test with 5580 ver 32 and it works with Unconnected message
It does not work with Connected message.

Stupid question time.

What is a Connected vs. unconnected message?

theColonel26 said:

Stupid question time.
What is a Connected vs. unconnected message?

Click to expand...

The best answer I have is here:
https://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm094_-en-p.pdf
Page 110.

Now sure if it will answer your question...

theColonel26 said:

Stupid question time.

What is a Connected vs. unconnected message?

Click to expand...

It is not a stupid question, nor trivial, I think. It took me years to grasp this difference. Basically unconnected messaging does not require the establishment of a connection. So the unconnected request message is sent once, with all the required overhead, from the client to the server, and the server either responds or the connection times out if there is no answer. If another request needs to be sent, then all the overhead must be sent again. This is the main difference with respect to connected messaging, for which after the connection is established a lot of overhead needs not to be sent every time while the connection is established.

A connection is established between a client and a server or a scanner and adapter. The former is for connected explicit messaging and the later for implicit messaging (implicit messaging can only be connected messaging). The establishment of a connection requires a number of steps between a client and a server before the actual communication takes place.

If you download the Molex ODVA Tools you can study this with Wireshark, as the Molex tool (which is a CIP client application) allows you to select connected and unconnected messaging, and the Wireshark dissector for EtherNet/IP is superb and dissects the EtherNet/IP frame to a great extent. I think it is a bit easier in the beggining to play around with this tool and Wireshark and get a sense of what is going on, and then go to the CIP specification or the technical literature. I say this because these documents can be a bit overwhelming, especially trying to figure out where to start looking/reading.

Interesting take on connected vs. unconnected in a 2016 PLCTalk thread here, similar to previous responses in this thread. I think the last three posts are the key, and #4 especially is the money shot: a qualitative metric+ for when to use each.







TL;DR


+ "qualitative metric?" => possible oxymoron alert


What an interesting trail through The Google:




At first I thought it was simply like UDP vs. TCP; while there are some analogous aspects, it's more subtle than that.


Ultimately it comes down to a trade-off that depends on message scale:

• Connected cached: use connection object resources* to save the average CPU** used per message in subsequent repeat messages between the same two nodes.
• Unconnected Uncached: use more CPU** per message, for one-off or infrequent messages, because the CPU** savings lost, by not caching connection information, is insignificant and/or not worth the resources* for a connected message.
• Connected Uncached: combines the disadvantages of both***
• Unconnected Cached: does not exist.

* memory to cache the connection information
** to build the connection
*** In a document called "CompactLogix Performance and Capacity" from A-B, I found this statement "Alhough it is is possible to configure messages as Connected Uncached these messages consume more controller memory and take more time to complete than Unconnected Uncached messages while consuming as much or more resources ..."


From that same document: connected means resources are allocated and reserved and available for each message; cached means resources are allocated and reserved and available to a [message instruction].