Looking to bring 24V inputs to PC to store in database

Question

I've been given a project that sort of bridges the electrical/PLC and PC/software world.

I have to take a 24VDC photoeye and 24VDC encoder (1/4" to 1/2" pulse @ 540FPM ~ 1 pulse every 2.3ms-4.6ms) input and store their derived measurements in a database.

Essentially I am measuring how many pulses the photoeye is blocked to get box length, and how long it is unblocked to get gaps between. Storing both the gap in front, the length of the box and the current time in a table/database and repeating.

Program wise I know a PLC is the best solution, but storage wise, I need this to be stored preferably in a database (CSV, MySQL) so that it can easily be exported to excel and analyzed for throughput and the like.

Thus I was looking at using a compact X86 based PC communicating with some type of 24VDC IO Arduino microprocessor to receive and process the IO, and then send to the PC and the PC will take care of storing the data, calculating gaps and length and handling HMI. The Arduino would likely also take input from the PC to control outputs.

Is this the best solution? Are there lower cost PLC's that can do this type of data storage while keeping the data easy to extract? Will an Arduino be capable of accurately picking up 2-4ms signals?

Thanks for the help guys!

Answer 1

For an industrial application I would steer away from the Arduino or any hobby board solution. It won't be industrially hardened, you'll have to sort out 24V to 5V interfaces, power supplies, mounting, etc., and worst of all, you'll be the only one able to maintain it.

Standard industrial approach would be:

• Use a small brick PLC with Ethernet comms capability.
• Have the program measure the box length and save the value to a memory location. At the same time increment a counter in another location to indicate that a reading has been taken.
• Use an OPC (Open Platform Communications) server to connect from your computer to the PLC. You configure the OPC device connection and "tags" (memory locations) that you wish to monitor and the OPC makes the tag data available to your operating system for reading by OPC clients.
• Add an OPC data logger with a connection to an SQL database and you can begin logging. Trigger the logging the length "on change" of the counter.

Figure 1. Source: Inductive Automation.

OPC servers are similar to printer drivers in that they make the hardware available to all applications on the host computer.

Most of the major manufacturers including Siemens, Allen-Bradley, Mitsubishi, Automation Direct, etc., make low cost brick PLCs often with built-in LCDs and cursor, Enter and ESC keys.

There are many OPC vendors. The OPC servers may be available from the PLC manufacturer or third-party vendors. Have a look at Inductive Automation's Ignition SCADA package. It has extremely powerful OPC server, data historian, unlimited Java based clients, unlimited tags, browser based admin, and an excellent comprehensive series of short instructional videos at Inductive University. There is a "light" version of their product which may suit you. You can download full or light version for trial with two-hour runtime.

For the database you can use MySQL or MS SQL Express both of which are free.

Think about where this development is likely to lead in the coming years and pick a scaleable solution.

Answer 2

As I was reading your problem statement, the solution that formed in my head was exactly what you outlined. I should note that I am probably biased, because I do not have PLC expertise. This is a pretty straightforward Arduino/serial problem. The Arduino can certainly handle that short of a pulse - they run at 16+ MHz and have digital IO operations in the range of 10,000-100,000/second in my experience. You could write a simple Python (or many alternatives) script to watch the USB port for the Arduino and then update a database (PostgreSQL, mySQL, etc) with the results that it gets. Note: you would want to do the simple computations on the Arduino, because the limit on the serial connection is going to be the bottleneck for communication (i.e., you don't want to mirror the digital signal straight through the Arduino - you want to count the pulses then send the result).