MB TCP/IP Error Diagnosis

[CReese]

Super.

Let me know if you think of a smart way to do this.

[BobO]

The decision to not support device indirection in those instructions wasn't arbitrary. It was due to the fact that these client instructions adapt to the device's needs...internal Ethernet vs ECOM100 vs internal serial vs SERIO vs unknown future device. With a reference, we don't know what the device actually is until runtime...hence...we don't know which flavor to encode. We understood the need, but there were other issues.

I will look into the dead socket issue again. We have a maintenance release due in a couple of weeks. Maybe I can get something worked out.

In the meantime, PING will let you test the connection prior to establishing it.

[CReese]

Yes, the ping is working great for now.

[BobO]

After trying 15 things when I looked at this the first time, I think I figured out what I may have done wrong then...because at one time I thought I knew the combo to make it clean up faster, but it never would. It appears to be doing much better...

[BobO]

Ran all night bouncing back and forth between different slaves. Scan time never varied. We'll test more, but I call that fixed.

So...use PING to minimize the chance of an offline slave killing your throughput and be confident there is now no side effect to using round robin on a single device, other than reduced performance due to the PING and constant connect and disconnect.

This fix will be in the maintenance release due shortly.

[plcnut]

Cool beans! 

[CReese]

Neat! On to my next question, for another thread.