TCP STREAMOUT problems

[BobO]

Hmmm... Puzzled by the 6 bytes in .InQueue while disconnected. I do cache the bytes remaining in the queue when the socket is being forced closed by the server, and I just found a bug in the Simulator where that value was lying at times, but I don't know of any issues in the DM1 implementation. That bothers me.

Aside from that, .Connected is what you need to be testing if you want to conditionally call OPENTCP. It really doesn't matter though, OPENTCP does the same check internally, so it is never a problem to start your request by calling it.

Please try this for me: Add an OPENTCP that you can manually trigger. Enable it and watch the .Connected member. If it turns on, and goes right back off, your server is terminating the connection due to inactivity or possibly security. That is not at all uncommon with things like web or mail servers where they are processing bazillions of requests very quickly and even short periods of inactivity on a port can cause some server constipation. Admittedly the 30 to 50ms seems very quick for a forced termination, but let's start there.

[plcnut]

Hmmm... Puzzled by the 6 bytes in .InQueue while disconnected.

I know that I am recieving some bytes that I am not using, and so I stop STREAMIN before the .InQueue is empty, if that helps explain.

Please try this for me: Add an OPENTCP that you can manually trigger. Enable it and watch the .Connected member.

It stays .Open and .Connected until I Close the connection.

[BobO]

It stays .Open and .Connected until I Close the connection.

What happens if you do more than one like that?

[plcnut]

What happens if you do more than one like that?

2 of them do the same thing. Perfect.

[plcnut]

Just for kicks I tried placing the OPENTCPs and CLOSEs in stages in their own program block and they reacted in the same way. I could even EXIT the program and they stayed open until I CLOSEd them.

[BobO]

Just for kicks I tried placing the OPENTCPs and CLOSEs in stages in their own program block and they reacted in the same way. I could even EXIT the program and they stayed open until I CLOSEd them.

So it sounds like it is working correctly, no?

[plcnut]

So it sounds like it is working correctly, no?

Yes, It sounds like it is good. I have not had a chance to go back over any of my program yet to see if I have left anything out.
I'm preparing to go over it though because I need to do some more testing with it.
I'll let you know what I find.

[BobO]

I'll let you know what I find.

Please. Unlike some automation companies, we actually care.

This really hasn't proven anything conclusively. There may or may still be issues, and the greater complexity of your project may cause them or make it difficult to find the programming error if there is one. But bein' as this isn't my first rodeo, I tend to back waaay up and reestablish that gravity is still functioning correctly, and then move forward into increasingly more complicated stuff. Questions like "why does it fail there and work here" become invaluable in pinning down either a coding error or replicating the bug for engineering.

[plcnut]

I disabled the only CLOSE in my program for this TCP connection, and now as soon as I get to the second STREAMOUT that uses that connection it throws the "Attempted to use a device that is disconnected.." error. The .Connected is staying on steady, but the .Connected is turning off.

I am able to receive the first response, and apparently that is when the .Connected turns off. I can't tell with the Trend view though because the .InQueue and .OutQueue are not updating on the graph. I guess that has to do with problem you mentioned earlier???

[BobO]

It sounds like your server is giving you a response and then disconnecting. Very common.

I don't know why the .InQueue member wouldn't update. The issue I mentioned was only related to the simulator.

[plcnut]

I re-wrote so I call the OPENTCP before every transaction and so far so good.

[plcnut]

I don't know if this is related to the previous problem or not, but, every time I use STREAMOUT to DMLogger it gets everything twice. I have all STREAMOUTs set to use "JMP to Stage" so there is not any looping. I also placed a PD coil of the SG bit that drives an INC in each stage and they are only incrementing once.
Any ideas? I don't know WireShark well enough to use it to confirm whether the data is streaming twice, or if the logger is double printing.

[BobO]

Maybe. Do you have dual NICs? Perhaps something wireless that is actually connected to the network?

[plcnut]

OK, I feel dumb... it was the dual NIC's. I normally keep my wireless card disabled, but it was on.
Thank you.