Nano10 Remote File Services

[lberridge]

When using the Remote File Services from a Nano10 to TLServer running on a PC on a LAN, it is taking over ten seconds to append a modest amount of data to a file (25 events: "door open, door closed, etc". plus hour and minute time stamps.
During this time, no scanning of inputs can take place, since the data transfer happens within a loop in a special function similar to your examples in TestEthernet.PC6.
The Timer Interrupt would appear to be a solution but it doesn't seem to work during these data transfers.
Am I missing something?
Are interrupts disabled during this time?
Is there some block transfer capability which would reduce overhead and speed up data transfer?

[support]

How much data are you writing to the TLServer each time you open the file?

The process of writing data to the TLServer file itself is actually very fast.  However, TCP communication is a two way process. When the PLC sends a TCP packet to the TLServer (i.e. the PC), it waits for an ACK from the PC before sending the next packet. But the PC, being designed to handle large volume of data, does not like to send an ACK when it receive a small packet from the PLC. Instead it thinks that more data should be forthcoming and therefore it will wait for 200ms and only when nothing else is received, it will then send an ACK. In networking lingo this is called a "Delayed ACK". The "Delay ACK" action is a feature designed into the TCP/IP stack of Windows operating system and it is not something that TLServer can override.

The way the PLC handles the PRINT #4 command is that each time a PRINT #4 command is executed it sends a packet to the TLServer. Therefore if you break down your data into multiple PRINT #4 (say using a FOR NEXT loop to send a lot of DM data), the accumulated Delayed ACK adds up and make the whole process appear extremely slow.

So what you can do is to minimize the number of time PRINT #4 is run each time you want to write data to the TLServer. You can use the PRINT #4  <1st data>;<2nd data>;<3rd data> and so on to send most of the data in a single PRINT #4 statement. As long as the total number of bytes is < 128 in a single PRINT #4 command it will be sent out in a single packet.

For example, if you want to store the data of DM[1] to DM[10] to the TLServer in CSV format, instead of running PRINT #4 statements 10 times to print DM[1] to DM[10] each time, you can do the following:


PRINT #4 "<REMOTEFS 192.168.1.169:9080>"
PRINT #4 "<APPEND DataDump.TXT>"
PRINT #4 "DATE: ";DATE[1];"/";DATE[2];"/";DATE[3];",";"TIME:";TIME[1];":";TIME[2];":";TIME[3];",";
PRINT #4 DM[1];",";DM[2];",";DM[3];",";DM[4];",";DM[5];",";
PRINT #4 DM[6];",";DM[7];",";DM[8];",";;DM[9];",";DM[10]

PRINT #4 "</>"
PRINT #4 "</RemoteFS>"

A command such as the above would take < 2 seconds to complete opening a file on TLServer, append the date and time stamp and 10 DM variable data. All data are separated by comma and therefore it is a CSV format that can be easily imported into a spreadsheet or database.

[support]

Periodic timer interrupt (PTI), when properly setup should run even when the PLC is busy with writing data to the TLServer.

However, if your PTI is supposed to monitor the digital inputs or update some digital outputs, then you must run the REFRESH statement during the interrupt so that the logic states of the physical I/Os are updated. (You do not have to run REFRESH if you are reading or writing to analog I/O or run SETPWM. Only Digital I/Os require REFRESH statement to update the status).

[lberridge]

Thank you for your prompt and lucid explanation of my comm issues.
The REFRESH instruction  in the timer interrupt service routine completely solves my "missed input changes during data transfer" issues.
The 200 msec delayed ACK also completely explains the data transfer speeds I am observing.
My application now works fine, even with the inefficient use of the PRINT #4 in a program loop.
However, I would like to use F series products in future applications which require much higher PLC-to-TLServer ethernet throughput.
It is my understanding that a simple double buffering technique can almost completely eliminate this 200msec delay and dramatically increase TCP throughput. Is this possible in present or near future F series products?
Even with a full 128 byte buffer at (1/200msec) 5 packets per second, 640 bytes per second is quite slow.

[support]

The double-buffering technique you mentioned requires modification to the PLC firmware, which will not to be taken lightly since there is a lot of implications. Although we can suggest this to the R&D they may not want to add that modification, unless there is a very strong demand for such a modification.

An easier method may be to modify the Windows registry to eliminate the delayed acknowledge. You can try to follow the method described in the following document and see if that would help in your application:

http://support.microsoft.com/kb/823764

[lberridge]

The Windows registry modification is certainly possible, but each version of Windows may have different modifications required and this approach is not really a universal solution.

I understand the reluctance to make a firmware modification on a stable product, but when performance is impacted so dramatically as to open up a whole new class of applications,
(those that need or would benefit from high bandwidth), I think the business decision becomes much clearer.

Please consider this: if every packet sent from the PLC was immediately followed by a "dummy packet" whose entire purpose was to trigger an immediate ACK from the Windows TCP stack, would this not eliminate the dreaded 200msec delay?

I am going to be making a business presentation very soon which will include a demonstration of a Nano10 doing a simple control function and some really compelling event logging and email alerts.
I want to keep the discussion focused on the dramatic technical advancements in the cost and ease of implementation of this new generation of networked controllers and especially the compelling business benefits of monitoring and controlling
large numbers of assets spread over a wide geography.
The business people in my audience will be quite accustomed to transferring multi-megabyte files from around the world in a few seconds.
My demonstration would be far more effective if all communications appear to be instantaneous.
I am quite sure this scenario will be repeated thousands of times over the life of this product.

Thank you for listening to your customers and your consistently excellent technical support. These are the things which distinguish you from your competition (along with innovative, cost effective products)
 

[lberridge]

You may find the following reference useful:
http://msdn.microsoft.com/en-us/library/aa505957.aspx
Apparently, two segments are better than one.