PLC Data Logger

Hi folks!

For those of you who don't know me, I am Ron Gage, the Author of the ABEL and CELL software packages - software for communicating with Allen Bradley PLC's from Linux based PC's.

I have a simple question for everyone here: would YOU see any value in a FREE and open source SQL based data logger for Allen Bradley PLC's with NO limitations?

I currently have one started (and working) but it doesn't have a front end - yet. Before I invest the time in creating the front end, I want to make sure that it would be useful to you folks.

Let me know!

Thanks!

I have actually given this a bit of thought, since I use a few open source programs and I was curious to know what makes one successful and what causes failure. Generally, if the software fills an empty market niche, it will be successful, if it doesn't, it will fail.

Successes:
Linux, - fills the niche of high powered OS, low cost and capable of being tailored to specialised needs and ported onto any computer. Not so good for normal, dumb, users, since we need something that is simpler to use.
Open Office, - its free, so the common user on a budget doesn't need to fork out $1,000 or so for MS office. It can also be used on operating systems that MS doesn't support. People still rather pay big bucks for MS office when they have the money.
Mozilla and variants, - fills a security hole that MS doesn't seem able to.

Failures:
Any open source soft PLC. This also includes any proprietry soft PLC systems. PLCs come in so many shapes, sizes and price tags, that ever niche has been filled. You cannot even give away a soft PLC system for free, no one is interested.

So, the question you should ask, is who else makes a system similar to yours, what does it cost, what are its limitations and who uses it?

For something like this, the possible markets would be businesses, schools and hobbyists.
For businesses, you may find that the cost of setting up your system compared to your competators system makes the total costs not much different. This may restrict the number of people who would use it.
Schools, these would always like to have something they can give each student, so you may get a lot of tech collages wanting to use your system. From there, you may break into the business world as these students port their system from the class to their place of emplyment.
Hobbyists, I think is quite limited, but will pick up your system if it is available.

Overall, I think it would be an interesting thing to do, but I cannot predict how successful it will be. Perhapse you could slap together a quick and dirty alpha version for the AB users on this forum to play with, then you could get some real feedback.

Doug

Datalogger on Linux

I think it could be very interesting for persons who wants to have servers running Linux.

We have done our own datalogger,two years ago it was running on an NT4 server with an OPC connection to RSlinx and an Oracle database.We have had a LOT of problems with this (memory leak...),sometimes the server was restarting alone.Every weeks we need to restart it.

So we decide to leave the dark side and i start working on library (based on C) to acces AB Plcs (We have SLC500,PLC5 and Controllogix on ethernet,controlnet and DH+).Since more than one year our datalogger run perfectly on a Linux Debian server with a MySql database,and without any kind of problem.(We log ~200 tags/min)

Sure it's (maybe) not so easy to configure because we don't have any front end but there's no limitation , it's free and the most important: it's reliable.

We plan to release our work on a GPL licensing.

Stef.

plcsql

Doug:

plcsql is already available in a near-beta version. It works here (against a SoftLogix 5 instance) without failure.

Because there is no front end, whoever is going to play with it will need to be fairly fluent with SQL as all the triggers and the register tables are stored in a MySQL database.

If this doesn't stop anyone from wanting to try, it's available via CVS from me. Go to my website - www.rongage.org - and get the instructions for CVS access.

As for what else does this, the only package I am personally aware of is RSSQL (from Rockwell). This package is intentionally limited (number of registers that can be monitored, I believe), costs plenty of money (what Rockwell Software doesn't), and also requires a MS SQL Server instance (more $$) on top of it all to store the data. I'm sure there must be other packages, just that I don't know what they are.

As for what can PLCSQL do? It basically supports up to 4999 triggers, each trigger causing up to 100 register values to be recorded along with a timestamp for each register. I plan to also have a timed trigger mode - fire this trigger every x seconds instead of whenever you receive msg x.

Front End?

Ron,

http://visual.sourceforge.net/new/index.php

You are probably aware of this effort, but anyway this open source project is about an HMI. It has data storage capability also. If your datalogger can do more, maybe you can have your logger ty in to this HMI>

As for frontend necessity:

Most people that would (initially) be willing to set up a linux box, would also be willing to play around with sql Triggers, especially if there are some simple samples to copy, paste and change from. Don't forget, logged SQL data is only usefull if you can somehow get it back out (which usually requires SQL commmands as well).
As for a Microsoft frontend, maybe you can give some samples of how to set up your logger and retrieve data with a simple Microsoft Access (ODBC linked) project.

I am certainly willing to try out your data-logger, but my time is limitted right now and I would like to try out the HMI project mentioned above first.

I just looked over the 'visual' project you mentioned, paying particular attention to the data logger section. As near as I can tell, they are using either a timed data gather or a polled data method. PLCSQL uses PLC generated trigger messages to retrieve the data. I'll post an explainer in a bit.

PLCSQL explainer

Following up on an earlier post...

PLCSQL, my attempt at a SQL based data logger running under Linux, currently operates in a triggered mode. This basically means that ANY PLC on the network (currently, only Ethernet) can send a simple MSG to the logger, causing the logger to read pre-configured data registers and record the values along with a timestamp.

In detail, PLCSQL sets itself up to look like an Ethernet based PLC5, implementing enough of the DF1 command structure to allow it to be the receiver of typed write MSG commands.

When a msg command is received, the index value of the register is stripped off and interpreted to be the "trigger" index. For example, say you send a typed write msg to PLCSQL for register N7:4 - the 4 (being the index value) is interpreted to mean "trigger #4" in PLCSQL; the "N7" segment is ignored. Once received, PLCSQL then does a couple of database lookups to see what registers from what PLC's it has to retrieve and then retrieves the contents of those defined registers. The register data is then stored in the database along with the id of the PLC that provided the data, the actual register itself, and a timestamp. Once the contents of the trigger is processed, then a "no error" response is sent back to the triggering PLC, setting the DN bit on the original msg and confirming that the data has been recorded.

I use a typed-write msg to keep things simple - it only expects a result code back as opposed to actual data. The actual data transmitted by the trigger generating PLC is actually irrelevent and ignored - the only important part is that index value. Thus, a "trigger" to "N7:4" and "F6:4" cause the same data to be collected - the index value is identical (4).

PLCSQL is also capable of receiving signals from ANY plc on the network. I use programmatic forks to handle the actual processing of the received data, much like Apache 1.3. This allows me to handle several connections at once.

The back end is a standard MySQL instance, ODBC drivers for MySQL are freely available for people in the Windows World as well as multiple other computer platforms (HP/UX, Solaris, etc). This allows the end-user to send the data into an Excel spreadsheet, into an Access front end, or whatever their heart desires.

Of course, the front-end I am going to work on will deal with things like system initialization, configuration of the triggers, and will also allow for recorded data display and/or extraction. I'm still not sure if I am going to do the front-end GUI or CLI, but the whole thing WILL be very user friendly and simple to operate once finished. The front-end will be Linux based.

Finally, PLCSQL will initially be based on the ABEL library I wrote many moons ago. I plan to eventually also support the CELL library, allowing PLCSQL to also work with ControlLogix PLCs.

Any questions?

Giving this some thought:

A competing product that matches your description (sort of) may be Citect Plant2Business. This takes plant data and stores it in a database, often SQL, but others are accomodated too. It is also very easy to setup and use.
Differences are that it takes its data from a Scada package rather than directly from the PLC (Citect, Wonderware and WinCC). It also costs a fair bit, but not as much as some similar packages. If you can get hold of a copy, which you may be able to download from the web site, you could use it for ideas. They also tend to give away CDs at trade shows.

As for a front end, Open office keeps claiming they do a good front end for MySQL. you could check this out, maybe some of your work is already done.

www.openoffice.org

Doug

[As for what else does this, the only package I am personally aware of is RSSQL (from Rockwell)]

Ron,

Check out I/Gear. It has a much broader set of features than RSSQL that you may find interesting. You may get some ideas on the configuration interface side. It is much easier to setup & has a very clean interface for data transfer. Look at the information on the DTU (Data Transfer Utility). You can download a fully functional demo to look & try.

www.igearonline.com

Re: plcsql

rongage said:

Doug:
As for what else does this, the only package I am personally aware of is RSSQL (from Rockwell). This package is intentionally limited (number of registers that can be monitored, I believe), costs plenty of money (what Rockwell Software doesn't), and also requires a MS SQL Server instance (more $$) on top of it all to store the data.

Click to expand...

RSSql to my knowledge does not require MSSQL. It can log data to any database using OLEDB or ODBC.

concerning VISUAL (It's my project)
VISUAL polls the PLC(s), normally as fast as possible. If you want less traffic, you can insert a delay statement into the PLC drivers instruction list.
You can also make certain instructions or the delay conditional.
There is currently no way to handle PLC generated messages.
Data logging itself is triggered by the change of some variable.
If this variable is read from the PLC, data storage takes place on every change. But the trigger condition can also be a timer, resulting in storing the same value multiple times if it hasn't changed.
There is a way to emulate a behaviour similar to PLC/data driven recording: Make the driver allways poll a "status word" from the PLC. Let a certain value of that staus word be the condition to execute additional poll operations. Finally, let that same condition execute an instruction that clears the status.
Naturally, this works only for data that changes slow enough to execute multiple polls of the PLC and recalculations of VISUALs internal state in the meantime.
Another way not yet realized would be to store quickly changeing data in some buffer in the PLC. A specially modified PLC driver could read this block and trigger the storage procedure per dataset.
VISUAL's structure is modular. Drivers for PLCs and for databases are loaded via dlopen mechanism at program start according to a configuration file.
Currently, database drivers are available for MySQL, text files and binary files.
If someone is interested in the further development, please let me know.