Configuring Do-more PLC Data Logging on a Tidal Turbine

The turbine's control is on/off and already runs on separate boards over CAN-bus. The PLC's real job is condition monitoring: 42 hardwired channels (12 RTD, 12 digital, 18 analog in a mix of 0-10 V and 4-20 mA) sampled at 1 Hz or faster, logged locally for at least 12 hours, and retrievable from shore on request. The accelerometers go to external vibration loggers. Two architectures cover this without a shore-side cRIO:

• A Do-more BRX writing to its SD card.
• A Do-more for control alongside a Red Lion data acquisition and logging system.

This walkthrough builds that system one layer at a time. Each layer ends with a check to pass before you start the next.

Skip the Quick Fixes That Fail Offshore

These are the usual first moves. Each one breaks down on a remote, unattended machine:

Quick fix	Why it fails here	What to do instead
Keep routing every signal to the shore cabinet	You get long analog runs through the export cable, and one cable fault blinds all monitoring. It also keeps the dependency on the shore-side cRIO that you are trying to drop.	Co-locate acquisition and logging on the device. Send only files or streams to shore.
Put a PC in the enclosure	It works, but it adds an OS, a disk, updates and thermal limits to a box nobody can reach quickly.	Use a PLC-class logger with removable flash media.
Log into PLC data registers	Twelve hours of 42 channels is far more than register memory is meant to hold, and nothing is written to a file you can pull.	Write timestamped records to SD or a dedicated logger's storage.
Wire the accelerometers into the PLC analog cards	At 1 Hz you capture nothing useful about vibration. Vibration analysis needs sample rates far above the process-variable rate.	Keep the accelerometers on external vibration loggers.

Check before moving on: write down which device owns each function (control, slow DAQ, vibration, retrieval). If any function has two owners or none, fix the plan now.

Count the Channels and Size the Log File

Start the budget from the actual I/O list, not from "30+ sensors":

Signal type	Count	Hardware implication
RTD	12	Needs RTD input modules or head-mount RTD-to-4-20 mA transmitters
Digital input	12	Standard DC input module
Analog input, 0-10 V and 4-20 mA mixed	18	Per-channel configurable inputs, or separate voltage and current cards
CAN-bus	1 port	Link to the control boards. Confirm the chosen controller or logger supports it natively or through a gateway.
Accelerometers	External	Handled by the vibration loggers, not the PLC
Total logged channels	42

Record count at 1 Hz for 12 hours:

File size depends on the format. Both cases below are labeled assumptions, not vendor figures:

• Assumption A, CSV text: about 10 characters per value including the delimiter, plus about 25 characters for the timestamp. That gives about 445 bytes per row and about 19 MB per 12 hours.
• Assumption B, binary: 42 x 4-byte REAL plus an 8-byte timestamp gives 176 bytes per record and about 7.6 MB per 12 hours.

Either figure is small for any SD card. The real constraints are:

• How many rows fit in one file before the logger rotates.
• How long a file takes to transfer over the link to shore.
• How many 12-hour periods you want to keep before the oldest is overwritten.

Check: read the logger's maximum file size, rotation options and supported media capacity from its manual. Confirm that at least two full 12-hour periods fit, so one outage does not destroy the only copy.

Pick the Logging Architecture

Three workable layouts match this I/O list. The two Do-more options are the ones that fit this application.

Architecture	Logging	Retrieval	Constraint to verify
Do-more BRX, single controller	SD card with a flexible logging facility	Log files emailed, or sent over TCP with a custom protocol	When this design was scoped, BRX had no analog expansion modules. Check the current catalog for enough analog and RTD capacity for 12 RTD and 18 AI channels before committing.
Do-more for control, plus a Red Lion acquisition and data logger	Handled by the Red Lion unit	Use the file-access methods listed in the Red Lion unit's documentation	Two devices to configure. Keep the time base consistent between them.
Productivity Series PLC	Verify the logging feature set in the current manual	Verify the file-transfer options	Same channel-count and CAN questions as above

Choose the split architecture when the single controller cannot carry all 42 channels on local or expansion I/O, or when you want logging to survive a controller reload. The Do-more handles the on/off logic and the CAN link to the control boards. The logger handles the 42-channel record.

Check: for the chosen hardware, list every channel against a physical terminal. If any RTD or analog channel has no terminal, stop and resize before wiring.

Wire and Scale the RTD and Analog Inputs

Mixed 0-10 V and 4-20 mA signals are where commissioning goes wrong most often. A current signal on an input set for voltage (or the reverse) reads a plausible but wrong value, not an obvious fault.

1. Set each analog channel's range in hardware (DIP switch or jumper, where fitted) and in software to match the transmitter's output type.
2. Scale 4-20 mA channels with EU = (mA - 4) / 16 x (EU_max - EU_min) + EU_min.
3. Scale 0-10 V channels with EU = V / 10 x (EU_max - EU_min) + EU_min.
4. Flag any 4-20 mA reading well below 4 mA as a broken wire or failed transmitter. Log it as a fault state, not as a low process value. A 0-10 V channel gives you no such live-zero diagnostic, so a dead sensor reads as 0.
5. Set the RTD type (element and wiring: 2-, 3- or 4-wire) to match the installed probes. Use 3- or 4-wire where lead length is significant, so that lead resistance does not show up as temperature offset.
6. Land cable shields at one end only, at the enclosure. This matters in a machine with a generator and power electronics nearby.

Check: inject 4, 12 and 20 mA and 0, 5 and 10 V on the bench into each analog channel and confirm the scaled readings. Open one 4-20 mA loop and confirm that the fault flag appears. Put an RTD simulator or a known-temperature bath on at least one RTD per module.

Trigger Records from the Clock, Not the Scan

A record must represent one instant with a known time.

// Pseudo-logic; map to the logger's actual instructions or config
ON rising edge of 1-second clock pulse:
    snapshot all 42 scaled channel values into a record buffer
    stamp buffer with RTC date/time
    append buffer as one row to current log file
    IF row count of current file >= rows_per_file:
        close file, open next file (date/time in file name)

• Set rows_per_file to 3,600 for hourly files. Hourly files transfer faster and limit the loss if one file is corrupted.
• Name files by date and hour, so a shore-side request can ask for a specific window.
• Sync the controller or logger RTC from a reliable source. In the split architecture, sync both devices, or event correlation between the CAN control log and the sensor log falls apart.

Check: run for one hour and open the file. It should contain 3,600 rows, give or take one, with no duplicate or missing seconds. A gap shows the trigger is tied to the scan or is being missed during file operations.

Connect the CAN-Bus Control Link and Isolate It from Logging

The turbine's control logic lives on the CAN-connected boards. Keep it that way. The logger must never be able to stall the machine.

1. Confirm the CAN interface on the chosen controller, or a CAN gateway, supports the boards' bit rate and message format. Read the board documentation for bit rate, identifiers and data layout.
2. Map the on/off command and status bits to named tags. Log the status bits alongside the 42 sensor channels, so each record shows the machine state.
3. Keep file writes out of the path that handles CAN control messages. A full SD card or a failed file transfer must leave control running.
4. Terminate the CAN bus at both physical ends only.

Check: pull the SD card, or disconnect the logger, while the turbine is commanded on in a test state. Control and CAN status must continue unchanged, and a logging-fault alarm should be raised.

Pull Files and Streams Back to Shore

On a BRX, the logging facility supports two retrieval routes:

• Email: send closed log files automatically, for example each completed hourly file, or on a request bit set from shore.
• TCP with a custom protocol: a shore-side client asks for a named file or a live stream of the current values. You write both ends, so define the request format, the file-name convention and an end-of-file marker before coding.

On a Red Lion logger, use the retrieval options in its manual and keep the same hourly naming, so shore-side tools work with either architecture.

Temporary restore vs permanent repair: if the link to shore drops, the local card keeps logging. That is the temporary restore, and it only holds as long as retention on the card lasts. The permanent repair is a retrieval job that tracks which files have been confirmed received and backfills the missing ones after an outage.

Check: request a specific hourly file from shore and compare its row count and first and last timestamps against the copy on the card. Then request a live stream and confirm that the values match the local display within one sample.

Run the 12-Hour Soak Before Deployment

1. Power the full enclosure with all 42 channels connected, simulated where the real sensors are not available.
2. Run for at least 12 hours at 1 Hz, with the turbine control cycling on and off over CAN.
3. During the run, drop the shore link for at least one full file period, then restore it.
4. Cycle power once mid-run and confirm logging resumes into a new file with correct time.
5. At the end, confirm 43,200 rows in total across the files, gaps only where power was intentionally removed, and every file retrieved to shore.
6. Spot-check the scaled values against the bench injection points recorded earlier.

If rows are missing, go back to the clock-trigger check. If values are wrong, go back to the input range settings. If files never reach shore, go back to the retrieval check.

FAQ