SS memory and pointers

[BobO]

I have reliably moved a LOT of data into a Do-more from local as well as remote servers over the past several years (ever since Do-more launched). I think that the way the timer rungs are structured are causing the issues. I *may* have time to do some testing some time next week.

Maybe, but I rewrote the read to chunk through the data as fast as I know how and it's dropping data. I want to play with it some more though.

[BobO]

It's what I thought. When the server drops the connection, that forces the PLC's socket closed. When the PLC's socket gets forced closed with data still in the buffer, we read that data and stuff into a cache so it's still available to the app. Since the PLC's are resource constrained and because we like to avoid dynamic allocation where possible (concerned about long term fragmentation), the buffer in the TCP Client is pre-allocated and only 1024 bytes. In this case there is well over 1K in the buffer, so it gets tossed on the floor.

Good news/bad news: The solution is simple (set cache size to match buffered data and dynamically allocate) and I'm willing to do it (low-ish fragmentation risk), but we are in the middle of development for a bunch of new modules we'll be rolling out next year, and the code is in no shape to release. Late Q1.

@Nut: You haven't had issues because your server isn't dumping you.

[Bolt]

I see.  Now I know what I am chasing.

Thanks for your looking into it, and an eventual solution!

In case anyone cares, here's my code to do it with.

Like I said, it works fine in the simulator, not reliably in the PLC.  And I'm not fond of my logic as far as searching separate strings, if the data falls partially between 2 strings, it throws a wrench in everything.

Load the program, load the memory parameters, open the data view, toggle C1210.

[BobO]

There really is a gray area here when the server forces the connection closed when the client hasn't closed it. I understand why they do it, and it isn't strictly prohibited by the spec, but it's the equivalent of hanging up on someone before they said goodbye. I had a workaround before, but the cache wasn't deep enough. I have a better workaround now.

[Bolt]

I have come up with an easy work around for this problem.

I wrote a simple php script on a server local to the PLC that fetches the file from the www, processes it into an array, and then only echo's the relevant data to the file (with some labels for parsing purposes).  Now I can get the data I want out of the file in a short, ~100 character response when the PLC reads the php file.

Now I have a question.  I am running multiple programs that create a TCP connection with the same server.  Do I :

1. keep them as separate devices (TCP clients)?
2. use the same device for each program?

Same device for all will run into issues with the DEVCLEAR instruction if multiple programs are running.

3. write all the comms with the server into just one program?