Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: plcnut on April 08, 2013, 08:22:03 AM
-
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.
-
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...
-
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.
-
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?
-
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).
-
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.
-
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...
-
I did update my DoMore OS last week...
-
If I use the OPENTCP before each use of the Device then I can make the program run.
-
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.
-
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...
-
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).
-
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.
-
Thanks for your work on it Bob! Don't forget to sleep sometime though... Speaking of sleep...
-
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.
-
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.
-
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.
-
It stays .Open and .Connected until I Close the connection.
What happens if you do more than one like that?
-
What happens if you do more than one like that?
2 of them do the same thing. Perfect.
-
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.
-
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?
-
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.
-
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.
-
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???
-
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.
-
I re-wrote so I call the OPENTCP before every transaction and so far so good.
-
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.
-
Maybe. Do you have dual NICs? Perhaps something wireless that is actually connected to the network?
-
OK, I feel dumb... it was the dual NIC's. I normally keep my wireless card disabled, but it was on.
Thank you.