I do agree with the FTP points you made, however if the end user would like to use web based access instead of FTP access then they can go up to the next level of this make of PLC and get the NX, the NX does support web based access and it comes with a demo program to show how this can be accomplished. There has been talk about making the XLE somewhat beefier by having it do a lot of the same features of the NX but I dont know if that is just talk or if they are actually looking into it. I know for a fact that the XLE upgrade for FTP is comming very soon it is in beta testing whether or not that includes web based access is unknown at this time.
As for dealing with conversion so one could compare what has been written on the compact flash with what has been written to say something like an SQL server, our data processing dept has written a little program in FoxPro which does the conversion from CSV and compares the data. As long as both the CSV and the SQL are written with the same types of data I am told this is an easy process. I dont have the skills or knowledge to do such a task or elaborate on it much further than what I have been told. So as for ease, can not guarantee.
Although I have not done it as yet there is said to be some new functions comming in the future that you could monitor a connection and if the connection goes down you can save the current pointer while still logging to the compact flash then when the connection is re-established it will start where the pointer was and catch up. But again this is something I have not done yet so dont know the complexity.
I do appreciate your feed back on this device and I sure you have more knowledge than I do about the finer workings and such. This is why I love this forum so much. It allows everyone to kind of sync up and see what all is available and what may or may not work based on their needs.
[quote=“nathan”]mrtweaver,
Thanks for the recommendation. I should elaborate on my earlier post and shouldn’t have used the term “cheesy”. Those devices are often a perfect fit for a particular problem. Suppose you had to log data 30 days back in case there was a problem, but in most cases nobody looked at the data. Compared to a PC based solution, this device is cheaper and has less potential points of failure. FTP access (or a builtin web server) provides simple access from anywhere, and the CSV format (hopefully zipped) is easy to read on any computer and manipulate with Excel.
These devices get knarly and loose much of their benefit when integrated into the Enterprise - particularly when you want to deal with data in SQL databases (for IT support, maintenance, backups, distributed visualization, analysis, etc, etc). Any way you cut it, you’ll introduce all the points of failure for the PC based approach plus this device. You’ll need to deal with transferring the file via FTP, which assumes that an FTP server is up AND implies historical data lag time since you’re probably doing an infrequent batch transfer. Writing a script to read the CSV into the SQL database isn’t hard, but something (probably a computer) has to do this periodically. Dealing with multiple logging data sources and missing/overlapping data is a big pain to deal with. It’s not that integrating these devices into your process can’t be done - it’s that they add too many moving parts. You can do better, simpler. They’re very cool and work well for what they were designed.
I interpret Al’s request as a device that basically does what FactorySQL historical groups do. The technical difference is pretty subtle, but it would play nice with an enterprise system. The device would log data remotely to an SQL database and have a local cache. It’s a pretty simple concept that could solve a lot of problems. I’m guessing that vendors don’t do this to avoid stepping on their “Enterprise Software” space. Also, given these capabilities, users will feature request this thing to death. They’ll need to support different SQL database types/schemas, want to log at variable rates or based on events (triggers), want to scale/format data, transfer data in batches, compress the data, support some form of redundancy, etc, etc. This leads to a computer and FactorySQL, RSSQL, inSQL, or whatever.[/quote]