BRX can collect the pass/fail results, but a PC should format and print the final 8.5 × 11-inch report. The fastest workable path is to write one CSV record through DMLogger, let the PC detect the completed file, and have a PC application render and print it. Direct PLC printing is practical only when the printer accepts raw serial text.
Rule out the quick fixes first
Do not start by treating an office printer like a label printer. A Zebra-style workflow works when the printer accepts a documented command language and the PLC can transmit that language. A normal sheet-fed printer usually relies on an operating-system driver, print spooler, page layout, and font rendering. Sending plain bytes to its USB or network connection does not reproduce that stack.
A direct serial connection is the exception. If the selected printer accepts raw text over a serial interface, BRX instructions such as STRPRINT and STREAMOUT can assemble and transmit a report. Before committing to that design, obtain the printer interface manual and prove that a terminal program can print a complete page using the same port settings and control characters. Stop pursuing direct printing if the printer requires a proprietary driver or cannot accept raw serial data.
Check before moving on: classify the printer path as either raw serial text or PC-managed printing. Do not buy hardware until one full sample page has printed through the selected path.
Define one complete test record
Freeze the report data structure before programming communications. A machine running about 300 tests needs more than a loose stream of pass/fail bits. Give every report enough information to associate the paper with the tested device and distinguish a completed cycle from an interrupted one.
| Field group | Required content | Reason |
|---|---|---|
| Identity | Unit or serial identifier and report identifier | Prevents a result from being attached to the wrong device. |
| Cycle state | Started, complete, aborted, and overall pass/fail | Stops partial tests from becoming final reports. |
| Test rows | Stable test number, test name, result, measured value, and limits where applicable | Makes the report traceable and readable. |
| Exceptions | Skipped, not run, invalid, or communication failure | Separates missing data from a genuine pass. |
| Record control | Sequence value or unique file name | Lets the PC detect duplicates and missed records. |
Choose a documented CSV column order and keep it stable. Quote text fields that may contain commas or quotation marks, and choose one representation for each result state. Record the overall result only after all required tests have reached a terminal state.
Check before moving on: export one manually prepared record and confirm that every report field can be generated without reading live values after the cycle has ended.
Freeze the BRX results before export
Do not let the logger read working registers while the next unit can change them. At test completion, copy the identity, overall status, and all required results into a report snapshot. Set a snapshot-ready flag only after that copy finishes. The export side reads the snapshot, not the active test data.
Use a simple handshake between the sequence and the logger:
- Run the required tests and retain each result.
- Stop the sequence from accepting another unit while the final snapshot is being assembled.
- Copy the finished values into the report area.
- Assign the record sequence value and mark the snapshot ready.
- Request the export.
- Wait for a success or failure response from the logging path.
- Clear the request only after success; retain failed data for retry or operator recovery.
A print request is not proof that a file exists, and a file is not proof that paper came out. Keep separate states for report ready, export accepted, file processed, and print completed wherever the PC software can return those acknowledgements.
Check before moving on: hold the PLC at the completed-cycle state, change a working test value, and verify that the frozen report value does not change.
Select the transfer and printing path
Use the simplest route that meets the traceability requirement. The installation described here selected DMLogger to place a .csv file in a computer folder. That keeps page formatting and printer control on the PC, where ordinary printer drivers are available.
| Path | Use it when | Main limitation |
|---|---|---|
| DMLogger to CSV | A Windows PC can receive data, monitor a folder, and print reports. | The PLC-to-PC transfer and the PC print job need separate status handling. |
STRPRINT plus STREAMOUT
|
The printer accepts raw serial text and the report needs simple fixed formatting. | Page layout is limited by the printer command set. |
| Custom PC application or AdvancedHMI | The report needs forms, validation, operator controls, or acknowledgement back to BRX. | The application becomes maintained production software. |
Server through JSON, MQTT, or HTTPCMD
|
A server already owns report storage, rendering, or centralized printing. | Server availability and message acknowledgement become part of machine operation. |
| SCADA reporting | The site already maintains a SCADA platform with reporting capability. | Licensing, tag count, and deployment effort can exceed a single-machine need. |
For a shelf-stock recovery, use CSV and the existing PC. For the permanent design, decide whether losing the PC or printer must stop production, permit queued reports, or require a controlled manual reprint.
Check before moving on: transfer the same snapshot twice and confirm that the receiving side can identify the duplicate instead of printing two indistinguishable reports.
Commission the CSV-to-print workflow
Make file completion explicit. A folder watcher can open a file while it is still being written, producing a partial report. Configure the PC-side workflow to process only a completed file or completed record. One common application pattern is to write under a temporary name, close the file, and then rename it to the watched extension; apply that pattern in the PC application if its tools support it.
- Configure DMLogger with the required BRX data and a destination folder accessible to its service or user account.
- Create one file-naming rule that cannot overwrite an earlier unit unintentionally.
- Generate the CSV only from the frozen snapshot.
- Have the PC validate the expected identity, completion state, and required test rows before printing.
- Render the report through the installed printer driver, including page breaks for the roughly 300 results.
- Archive or move the processed CSV so a folder watcher cannot print it again.
- Return a processed or failed indication to the control system when the chosen PC software supports feedback.
Test commas, quotation marks, blank measurements, failed tests, skipped tests, and a report long enough to cross multiple pages. Set the document template for 8.5 × 11-inch paper on the PC; do not bury paper size assumptions in PLC strings.
Check before moving on: compare the printed first, middle, and last test rows with the frozen BRX values and confirm that the report identity appears on every page where separation could cause a mix-up.
Prove the complete production sequence
Run the workflow as a machine function, including failure recovery:
- Complete a passing unit and confirm one CSV, one report, and the correct overall result.
- Complete a failing unit and confirm that the failed test is visible and the overall result is fail.
- Interrupt a cycle and verify that no final report is presented as complete.
- Disconnect the printer, complete a test, and verify that the record remains recoverable for printing.
- Restart the PC-side process and confirm that completed records are not duplicated or lost.
- Reprint an archived record and mark it as a reprint if document control requires that distinction.
The production release criterion is reconciliation: the BRX completion count, accepted CSV count, printed-report count, and retained failure queue must agree after normal runs and induced faults. A green PLC bit by itself proves only the state represented by that bit.
Final check: hand the workflow to an operator with the printer offline, restore the printer, and confirm that the operator can recover the exact pending report without rerunning the device tests.
FAQ
Can I print an 8.5 × 11 report directly from a BRX PLC?
Yes, if the printer accepts raw serial text or a command language that BRX can send with STRPRINT and STREAMOUT. Use a PC-managed path when the printer depends on an operating-system driver.
Can I use DMLogger to create the final test report?
Use DMLogger to place the test data in a .csv file on the computer. A PC application must still validate, format, submit, and track the print job.
Does creating the CSV prove that the report printed?
No. Track export accepted, file processed, and print completed as separate states, and retain the CSV when printing fails.
Can I send BRX report data to a server instead?
BRX supports JSON formatting and can use MQTT or HTTPCMD for a server-based workflow. Define message acknowledgement, duplicate handling, and outage recovery before relying on that route.
Does a failed print require AutomationDirect support?
Stop and contact official AutomationDirect support when BRX communications or the logging instruction fails after the port, destination, handshake, and diagnostic status have been checked. Contact the printer or PC-software supplier when BRX produced the complete record but the driver, spooler, renderer, or printer rejected it; do not change the test sequence to mask a downstream printing fault.