Proper use of TCPLISTEN

[plcnut]

What is the proper use of TCPLISTEN as far as CLOSEing the connections? I want to make sure that I am not going to cause adverse affects to scan time or to network traffic by not handling the connections properly. Thanks

[BobO]

TCPLISTEN opens a listening socket, and upon receiving a connection request, accepts a new connection and RUNs the specified program. From that point, it is basically indistinguishable from a connection established by OPENTCP.

Since we don't have threads or true objects in Do-more (yet), it was only possible to support a single connection per server device. Were this a PC type server, you would allocate a socket and a new server thread instance for up to n connections per server.

[plcnut]

Bob, I have been using TCPLISTEN, and all was working fine, and now it is working very sporadically.
I had been using CLOSE at the end of each transaction, and then I tried removing it, and everything went haywire from there (even after putting the CLOSE back in). I also notice that my CLOSE instruction will lock sometimes( watching it using Device Status).
I have attached a screenshot of a trendview monitoring the TCP connection.
Does it look right? (Is .open supposed to turn off whenever .connected turns on?)
Thank you.


<edit> forgot the pic 

[BobO]

Something sounds very unhappy. You may have found a bug (imagine that ).

Have you power cycled, or gone to program mode and back? You might try changing the struct to non-retentive and power cycling.

Also, under 'Clear PLC Memory...' you might try clearing just the Image Register.

Meanwhile, we'll do some thrash testing and see if we can dupe it. If you happen to find a way to get it into this mode, likewise please let me know. Love to get the fix into 1.1...

[plcnut]

Have you power cycled, or gone to program mode and back?

Yes, and yes.

You might try changing the struct to non-retentive and power cycling.

The $TCPServer?

Also, under 'Clear PLC Memory...' you might try clearing just the Image Register.

I need to know the ramifications of doing this. I can't afford to dump my database... that would be a REALLY BAD DAY.
 

Meanwhile, we'll do some thrash testing and see if we can dupe it. If you happen to find a way to get it into this mode, likewise please let me know. Love to get the fix into 1.1...

Are the .connected and .open backwards?

[BobO]

You might try changing the struct to non-retentive and power cycling.

The $TCPServer?

Yes.

Also, under 'Clear PLC Memory...' you might try clearing just the Image Register.

I need to know the ramifications of doing this. I can't afford to dump my database... that would be a REALLY BAD DAY.

It would wipe the PLC's retentive image register. Sounds like that would be a bad thing. You do have that backed up right?

Are the .connected and .open backwards?

I doubt it, but it's possible.

[plcnut]

I changed the TCPServer to non retentive, will test it tomorrow..

I have used the "Backup" button in DMD, I assume that saves my Database? if not, then no, it's not backed up.

On the .connected/.open issue, I am only questioning what I am seeing in the TrendView. Is the screenshot what it is supposed to look like?

[BobO]

I have used the "Backup" button in DMD, I assume that saves my Database? if not, then no, it's not backed up.

No. If you want to save/restore the full memory state, you need to create a memory image. Go to Tools>Memory Image Manager. It takes a snapshot of the memory state and stores it to the project file. It is a completely manual operation...both directions. In the future we want to make it easier, but for now that's the way it is done.

The project backup is just stashing a copy of the project...not the PLC's memory contents.

On the .connected/.open issue, I am only questioning what I am seeing in the TrendView. Is the screenshot what it is supposed to look like?

You are telling me that it is malfunctioning though, right? Once the train has jumped the rails, the memory state is suspect and I would draw no conclusions from it.

[plcnut]

  I will do a memory image first thing tomorrow!

I'm not sure what is going on with the TCPLISTEN. It appears that when I used it to start a program, and then did an EXIT but did not CLOSE the connection, it left the connection in a state where I could not close it or open it. In the midst of troubleshooting, I noticed that whenever the system was 'idle', the .open member was on, but when I would use a web browser to open the connection, .open would turn off, and .connected would turn on. I expected the .open and .connected to both be on when a transaction was taking place.

[BobO]

I don't see that, but I'm also calling CLOSE before EXIT. There may be some busted logic. I'll dig a bit more. Clearly it is misbehaving due to something unknown, and once it isn't working correctly, all bets are off about bit states and such.

[plcnut]

Memory Image Manager doesn't work  
It will only copy portions of the memory and then it will give me an warning:
"Attention! Communications error while reading region! Continue updating? Yes/No"
When I click yes it pops right back up. When I click no, it will show the memory that it copied, but it isn't copying any of the memory areas that are important. It isn't getting any of the user defined structures that are over 700 long.  

[plcnut]

I did some testing with another connection and there is definitely a problem with the status bits.
Now how to duplicate it...

[plcnut]

Bob,
I changed the port number of the TCP server to a different port (it was on 2, I changed it to 3). I then set up a new TCP server and set it to use port 2. Then I went through my program and changed all the instructions to use the new server that I had set up, then downloaded all the changes. The new server has all the same issues as the old one did (status bits out of whack and only works part of the time).

[BobO]

Dude...I'm at a loss...

I have a Do-more TCP server that is getting the poo beat out of it. Another PLC connects, receives a time/date string, and closes. I've tried CLOSEing and not CLOSEing before EXITing. It's running completely clean...my .Open is always true, and my .Connected is toggling as the other controller connects. Just curious...is your TCPLISTEN input staying on, or are you turning it on and off?

Also...Memory Image Manager is working fine for me...even with large user blocks.

You've sent it to us before, I think, but it might be nice ti get a fresh copy of your program. Something feels very off...

[plcnut]

Umm...<Big red ears> I don't remember why I did it, but I had the .Running bit for the program the the TCPLISTEN runs, inline as a NOT with the TCPLISTEN... Ooops.

I deleted it and things look much better.

I wonder if the Memory Image Manager problem is getting tripped up by the same thing that locks up DataView when viewing long strings? Something in my computer maybe...