AB Socket Logic - Message Command Using Previous Instance

I'm hooking up a scale to an EWEB card on a 1756 PLC through ethernet/IP sockets, and I've run into an issue that seems to defy ladder logic. See the attached image for the relevant part of the rung.

So, I've got a move instruction moving the socket instance number from the results of the Create Socket message instruction to the Instance tag in the tag for the Write Socket message instruction. This normally works and is working correctly in other rungs in the same program. However, periodically I get the "Class or instance not supported" error from this rung.

I added the bottom branch to the rung to help diagnose this program, and as you can see, the instance number that was in the message tag at the time of the instruction's enabling and erroring out is not the number of the instance that is currently open. Specifically, it is the number of the previous instance that this message instruction was referring to.

And, for reference, the rungs with the timer and the latched bit are like that for testing, I know they're kind of dumb. They don't seem to be part of the issue, though.

Am I wrong to think that this doesn't make any sense? Do any of you see an error or mistake that I've missed, or have an idea that I could try?

Thank you for reading if you make it this far; I tried not to miss any details, so it ended up wordy.

I don't have experience, but do you know which instruction is causing the error?

It sounds like an edge case, maybe the instance in Ohaus0_Socket_Create_Instance is invalid during some scans.

Could we split this out into four rungs and see which rung/instruction is causing the problem?

• The MOVe into .Instance
• The MSG
  • BTW, where is the trigger for this MSG? Or are you clearing the .EN bit somewhere else?
• The timer test
• The MOVe test

There is a fully functional AOI available from the sample code library, probably should use it.

Also there is TN 32962 has a working test code and windows based test application.

Contr_Conn said:

There is a fully functional AOI available from the sample code library, probably should use it.

Also there is TN 32962 has a working test code and windows based test application.

Click to expand...

From another thread, I think @Horseshoe00 is using that AOI.

TN 32962 is not the same as the AOI that is available on the Sample code site

@drbitboy I'll see if I can break it up reasonably. Also, the trigger is on the same rung, just upstream. It's ugly, and linked to multiple other conditions in different rungs. I had some clean rungs before that seemed to work fine, but the scale I'm using isn't very well suited to our application and I'm having to get creative to fit it in our target cycle time. I'll grab a screenshot and post it here soon.

@Contr_Conn I'll look into that AOI, that would make things simpler. I did make these rungs using that TN as a reference. I'll have to see what the AOI's capabilities are.

To bring you all a bit further up to speed on the context, I'm polling this scale with a write command and two read commands. In order to bring down the cycle time of the weighing, I'm creating and opening the socket, polling it multiple times, then periodically closing the socket and opening a new instance. This error is occuring while I have the socket refreshing every five seconds, though the planned refresh rate is every two minutes. This is also why the trigger logic is ugly, as I've forced it to integrate smoothly into the rest of the logic.

(Don't ask why it needs two read commands, it doesn't if I use an EN2T but that causes another issue that would require I start a different thread and I'm morally/financially opposed to crowdsourcing my entire job. It works and this project is already taking longer than intended, so I'd rather not try to "fix" it now.)

Here's the complete rung, hopefully it answers more questions than it poses. The rung below it was troubleshooting for another thing; the outputs from MSG instructions apparently update asynchronously from the ladder scan, so that rung gave me a bit that updates with the scan.

The messaging by the MSG is going to be triggered on only the scans that detect rising edges of the result of the logic of those branches of XICs and XIOs at the start of the rung.

But the MSG instruction itself will execute on all scans when that logic result is True.


So if there is a scan where the logic result is True, but the MOV puts a "bad" (whatever that means) value into the .Instance attribute, that could cause the problem, even if the state of the MSG input rung would not otherwise affect anything because it is not a rising edge. If that is the case, then a one-shot gate after the branches of XICs and XIOs would ensure the MOV only occurs when needed.

I would do a cross reference of Ohous0_Socket_Create_Instance, and make sure the only (intended) destructive reference is the message that creates the socket, the socket create message was not in error, and the socket create message is not inadvertently being triggered, unless there in an intention to have multiple instances.

In addition to what's already been stated, you might consider using sequence/state-wise message handling, especially when doing the coordinated multi-messaging that the Logix Socket object requires.

Longer and longer of arbitrary BOOL evaluations like:

get tougher and tougher to troubleshoot (and may even run poorly when it does work), when instead the message trigger logic could amount to:


Further, the 1756-EWEB card is probably the least performant of all 1756 ethernet cards. To avoid timing issues or race conditions, utilizing the step approach like this:


prior to assigning the new socket instance Id to the next message's instance field will guarantee that you are in fact using the correct value as soon as it becomes available.

The timing and consistency issues blur even more so when you begin talking about carrying out your specific application's use of the Socket object (Modbus TCP, NTP, and so on).