https://community.element14.com/challenges-projects/design-challenges/on-the-line/A design challenge centred on adding intelligence to production lines, with projects that monitor processes, test products, and improve uptime through automation and data-driven control. Participants build and share practical industrial solutions, showingen-USTelligent Community 12https://community.element14.com/challenges-projects/design-challenges/on-the-line/f/forum/57105/opendfm-a-utility-for-getting-the-logs/236411Fri, 17 Jul 2026 17:31:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:14173f7f-7715-4b43-ac62-872c8c410fdfcolporteur"Our need will be our creator" Plato It looks like you dug the burr out of the saddle blanket on this one. Hopefully the ride is smooth from here on out. I can recall a few "Augh fk-it moments" and just committed to fixing it.https://community.element14.com/challenges-projects/design-challenges/on-the-line/f/forum/57105/opendfm-a-utility-for-getting-the-logsThu, 16 Jul 2026 03:50:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:a532ec93-accb-4bea-82dd-678a5634e5c4SensoredHacker0Whose going to carry the boats?? Who is going to carry the logs? I work with IDEC PLCs. They have some software which was probably really nice in 1982. yesterday, I was so infuriated when a log download process kept failing, I went off and made my own utility to get logs. The general gist is that when the OEM supported software looses connection, you loose the entire set of data you had been downloading. many of our systems are thousands of miles away, on questionably reliable networks. While you might see 20Kpbs down, locally, remote connections even for small files can take hours at 2-4KBps. then to loose it. .. OMG. or the syntax is convoluted AF, or theres no direct way to automate the process via the OEM supported software. Well last night, I had enough, and delved into the internal operation of remote SD Card reading, via Maintenance Protocol. How OpenDFM Works OpenDFM is a multithreaded graphical client for accessing the SD-card filesystem exposed by IDEC PLCs through the maintenance protocol over TCP. Each PLC is represented by an independent tab and session object. A session stores the controller’s IP address, TCP port, PLC device identifier, current remote working directory, local destination path, cached directory-entry metadata, active transfer state, and synchronization primitives used to prevent overlapping protocol transactions. Ethernet maintenance communication normally uses TCP port 2101. At the transport layer, OpenDFM creates a TCP socket to the PLC and exchanges IDEC maintenance-protocol frames. A conventional request contains: ENQ control byte 0x05 two-byte device identifier, commonly FF continuation flag command and subcommand command-specific payload XOR-based block-check character carriage-return terminator 0x0D The PLC normally responds with an ACK frame beginning with 0x06 , followed by the responding device number, completion status, returned data, BCC, and terminator. Negative protocol responses are decoded separately from TCP errors, socket timeouts, truncated frames, and malformed payloads. SD-card access uses the PLC’s extended FR filesystem command family. Directory enumeration is stateful. OpenDFM first submits a remote path, such as: /FCDATA01/DATALOG/1-secLog The path-open request includes the path length and a NUL-terminated path name. The PLC returns the number of directory entries available in the opened directory context. OpenDFM then issues successive entry-read requests, using the observed FR20 sequence, until every directory record has been retrieved. The final request uses the terminating form of the command so the PLC can release the active enumeration context. Each returned directory record is parsed into structured metadata. Depending on the record format, this includes: file-versus-directory type filename length filename bytes file size FAT-style modification date FAT-style modification time additional flags or reserved fields The date and time fields are decoded from their packed filesystem representation. File sizes are converted from the protocol’s hexadecimal ASCII representation into native integers. Filenames are decoded without treating path separators as local filesystem separators until the remote entry has been validated. The GUI does not directly display raw protocol responses. Parsed entries are converted into application-level directory-entry objects and inserted into a tree or list model. Directory entries can therefore be sorted, selected, recursively traversed, and associated with transfer actions without repeatedly reparsing the original response bytes. File retrieval is also stateful and block-oriented. OpenDFM opens the selected remote file, determines or receives its expected length, and repeatedly requests the next block. Returned blocks contain protocol framing plus a binary or encoded data payload. The application removes framing, validates the response, extracts the payload, and appends it to a local output stream. The local file is normally written incrementally rather than buffering the complete remote file in memory. This allows large logs to be downloaded with a bounded memory footprint. The transfer loop tracks: expected remote file length bytes requested bytes received bytes committed to disk current remote offset retry state elapsed transfer time effective transfer rate A transfer is considered complete only when the protocol reports end-of-file or the accumulated byte count matches the size reported during directory enumeration. A short response, zero-length block before the expected end, invalid BCC, unexpected command status, or socket disconnect is treated as a transfer failure rather than silently producing a truncated file. Folder downloads are implemented as client-side recursive traversal. The PLC provides only the contents of one opened directory at a time. OpenDFM therefore performs a depth-first or breadth-first walk: Enumerate the selected remote directory. Create the matching local directory. Download each regular file. Queue or recursively enter each sub-directory. Repeat until no unvisited directories remain. The remote path is normalized independently from the local path. This prevents a PLC filename containing parent-directory components, absolute-path syntax, or unexpected separators from escaping the selected local download directory. Because the PLC’s filesystem commands maintain implicit remote state, command ordering is significant. A directory-open operation establishes the context used by subsequent directory-entry reads. Likewise, a file-open command establishes the context used by following block-read commands. If two operations against the same PLC were interleaved, one command sequence could replace the context required by the other. OpenDFM therefore serializes filesystem transactions per PLC session. A tab may have only one active directory enumeration, file transfer, or recursive operation at a time. This restriction is not primarily due to Ethernet bandwidth; it is required to preserve the PLC’s stateful command sequence. Concurrency is applied between PLC sessions rather than within one PLC session. Each tab has its own socket activity, protocol state, command lock, transfer worker, and progress reporting path. As a result, PLC A may download a log while PLC B enumerates a directory, provided the two operations use separate sessions. Blocking socket and disk operations are executed in worker threads so they do not run inside the GUI event loop. The workers publish status updates through a thread-safe queue or framework signal mechanism. The main interface thread consumes those updates and modifies widgets, progress bars, transfer labels, and tab state. GUI objects are not directly manipulated from network workers. A typical operation therefore crosses several layers: GUI action -> PLC session controller -> filesystem operation -> maintenance-protocol command builder -> TCP transport -> PLC response parser -> directory-entry or file-block decoder -> local filesystem writer -> thread-safe progress update -> GUI model refresh Error handling is divided by layer. Connection failures identify an unreachable PLC. Protocol failures identify a syntactically valid exchange rejected by the controller. Filesystem failures identify invalid paths, unavailable SD cards, changed directory contents, or interrupted remote file state. Local I/O failures identify permission errors, full disks, invalid filenames, or failed writes. OpenDFM can also verify that the SD card is mounted before performing filesystem operations by reading the PLC’s SD-card status devices. On FC6A controllers, special relay M8070 indicates SD-card mount status, while special registers such as D8250 and D8251 expose total and free SD-card capacity. These checks are separate from directory enumeration but provide an early indication that a browsing or download request is likely to succeed. In effect, OpenDFM translates a stateful, request-response filesystem interface into a conventional graphical file browser while preserving the strict transaction ordering, response validation, and per-controller isolation required by the PLCs. https://github.com/FOSSBOSS/OpenDFM Are there bugs? HELL YEAH! Am I going to fix it? hell ye? Did I really write this whole thing in one night? LOL NO. Vid: www.youtube.com/watch Next up: Decoding the SV1 security protocol into practical utilities.datalogplcindustrial automationautomationhttps://community.element14.com/challenges-projects/design-challenges/on-the-line/f/forum/57105/opendfm-a-utility-for-getting-the-logs/236403Thu, 16 Jul 2026 03:45:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:0fd24b30-8c8e-48c2-85cc-af84026b2146kmikemooI can't play with it, but I like the concept and execution.https://community.element14.com/challenges-projects/design-challenges/on-the-line/m/managed-videos/151524Thu, 16 Jul 2026 00:29:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:ba261655-78a0-47ff-9117-14b6c790fc47SensoredHacker0Download logs based on date selections from the YYYYMMDD format. are your logs formatted that way? ### How OpenDFM Works OpenDFM is a desktop application for browsing and downloading files from the SD card installed in an IDEC PLC. The application...https://community.element14.com/challenges-projects/design-challenges/on-the-line/b/news/posts/winners-announcement-on-the-line-design-challengeFri, 26 Jun 2026 16:50:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:29bb7c4c-94b5-4805-9a28-b7d6a5c5e732JoRatcliffeIt is time to announce the winners of the On The Line Design Challenge! Let's quickly remind ourselves of the challenge and its theme, the prizes, and then get straight into it. The Challenge For a chance at winning one of the prizes, Challengers had to use the provided kit to build a smart industry-themed project and blog the build process here on the community, showcasing the features of the kit components in the most innovative, creative ways possible. Prizes Prizes are subject to change but will be of similar price and style. Prize Prize Category First Place Prize First Place wins Multicomp Pro MP720013 MSO, 2+16+1 CH, 100MHZ, 3.5NS, 1GSPS (Approx. Value $1,106) Second Place Prize Second Place wins Multicomp Pro MP750511 WAVEFORM GENERATOR, 2CH, 60MHZ (Approx. Value $712) Third Place Prize Third Place wins Multicomp Pro MP3055 Bench Digital Multimeter, 5.5, RS232, RS485, USB, 10 A, 750 V, 100 Mohm (Approx. Value $573) Finisher Prize For anyone who completes their 5 forum posts and 1 project blog demonstrating their project. Multicomp Pro AC/DC Voltage Clamp Meter (Approx. Value $30) *Don't worry if a prize is out of stock in your region or does not have the right plug for you. We can ship from global stocks, include a plug adaptor, or find a local equivalent of a prize. **Grand Prize and Runner Up winners will also earn the finisher prize. The Winners 1st Place Winner SolarSense In conjunction with their Masters Thesis, arvindsa created a predictive maintenance system which uses sensors to detect when solar panels need cleaning before their output drops by too much. 2nd Place Winner Green Brain saramic designed a smart greenhouse monitoring system built around Arduino Nano nodes, an Arduino UNO Q hub, and a Python Flask dashboard. 3rd Place Winner Industrial Line Sentinel (ILS) skruglewicz created the ILS to act as an intelligent safety system for industrial environments, helping enforce PPE compliance by monitoring for workers not wearing a safety vest, not wearing protective glasses, or workers walking into a dangerous 'red zone'. Finisher Prize In no particular order Smart Ventilation Motor Monitoring System Project on Labview fyaocn designed an intelligent monitoring system for industrial ventilation motors, aiming to help avoid unexpected downtime and optimize maintenance cycles. Misaz’s Experiments with Industrial Sensors misaz conducted a number of experiments with the kit parts, show how to use them, how they work, how to use them for measurements and convert values back to real values, and much more besides. Chiller Temperature Monitoring for Electrochemical Processing pandoramc built a system for helping monitor and maintain the temperature in cooling systems such as those used in electrochemical processes like electropolishing, where high temperatures generated during the process could affect the quality of the final product. AIoT: Smart Active Dry Box & Print Farm Supervisor To solve the problem of degraded filament material quality in 3d print farms increasing print failure rates, Zhar_14 created a system combining an automated filament drying chamber for optimal filament quality and real-time monitoring to autonomously detect print failures using computer vision. Congratulations to our winners and finishers, I hope this makes for a good start to the weekend! These were really creative projects and I strongly recommend checking out every one of them! I will be helping ship prizes for this design challenge so drop me a message if you have any questions at all. Very well done to everyone who took part, commented, and discussed this challenge, and a big thanks also to the challenge's sponsors: Analog Devices, Molex, Emerson | NI, and DwyerOmega.design challengeOn the line design challengee14-on-the-linedchttps://community.element14.com/challenges-projects/design-challenges/on-the-line/b/projects/posts/smart-ventilation-motor-monitoring-system-project-on-labviewWed, 24 Jun 2026 08:44:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:c6f2a5f5-cc38-4f23-b28c-e1b0f546f43efyaocn1 Full System Architecture 1.1 Low-cost distributed IMU motion sensing over industrial CAN bus, edge data forwarding to PC-side LabVIEW visualization & AI monitoring. The schedule is delayed totally since I misuse Arduino CAN library which support MCP2501 over SPI. I have to rebuild sustomized CAN library by GPIO simulation, although the Arduino Uno Q support CAN natively, but the port is not wiring out. The STM32U support high speed CANFD, which is perfect fit for MAX33040 shield. Fully custom CAN receiver stack on Uno Q demonstrate embedded low-level CAN protocol implementation, end-to-end industrial sensing pipeline for manufacturing line monitoring challenge. 1.2 Hardware Signal Flow MKR Board + MKR IMU Shield (LSM6DSOX 6-axis IMU: Accel X/Y/Z, Gyro X/Y/Z) ↓ I2C read by Platform2Go 4200 (edge CAN transmit node) ↓ CAN 2.0B Bus differential signal ↓ MAX33040 CAN Transceiver Shield (Arduino Uno Q) (custom self-written CAN receive library, no third-party CAN libs) ↓ Uno Q USB Serial UART ↓ NI-VISA Serial Read in LabVIEW VI ↓ LabVIEW: Data parse, real-time graph visualization, AI anomaly detection, data logging 1.3 BOM Component Function Platform2Go 4200 Transmit node: read MKR IMU, package IMU X/Y/Z data into CAN frames MKR IMU Shield Motion sensor source (Accel X,Y,Z float values) CAN Twisted Pair Cable Differential CAN bus wiring, 120Ω termination resistors at bus ends Arduino Uno Q Central receive node, custom MAX33040 CAN receiver stack MAX33040 CAN Transceiver Shield Physical layer CAN bus interface for Uno Q USB Cables Platform2Go 4200 power/debug; Uno Q USB to PC for VISA NI-VISA Driver + LabVIEW PC visualization, data analysis, AI detection 1.4CAN Bus Wiring: Platform2Go 4200 CAN_H -> MAX33040 CAN_H Platform2Go 4200 CAN_L -> MAX33040 CAN_L Common GND connection between all CAN nodes 120Ω resistor across CAN_H/CAN_L at Platform2Go 4200 and Uno Q bus endpoints over MAX33040 Shiel 2 Transmit Side – Platform2Go 4200 Workflow Platform2Go 4200 polls IMU via I2C, reads raw acceleration X/Y/Z , converts raw integer register values to engineering float units #include #include float x, y, z; void setup() { Serial.begin(9600); while (!Serial); if (!IMU.begin()) { Serial.println("Failed to initialize IMU!"); while (1); } Serial.print("Accelerometer sample rate = "); Serial.print(IMU.accelerationSampleRate()); Serial.println(" Hz and Acceleration in G's "); Serial.println("X\tY\tZ"); if (IMU.accelerationAvailable()) { IMU.readAcceleration(x, y, z); Serial.print(x); Serial.print('\t'); Serial.print(y); Serial.print('\t'); Serial.println(z); } Serial.println("CAN Sender"); // start the CAN bus at 500 kbps if (!CAN.begin(500E3)) { Serial.println("Starting CAN failed!"); while (1); } } void loop() { // send packet: id is 11 bits, packet can contain up to 8 bytes of data Serial.print("Sending packet ... "); CAN.beginPacket(0x12); CAN.write('h'); CAN.write('e'); CAN.write('l'); CAN.write('l'); CAN.write('o'); /************` if (IMU.accelerationAvailable()) { IMU.readAcceleration(x, y, z); CAN.write(&x,4); //Serial.print('\t'); CAN.write(y); //Serial.print('\t'); CAN.write(z); }*/ CAN.endPacket(); int packetSize = CAN.parsePacket(); if (packetSize) { // received a packet Serial.print("Received "); } Serial.println("done"); } The reading for x-y-z is output 3 Receive Side – Arduino Uno Q + MAX33040 Custom Self-Built CAN Library 3.1 Hardware Control Logic MAX33040D4 STB pin set HIGH on startup to exit low-power standby UART hardware pins D0(RX)/D1(TX) connect directly to MAX33040 differential CAN physical layer 3.2 The library with GPIＯpin simulation for CAN #include "MAX33040_CAN.h" // ============================================ // ============================================ static MAX33040_CAN* _instance = NULL; // ============================================ MAX33040_CAN::MAX33040_CAN(uint8_t txPin, uint8_t rxPin) : _txPin(txPin) , _rxPin(rxPin) , _speed(DEFAULT_CAN_SPEED) , _txState(CAN_STATE_IDLE) , _txActive(false) , _rxState(CAN_STATE_IDLE) , _rxReady(false) , _rxQueueHead(0) , _rxQueueTail(0) , _errorCount(0) { } // ============================================ bool MAX33040_CAN::begin(uint32_t speed) { _speed = speed; // 初始化引脚 pinMode(_txPin, OUTPUT); digitalWrite(_txPin, HIGH); // CAN recessive pinMode(_rxPin, INPUT); _instance = this; _txState = CAN_STATE_IDLE; _txActive = false; _rxState = CAN_STATE_IDLE; _rxReady = false; _rxQueueHead = 0; _rxQueueTail = 0; _errorCount = 0; attachInterrupt(CAN_RX_INT, []() { if (_instance) { _instance->interruptHandler(); } }, CHANGE); return true; } // ============================================ uint8_t MAX33040_CAN::calcCRC(const CANFrame& frame) { uint16_t crc = 0; for (int i = 10; i >= 0; i--) { bool bit = (frame.id >> i) & 1; bool newBit = bit ^ ((crc >> 14) & 1); crc = (crc = 0; i--) { bool bit = (frame.dlc >> i) & 1; bool newBit = bit ^ ((crc >> 14) & 1); crc = (crc = 0; i--) { bool bit = (frame.data[j] >> i) & 1; bool newBit = bit ^ ((crc >> 14) & 1); crc = (crc > 7); } // ============================================ void MAX33040_CAN::txIdle() { digitalWrite(_txPin, HIGH); // Recessive } void MAX33040_CAN::txDominant() { digitalWrite(_txPin, LOW); // Dominant } void MAX33040_CAN::writeBit(bool bit) { if (bit) { txIdle(); } else { txDominant(); } } // ============================================ bool MAX33040_CAN::sendFrame(const CANFrame& frame) { if (_txActive) { return false; } _txFrame = frame; if (_txFrame.dlc > 8) _txFrame.dlc = 8; _txState = CAN_STATE_RECV_SOF; _txActive = true; _txBitCount = 0; _txByteIndex = 0; _txBitIndex = 0; _txStartTime = micros(); txDominant(); return true; } // ============================================ bool MAX33040_CAN::sendAccelData(const AccelData& accel) { CANFrame frame; frame.id = CAN_ID_ACCEL_DATA; frame.dlc = 12; uint8_t* px = (uint8_t*)&accel.x; uint8_t* py = (uint8_t*)&accel.y; uint8_t* pz = (uint8_t*)&accel.z; for (int i = 0; i _txBitCount) { bool txBit = HIGH; switch (_txState) { case CAN_STATE_RECV_SOF: { _txState = CAN_STATE_RECV_ID; _txBitCount++; _txBitIndex = 10; break; } case CAN_STATE_RECV_ID: { txBit = (_txFrame.id >> _txBitIndex) & 1; if (_txBitIndex == 0) { _txState = CAN_STATE_RECV_RTR; } _txBitIndex--; break; } case CAN_STATE_RECV_RTR: { _txState = CAN_STATE_RECV_DLC; _txBitIndex = 3; break; } case CAN_STATE_RECV_DLC: { txBit = (_txFrame.dlc >> _txBitIndex) & 1; if (_txBitIndex == 0) { _txState = CAN_STATE_RECV_DATA; _txByteIndex = 0; _txBitIndex = 7; } else { _txBitIndex--; } break; } case CAN_STATE_RECV_DATA: { if (_txByteIndex > _txBitIndex) & 1; if (_txBitIndex == 0) { _txByteIndex++; _txBitIndex = 7; if (_txByteIndex >= _txFrame.dlc) { _txState = CAN_STATE_RECV_CRC; _txBitIndex = 14; _crcAccum = calcCRC(_txFrame); } } else { _txBitIndex--; } } break; } case CAN_STATE_RECV_CRC: { txBit = (_crcAccum >> _txBitIndex) & 1; if (_txBitIndex == 0) { _txState = CAN_STATE_RECV_ACK; } else { _txBitIndex--; } break; } case CAN_STATE_RECV_ACK: { _txState = CAN_STATE_RECV_EOF; _txBitCount = 0; break; } case CAN_STATE_RECV_EOF: { _txState = CAN_STATE_IDLE; _txActive = false; txIdle(); return; } default: _txActive = false; txIdle(); return; } writeBit(txBit); _txBitCount++; } } // ============================================ void MAX33040_CAN::interruptHandler() { static uint32_t lastTime = 0; static uint8_t lastState = HIGH; uint32_t now = micros(); uint8_t currentState = digitalRead(_rxPin); if (currentState == lastState) return; uint32_t delta = now - lastTime; lastTime = now; lastState = currentState; uint32_t bitTime = 1000000UL / _speed; uint8_t bits = delta / bitTime; if (bits == 0) bits = 1; bool bit = (currentState == HIGH); static uint8_t bitBuffer[32]; static uint8_t bitIndex = 0; static bool inFrame = false; if (!inFrame && !bit && _rxState == CAN_STATE_IDLE) { inFrame = true; _rxState = CAN_STATE_RECV_ID; _rxBitCount = 1; _rxByteIndex = 0; _rxBitIndex = 10; bitIndex = 0; _crcAccum = 0; memset(&_rxFrame, 0, sizeof(_rxFrame)); return; } if (!inFrame) return; for (uint8_t i = 0; i = 11 + 1 + 4 + 8 * 8 + 15 + 2 + 7) { parseReceivedFrame(bitBuffer); inFrame = false; _rxState = CAN_STATE_IDLE; return; } } } void MAX33040_CAN::parseReceivedFrame(uint8_t* buffer) { uint8_t idx = 0; idx++; _rxFrame.id = 0; for (int i = 10; i >= 0; i--) { _rxFrame.id |= (buffer[idx++] & 1) = 0; i--) { _rxFrame.dlc |= (buffer[idx++] & 1) 8) _rxFrame.dlc = 8; for (uint8_t b = 0; b = 0; i--) { _rxFrame.data[b] |= (buffer[idx++] & 1) 0 String cleaning subVI: Strip \r\n line terminators IMU Serial String Parsing (Extract X/Y/Z Floats) String Split by comma delimiter → string array,ax,ay,az, Array index validation (array length =7 before conversion, reject broken partial frames) String-to-number conversion for 3 float outputs: ax,ay,az Graphical Visualization & AI Anomaly Detection Real-Time Waveform Chart: 6 trace curves (Accel X/Y/Z ), scrolling live motion plot Python AI integration (advanced) 5 Summary The Labview is perfect for industrial line supervision and the CAN is typical choice for industrial communication over Vehicles. All the kits is enough for this design, but misuse of port and library put off the progress. This is how the project proposed and how to implement the idea. There are still more to improve for the Industrial line in operation.