TCPLISTEN & STREAMIN

[MarkTTU]

I'm trying to get an ASCII string into a PLC from a PC. The PC is setup to stream the string to port 2055 on the IP of the BX-P-ECOMEX in a BRX.

I have a device created as a TCP Server configured for port 2055 and a TCPLISTEN command using that device and triggering a program that has a couple of stages.

First stage of the program is a STREAMIN command that uses the same device and waits for the length to be right or the delimiter character.

Second stage just parses the string; this works 100% of the time when I actually manage to get the string read in by the STREAMIN command.

Third stage does a DEVCLEAR and then fourth stage exits the program.

This all sometimes works, but also sometimes doesn't. When it doesn't I get an error in the PLC that says operation timed out in STREAMIN.

What am I missing here?

[franji1]

TYPICALLY, as the server, you technically have no control over what/when the client is doing with the connection.  This may be the cause of the strange behavior.  (caveat - see my assumptions at the bottom)

You probably should only EXIT the program after the client disconnects.  Add that as a condition to the first stage (where you are waiting for the STREAMIN).  The client may just be sitting there waiting for something for IT to do.  Or the client may disconnect.  THEN you should EXIT the program.

The Stream heap item contains a .Connected member.  So if in your initial stage, you see the .Connected member be OFF, go ahead and JMP to the 3rd stage to do a DEVCLEAR then the EXIT.

In the second stage, just jump back to the first stage unconditionally.  You may want to SET a bit in that stage to let $Main (or anything else) know that you processed the STREAMIN (then have $Main RST that bit).  You are probably looking for MyServerProgram.Done for that "processed" event - use a SET C bit for that.

So basically your Server PROGRAM code block should be in the first stage as long as the client decides to remain connected.  Once the current TCP client hangs up, your program should EXIT (so it can later process another connection from the same or different client).

CAN a Server hang up?  Sure.  DEVCLEAR will do that.  But realize the CLIENT is typically controlling when to hang up.  I'm guessing you are seeing some anomaly between it wanting to hang up and the server (the PLC) hanging up.

I am definitely making some assumptions.  For example, your client may NEVER "hang up", and is EXPECTING the SERVER to hang up to let the client know the processing was completed.  If this is the case, then there's something else going on that a good wireshark trace may point to the problem.

[BobO]

I'm trying to get an ASCII string into a PLC from a PC. The PC is setup to stream the string to port 2055 on the IP of the BX-P-ECOMEX in a BRX.

I have a device created as a TCP Server configured for port 2055 and a TCPLISTEN command using that device and triggering a program that has a couple of stages.

First stage of the program is a STREAMIN command that uses the same device and waits for the length to be right or the delimiter character.

Second stage just parses the string; this works 100% of the time when I actually manage to get the string read in by the STREAMIN command.

Third stage does a DEVCLEAR and then fourth stage exits the program.

This all sometimes works, but also sometimes doesn't. When it doesn't I get an error in the PLC that says operation timed out in STREAMIN.

What am I missing here?

What's the timeout? Are you certain the data is being sent as expected (as evidenced by Wireshark)?

[MarkTTU]

Using the .Connected has helped me get a better understanding of what I think is going on. Still randomly not working, but starting to think it's not on my end. I'm not on-site so can't make use of wireshark to investigate.

In $Main where I have TCPLISTEN do I need to interlock anything with the TCPLISTEN command? Do I need to put something like my program is not running for it to be listening?

In my program in the first stage I now have a NO .Connected for the STREAMIN command and a NC .Connected to jump to my DEVCLEAR stage.

After my second stage if .Connected is still on then I jump back to my first stage. If it's off then I'm jumping to DEVCLEAR and then exiting the program.

I've been told that by design the sending device will connect, send the string, and then disconnect.

I'm getting an error that I attempted to use a device that hasn't been opened in my STREAMIN command immediately followed by operations timed out in my STREAMIN command... not sure what's up with that. Timeout is set to 1000ms in the STREAMIN.

[BobO]

Interlock isn't necessary. It's done internally.

Are you expecting to stay connected constantly, or are you answering a request and then shutting down and waiting for the next request?

[MarkTTU]

I am not expecting to stay connected constantly. Expectation is to answer a request and then have the client close the connection and I wait for the next request.

I unchecked the timeout in the STREAMIN command and that seems to have fixed my issue not receiving the string. I tried running it up to 5s before I figured I don't really care how long it takes as long as the connection is open I'm perfectly fine with waiting to receive the string.

Interestingly I'm still getting an error that I attempted to use a device that hasn't been opened. Not sure if that's because I'm jumping back to my first stage before the client closes the connection and then the STREAMIN command has already been told to run, but then the connection gets closed on it or what.

[BobO]

I would answer the request, then CLOSE and EXIT without regard to the client.

[MarkTTU]

Good call. I tried adding in a 2s timer to wait and see if the client would close the connection or not and that fixed it, they close every time, but I think it's better to just close and exit and wait for them to re-establish.

Thanks for all the help! Looks like this one is finally reliably working. 

[BobO]

You're welcome! Glad it's working.