Writting data to local PC

[TravisB]

I see that ExcelLink is the easiest method to get data off a PLC and onto a PC, but requires Excel be on the PC. I don't want to us the Email method because, as I understand it, I'd end up with a new email every hour when really I want to appened to an existing file. I get the impression that there are other methods as well, but I don't understand the jargon to know which one (Modbus, Multi-point, Host Link Protocol) I should spend my time learning about. I've read those chapters and I will need to spend a lot of time on wikipedia and elsewhere learning what all those words mean before I can proceed.

I have an onsite PC connected to the f1616-ba PLC via ethernet cable. It is dedicated to runing several operations and is expected to be "On" at all times, running TLServer. I would like to have the PLC initiate communication and send many DM fields to a location on the PC. Hourly, and appending to an existing file.

Where should I be looking?

[support]

You can read Chapter 2 of the User's Manual on "Network Services" where it explains how you can make use of the services provided by TLServer for the PLC to open a data file and the write data to it.

Basically you need to using the PRINT #4 command to send the "<REMOTEFS xxxx> tag to open a connection to TLServer and then using the PRINT #4 to send "<WRITE XXX>" to open a file on the TLServer subfolder, then use PRINT #4 to send the actual data to the PLC. You may need to close the file after you finished writing the data. To append new data you can use the "<APPEND>" command to append to an existing file.

There are example code in the "TestEthernet.PC6" sample program that you can download from our website (link is in the manual) or you can find it on your TRiLOGI folder.

[TravisB]

Thank you for the help, I've got some things working now. It seems that one "PRINT#4" starts a new line of printed text, so if you want several things on one line then keep adding them (with the +) and when you want to start a new line, do PRINT#4 again. I wan't able to get things to work and I believe the problem was I wasn't closing the RemoteFS. Once I got </RemoteFS> included in my code, several files from prior attempts showed up. I think they were out in computer limbo until released by the </> command.

 There are two things I havn't been able to figure out yet.
1) I can't get the PRINT#4 to work from within the "1stScan" function. I'm not sure why this is, and it's not a big problem as I've a workaround finished, but it would be nice to have the 1stScan put in the headers (first line of the file.)
Should the PRINT#4 work from 1stScan?

2) I can't format things exactly as I wish. I'd like to have the date,time, then data values all on the same line. The problem is to format the data values I need to run "If" statements to properly format decimal point data. The compiler seemed to prevent me from doing that.
Should the PRINT#4 work with IF statements?
example:
PRINT#4 "Text..."
 if A > B Then
  +A
 else
  +B
 endif
 if C > D Then
  +C
 else
  +D
 end if

PRINT#4 "End of File"

[support]

When the  PLC just come out of power on reset it may take longer to establish a network connection to the router than the PLC start up time. That's why PRINT #4 may not work in 1st.Scan. You can always start a timer when power on and when timer times out say 5 second later, then do the first PRINT #4 to make the connection.

Why don't you run the IF statement first and get your value into a variable, then run the PRINT statement with the variable as one of the argument (separated by semi-colon)?

[secs]

I am not sure if this is going to help but I use Modbus to do it. In my case I have my software read the data from the f24 unit, write it to Mysql database, write it to a log file and display it. Never failed yet.

[TravisB]

Wow secs, that looks great. I am already taxing my F1616 with all the tasks it is required to do, so I'm hesitant to push very much data through. I'm trying to talk the client into few data every hour and most data being sent/stored daily. (I'm also taxing my own brain just getting the basics working.)
At this end of this project I'd like to take everything I've learned at set up something similar for my home. It will be even more fun to work on this when I can do it /my/ way, and also without deadline.
I presently have the PRINT #4 command working, and we've decided we can do without storing decimal data, although I'm keeping in mind the suggestion that support gave for putting the print command inside the "IF"

[secs]

That's the best part about the way I do it and I am sure others. All my software does is query the master (the plc) to get the data. No code is added to the plc. I simply read a block of addresses. SO I give it a starting address and how many to read and the inbuilt modbus does the rest. If anything, I read the relays, inputs etc simply. I was looking to do it from the other end (plc) but like you, didn't want to tie it up doing stuff. In fact as an example, the outputs are read as 2 addresses only. They return a 16bit number and then in my software I have a function that decides if a particular bit (output or relay) is on or off

I am in no way saying you should do it this or any particular way, just showing how I do it. My database has about 1.5 mil records of power usage taken every 10 secs since April this year.

[TravisB]

After having the PLC and PC communicate reliably on an hourly cycle for a few months, the PC died. The client rebuilt the PC but ever since the rebuild the success of the PRINT #4 command has been sporadic/rare. It appears that one part of my code reliably sends data, but it's only a daily command. My hourly PRINT works less often than once a week. To be clear, days when none of the hourly data get's "print"ed I still get the once a day "print" from lower in the same function!
I've cleaned up the code, added </> and </RemoteFS> all over the place and even restarted TLServer a few times but I'm still not seeing results. I see that I have two options, either try to fix the problem using the same method (PRINT #4) or try a different method for datalogging. The client is requesting 1-minute datalogging, so I'm ready to put the burden on something besides the PLC.
1) Secs, if you're still listening, could you tell me what software you use to pull data off the PLC?
2) Is my generous application of opening and closing <RemoteFS> contributing to the problem?

I was thinking about this overnight and wanted to mention that I have no problem monitoring the PLC, so I know the connection through TLServer is working.

[support]

It sounds like a programming issue. Perhaps the last PC that diied had better network connection (than the new PC) and therefore did not expose the weakness of the code.

You may want to put in more checks in your code to ensure that it is connected to the TLServer via REMOTEFS command before it start writing data to the file.

Remember to close any previous connection your have made to the TLServer after you have finished the data writing. The PLC only supports a single client connection to the server and therefore it must be closed before another connection can be made. Do not leave the connection open but idle as the O/S may time it out.

There are also many other ways to log data beside using TLServer:

1) If your PLC has firmware r78 and above you can also add FRAM-RTC-256 to get 256K bytes of data file space. You will be able to write data to the file locally and once a day or so you can upload the entire data file you have created via FTP to a PC or a remote FTP server on the Internet.  This may be the most reliable method since it doesn't depend on a constant good network connection to a PC or server, especially if you need to log data very frequently such as every minute or seconds. At the end of a fixed time period you can upload the data file via FTP and if upload fail you can retry until the file is successfully uploaded.

2) You can also use an online webserver with mySQL database with a PHP interface that let your PLC connect to the server to update data periodically.  You can visit www.plclog.com for an example of such a service.

[secs]

1) Secs, if you're still listening, could you tell me what software you use to pull data off the PLC?



Well I use a compnent in Delphi to read and write to the Modbus address. The software image with the dials etc is a stand alone program. It compiles into a exe written using Delphi 7. The Modbus component is a free component.
I then write it to MySql via tcp sockets...
Not sure if that helps.

PS: It polls the data every 10 seconds. I ran the thing basically non stop for about 5 months and eneded up with millions of records in the database.

[can]

Hi. Searching for an answer to one of my problem and I came across this thread. Went to read up more to see what my options are. Found this paragraph in Chapter 4 of programming manual. How do I get PLC to check for the OK tag?


The TLServer will close the file after it receives the end-ofservice
tag "</>" from the PLC and it will in turn send a
"<OK>" string to the PLC to acknowledge that the WRITE
request has been completed successfully. It is up to your
PLC program to check for the "<OK>" tag to determine i

[support]

The PLC can read what's the TLServer return to it using the INPUT$(n) command where n is the comm port number depending on which serial port of the PLC you use to connect to the TLServer.


A$ = INPUT$(1)
SETLCD 1,1, "A$=" + A$
IF STRCMP(A$, "<OK>")=0
   ....
ELSE
   ....
ENDIF