Log PLC variables to a database from CoDeSys

Can CoDeSys write variable values straight into a database?

No, the CoDeSys runtime cannot write a database row itself: it executes the program and serves variable values to a data interface, and a separate client on a PC reads those values and writes the rows. Every working setup you will ever see puts that client in the middle, and the client is the piece you configure.

Three paths cover the job:

A custom program, written in a language such as Visual Basic, is the honest answer when acquisition and insert logic must be built together: one codebase reads the runtime and writes the records. For everything else, an OPC client or a DDE-capable application already does both jobs.

Draw the path on one page before you touch the program: runtime, interface, client, database file, and the machine each piece runs on. When a logging project stalls, that drawing usually names the component somebody assumed somebody else was supplying.

Which link should carry the data, OPC or DDE?

Use OPC for anything that changes faster than about once per second or that will grow past a handful of tags; use DDE only for a few slow values where a DDE-capable application already sits on the desk. OPC earns the default spot because the client can browse the tag list, subscribe so the server pushes changes, and carry a timestamp and a quality flag with every value. DDE is one conversation per value: workable on a desk, thin on a plant floor.

Where user management is active on the controller, the OPC UA server asks the client for a user name and password before the session opens, so create that account before commissioning day.

Recommendation: put an OPC UA client between the runtime and the database whenever a tag changes faster than about once per second or the tag list will grow; keep DDE for a few slow values feeding one application on one desk PC, and write a custom program only when no client offers the logic you need.

What do you need before you start?

Four things: a running runtime with its data interface enabled, a client PC on the same network with the client software installed, a database file with a table ready for rows, and one PLC variable whose value you can watch change. Get all four on the bench before any protocol work.

• On the controller: the program running, the OPC server enabled in the runtime configuration (or the DDE interface enabled), and the target variable published.
• On the PC: the client installed, and the LAN path to the controller checked with your site's normal tools.
• In the database: a table on a drive the client can write, with fields for the value, the time, and the tag name.
• On paper: the sample rule, periodic or on change, and the login the client will use. Give that login read-only access to the variables; a logger has no business writing to a running process.

Choose the first variable deliberately: a counter or a clock you can force to move, so a frozen read shows itself in seconds.

How do you commission the first record?

Expose one changing variable, read it in the client, map it to one field, force one write, and inspect the row. One variable keeps interface errors and mapping errors from hiding behind each other, so the first record takes minutes, not days.

1. Enable the OPC server (or the DDE interface) in the runtime configuration and load that configuration so the interface is live.
2. In the client, connect to the server and browse to the variable. Watch the client's live value move while you force the PLC value.
3. Create the table if it is not there yet: value, timestamp, tag name. Keep the timestamp mandatory and everything else simple.
4. Map the one variable to the value field and let the client fill the timestamp and the tag name.
5. Trigger one write with whatever the client offers: a manual write command, a one-shot sample, or a forced change.
6. Open the table and read the row against the client's displayed value at that same moment.
7. Break the link on purpose and confirm the client reports a read fault; the table must gain no rows while the link is down.

Reads fine, inserts nothing: the fault is in the database connection, the file permissions, the field mapping, or the insert path. Inserts fine, value wrong or frozen: the fault is upstream, so check the variable selection, the subscription, and whether the interface is enabled but delivering nothing.

What does a worked example look like on one pump station?

A pump station logs a seconds-of-runtime counter into the database every 5 seconds; three shifts a day produce 17,280 rows, and the arithmetic below is the whole sizing job. Run it once with your own sample period and the storage question is answered before the first row exists.

• Sample period: 5 s.
• Production day: 3 shifts x 8 h = 24 h = 86,400 s.
• Rows per day: 86,400 / 5 = 17,280.
• Rows per 30-day month: 17,280 x 30 = 518,400.
• Size: four short fields, about 60 bytes of data a row. 518,400 x 60 B is about 31 MB of raw data. With file overhead and one index on the timestamp, budget 100 MB a month and the table stays manageable for years.

That table doubles as content for a shop-floor status screen: export the last shift as a table image, load it on the offline display from its card, and the board updates as often as the export runs. The factory data table signage layout rules cover the image, a rolling 24 hour runtime display shows the same counter as it accumulates, and whether that board needs live values or a daily export is its own call: live factory data display walks it. Size the text before you build anything: 30 ft of viewing distance per inch of capital height is the FHWA planning figure, and 20 ft per inch is the safer pick where people glance. The screen size and viewing distance guide turns that into a panel size.

How fast can you log before the path breaks?

One sample per tag per second is comfortable for a client and a database file on one PC, and OPC UA on a healthy LAN holds a 100 ms publishing interval, 10 samples a second, before the insert becomes the bottleneck. A single-row insert into a local database file costs a few milliseconds, so a 10-row-per-second stream swamps a one-row-at-a-time writer. Batch tens of rows into one write and the same writer keeps up. Log on change with a deadband when values sit still for hours; a quiet signal then writes almost nothing.

How do you check the whole path works?

Follow one value through every hop while it changes: the variable in the program, the live read in the client, the inserted row, and the row still present after the database closes and reopens; then run a 15-minute soak. End commissioning only after all five checks pass.

• Live read: force a change at the controller and see it in the client within one sample period.
• Row integrity: the stored value equals the client's displayed value at that sample, and the timestamp advances by the sample period.
• Fault behavior: with the link down, the client raises a read fault, the table gains no rows, and rows resume with honest timestamps when the link returns.
• Persistence: close and reopen the database; the soak's rows are still there.
• Soak: 15 minutes at the intended rate. At a 10 s sample, expect 900 / 10 = 90 rows. Count them.

The decision, case by case: fast tags or a growing list, an OPC UA client plus the database; a few slow values on one desk, DDE; bespoke acquisition logic, a custom program. Commission one variable end to end before the list grows.

Questions