TCP STREAMOUT problems

[plcnut]

I have several different program blocks in my project that are working perfectly using this same method, but I just added a new program that is persistently giving me this error: "Attempted to use a device that is disconnected...in STREAMOUT" ...

I have set up different "TCP Client Devices" for each of my program blocks even though some of them are referencing the same server, I thought it would make it simpler to troubleshoot, this is the way I set up the new block as well.
I went back and attempted to make my new block use a known working TCP Client Deveice (that is being used in a different block), but it gives the same error.

In the block I have a timer in the first stage that is JMPing to the next stage where I check if the client connection is open, if not then JMP to the OPENTCP stage, if open then JMP to the STREAMOUT. The STREAMOUT errors every time.

There are a total of (5) TCP clients being used in this project.

Please advise.

[plcnut]

OK, I got it working.
I'm not sure exactly what was causing my problem but here are the 2 things I did.

(1) I eliminated any "checking" to see if the device was open. I now run the OPENTCP every time the program is called.

(2) I reassigned all references to the TCP Client device and then used the memory editor to delete the device. I then created a new TCP Client and then went back and reassigned all device references in my program block to the new device.

How I got to this point: On reexamining my program, I realized that in one of the other TCP blocks that was working, that the device was never being closed in the program, and yet every time the program was called a counter would increment when tied to the ".open" bit for the device. Upon further scrutiny, I realized that I was referencing the wrong .open bit to trigger the OPENTCP for that program, meaning that OPENTCP was being called every time the program was used. And so after reassigning the Device in the new program I set it to call the OPENTCP every time and it is now working...

[plcnut]

There is still something wrong.

Just a few stages later I try to do another STREAMOUT using the same device in the same program block, and now I am getting the error there...

Did I hit some kind of limit with number of connections?
Could my PC be be closing the connection?

Any advice is appreciated.

[franji1]

If some of them are referencing the same Server, could it be that your Server is running out of TCP connections?  Are you trying to have multiple connections to the same server on the same port?  Does your server support that?

[plcnut]

If some of them are referencing the same Server, could it be that your Server is running out of TCP connections?

I don't know. This part is over my head.

  Are you trying to have multiple connections to the same server on the same port?

Yes. Can I use http GET requests over ports other than 80?

  Does your server support that?

I don't know, I am running WAMPSERVER (Apache 2.2.22) on my laptop until development is done, and then I will switch the addressing over to our main server (the latest and greatest according to our IT guys).

[franji1]

If you are using an actual PC SERVER, then you should have no issues on THAT side.  I wasn't sure what your "server" was.

[BobO]

There is still something wrong.

Just a few stages later I try to do another STREAMOUT using the same device in the same program block, and now I am getting the error there...

Did I hit some kind of limit with number of connections?
Could my PC be be closing the connection?

Any advice is appreciated.

Lemme do some playing. There is always the possibility that something got broke along the way...

[plcnut]

I did update my DoMore OS last week...

[plcnut]

If I use the OPENTCP before each use of the Device then I can make the program run.

[BobO]

If I use the OPENTCP before each use of the Device then I can make the program run.

OPENTCP will just make sure the server is connected. When you were checking before calling it before, were you checking .Connected and/or .Open?

'.Open' means that a device is opened from a previous call to OPENxxx...this is a generic device mechanism that doesn't have anything to do with TCP connections per se. '.Connected' means the TCP client/server connection is active. A TCP client can be .Open and not .Connected if the server has dropped the connection.

[BobO]

It appears to be dropping the connection when I don't think it should be. It may be an inactivity timer somewhere, but I'm thinking it isn't working like I would expect. Investigating...

[plcnut]

In another block I'm doing 8 tcp transactions in 400-500 msec and if I put a counter on the .open it will count to eight every time, even though I never close the connection(programmatically).

[BobO]

Mine was a coding error. I had some cross contamination between the two program blocks. Once I fixed it, my connection is staying opening and running fine.

FWIW...not saying there isn't an issue...but on no less than 3 occasions today, I have sworn it wasn't working right and it turned out to be a coding error. It is very easy to do when you create copies of the same code and modify it.

I did find a couple of things in the implementation I don't like however. One was that once a STREAMIN has passed the initial check for a connection, it doesn't check on subsequent scans. The code was there for the check and I had commented it out. What bothers me is I don't remember why I removed it, and I didn't leave myself any bread crumbs, which I generally do. Adding the check back in allows STREAMIN to fail due to a lost connection when no timeout was configured. Truthfully, it is pretty bad form to not use a timeout, but, it is worse form to allow an instruction to get hung badly enough that a trip to program mode is required. So I put the checks back in. It will be interesting to see what I just broke.

The other thing I found that I don't like is that the OPENTCP was not setting the .Connected member immediately upon completion, but relying on some background code that manages it after it is open. What this means is that if anything was expecting .Connected to be true between the completion of OPENTCP and the bottom of the current scan, it might be wrongly concluding that the connection is closed. Upon reflecting on it, that seems like that could be a pretty big deal...I would fully expect code to be testing the connection immediately after opening. That could be causing you trouble.

[plcnut]

Thanks for your work on it Bob! Don't forget to sleep sometime though... Speaking of sleep...

[plcnut]

OPENTCP will just make sure the server is connected. When you were checking before calling it before, were you checking .Connected and/or .Open?

I was monitoring .open

In my dataview, while the program is running, I can watch the .Open and it "appears" to be on all the time with only a spike down every couple seconds, but the .Connected stays off and then rapidly flashes on and off during transactions.

I have attached a screenshot of a Trend View as well as a .txt file of the same trend. As I scrolled through, I noticed that sometimes the .open would stay on through all 8 transactions, and then at other times it may have to re-open several times right along with the .connected.

Hopefully this will help you in troubleshooting. Meanwhile I will scour over my ladder again for mistakes on my end.