Resolving RoboDK Omron Remote Post Processor TM5-900 FTP Errors

1. Problem Overview

The Omron Remote post processor in RoboDK provides a path for offline-generated robot programs to be pushed to an Omron TM collaborative robot (such as the TM5-900) over the local network using FTP, with Modbus TCP handling the start, stop, and status handshake. When the post processor generates a script and attempts to transfer the file to the robot controller, the integration can fail with file-transfer errors, listen-node timeouts, or silent failures where the program is generated locally but never appears on the robot.

This reference documents the diagnostic procedure and the resolution path for the most common failure modes encountered when the Omron Remote post processor is paired with a TM5-900 running TMflow, with RoboDK 5.5.x as the generation host. The same approach applies to TM5, TM7, TM12, and TM14 cobots because the post processor uses the same TMflow FTP endpoint and the same Modbus register layout that TMflow exposes through its built-in Modbus TCP server.

2. System Architecture and Data Flow

The Omron Remote post processor is a Python-based code generator inside RoboDK. When the user selects it in the cell properties, the post processor does three things on every program run:

1. Generates a TMflow script file (typically a .cs or .txt payload) from the RoboDK station.
2. Wraps the script with a RoboDK driver Python file that performs the FTP upload, polls the Modbus handshake registers, and reports program state back to RoboDK.
3. Attempts to connect to the TMflow FTP server on the controller and to the Modbus TCP server, then triggers program execution through a write to the start register.

The end-to-end data path is summarized below.

Both the FTP channel (control + data) and the Modbus TCP session ride over the same Ethernet link. A failure in either service breaks the upload, but the failure mode the operator sees depends on which leg has failed.

3. TM5-900 Hardware and Network Context

The TM5-900 is a 6-axis collaborative robot in the Omron TM series. The values in the table below are stated by Omron for the stock TM5-900 hardware and are used here to size the network and to identify the physical node that must be reachable from RoboDK.

4. Prerequisites

Before running the diagnostic procedure, verify the following baseline items.

1. RoboDK install path on Windows. Confirm the install location, typically C:\RoboDK\, and that the user account running RoboDK has write access to the post-processor folder. The default path is C:\RoboDK\Posts\.
2. RoboDK license. A trial, educational, or professional license must be active. The Omron Remote post processor does not require a paid post-processor entitlement on top of the RoboDK license, but the RoboDK driver that performs the FTP upload runs only when RoboDK itself is licensed and connected.
3. RoboDK version. Use the latest 5.5.x or later build. Earlier builds of the Omron Remote post processor had known issues that were corrected in subsequent 5.5.x maintenance releases; a fix was published the day after the report reproduced in the field.
4. TMflow project with a Listen node. The TMflow project on the robot must contain a Listen node configured to listen on the same Modbus register address that the post processor writes to. Without this node, TMflow will accept the FTP upload but never execute the program because no flow triggers.
5. Modbus TCP server enabled in TMflow. Settings → Network → Modbus TCP → Enable.
6. FTP server reachable on the controller. TMflow exposes an FTP endpoint on TCP/21 of the controller IP. Use an FTP client (FileZilla, Windows Explorer ftp://) to log in with the TMflow credentials before involving RoboDK.
7. Layer-3 connectivity. ping <controller_ip> must succeed from the RoboDK PC.

5. Common Error Scenarios

The errors that surface when the Omron Remote post processor fails fall into the categories below. Each maps to a specific layer in the integration stack.

6. Diagnostic Procedure

Run the procedure in order. Each step validates one layer of the stack. Do not skip ahead; the post-processor behavior looks identical for several distinct root causes.

6.1 Validate Layer-3 connectivity

1. Open a Windows command prompt on the RoboDK PC.
2. Run ping <TM5-900_IP> -n 10.
3. Confirm round-trip time below 5 ms on a wired link and 0% packet loss. Anything above indicates a duplex mismatch, bad cable, or a managed switch with an inactive port.
4. Run arp -a and verify the controller MAC address resolves. The TM controller's MAC prefix is stamped on its label.

6.2 Validate FTP independently

1. Open FileZilla or ftp from the Windows command line.
2. Connect to ftp://<TM5-900_IP> using the TMflow user account and password. The default TMflow FTP account is the user set under Settings → User Management.
3. Change directory to /programs/ or the location the Listen node expects.
4. Upload a small test file (test.txt) and confirm it appears in the TMflow Project Explorer after refresh.

6.3 Validate Modbus TCP independently

1. Use a Modbus TCP test client (modbuspoll, qModMaster, or a Python pymodbus script).
2. Connect to <TM5-900_IP>:502.
3. Read holding register 0. TMflow exposes a set of registers whose default base varies with TMflow version. The Omron Remote post processor expects to write a function code 05 (Write Single Coil) or function code 06 (Write Single Register) to the start address and to read function code 03 (Read Holding Registers) from the status address.
4. If the read fails with connection refused or timeout, confirm that Settings → Network → Modbus TCP Server is enabled in TMflow.

6.4 Validate the Listen node

1. In TMflow, open the project that should be triggered.
2. Confirm a Listen node exists at the top of the flow.
3. Confirm the Listen node is configured for the Modbus register address used by the post processor. The default in the Omron Remote post processor is register 0 (coil 0) for the start trigger, register 1 (coil 1) for the stop trigger, and register 100 (holding) for status feedback. Verify against the comments at the top of the post processor Python file.
4. Right-click the Listen node → Test. The trigger should fire if you write to the configured register from the Modbus test client.

6.5 Validate the RoboDK post processor selection

1. In RoboDK, open the station.
2. Select the robot → right-click → Select Post Processor.
3. Confirm that "Omron Remote" or "Omron-Tecman Remote" is selected, not the vanilla "Omron" or "TM" post processor. The Remote variant is the only one that issues the FTP upload and Modbus handshake; the standard post processor only emits TMflow-compatible script text.

6.6 Validate the generated driver

1. Right-click the program → Generate Robot Program (F6).
2. Open the folder RoboDK writes to. Two artifacts are produced: the TMflow script (.cs or .txt) and a Python driver file.
3. Open the Python driver and confirm the controller IP, FTP user, FTP password, Modbus port, and register addresses match the TMflow configuration on the cell.

7. Root Cause Analysis

The most common root cause in the field is a version mismatch between the post processor file shipped with the RoboDK install and the post processor source the integrator customized. When the Omron Remote post processor was first distributed, the generated Python driver used a function call sequence that worked against older TMflow builds but raised exceptions against later ones. A bug fix landed in the next daily build of RoboDK after the report was filed, and the fixed source was provided directly to the integrator to drop into C:\RoboDK\Posts\.

The second most common root cause is Listen node misconfiguration. The FTP upload succeeds, but TMflow has no trigger to consume the new file, so the operator sees a successful upload followed by silence.

The third most common root cause is credential drift. TMflow credentials are user-managed and can be changed without notifying the upstream RoboDK station. The Python driver keeps the old password baked in until the post processor is regenerated.

8. Resolution Procedure

Apply the resolution steps below in order. They are additive; you do not need to restart between them.

8.1 Update RoboDK to the latest 5.5.x maintenance release

1. Open RoboDK → Help → Check for Updates.
2. If a newer build is available, install it.
3. Restart RoboDK.

The vendor publishes daily builds. Confirm the post-processor fix is included by checking the release notes for an entry that mentions "Omron Remote" or "TM" before regenerating.

8.2 Refresh the Omron Remote post processor file

1. Close RoboDK.
2. Replace the post processor file in C:\RoboDK\Posts\Omron_Remote.py (the filename varies by version) with the source the vendor provides.
3. Restart RoboDK.
4. Re-select the Omron Remote post processor on the robot in the station tree.

8.3 Verify the controller IP and credentials in the station

1. Right-click the robot → Properties → Connection.
2. Confirm the IP matches the TM5-900 controller.
3. Confirm the FTP username and password match the TMflow account. These are stored in the station file (.rdk) in plain text. Restrict read access to the station file accordingly.

8.4 Rebuild and re-test

1. Right-click the program → Generate Robot Program.
2. Confirm the driver Python file is regenerated against the new post processor.
3. Run the driver manually (python driver.py) and watch the console output for FTP transfer lines and Modbus handshake lines.

9. Verification

After applying the resolution, validate the integration end-to-end.

10. Advanced Troubleshooting Matrix

The matrix below consolidates diagnostic steps for field escalations. Apply it when the standard procedure does not resolve the fault.

11. Network and Security Hardening

Cells that go from lab to production need additional consideration. The Omron Remote post processor uses plaintext FTP and plaintext Modbus TCP, both of which expose credentials and command traffic on the wire.

• Segment the robot onto a private VLAN with the RoboDK PC and no other hosts.
• Disable inter-VLAN routing for TCP/21 and TCP/502 unless a remote operations dashboard explicitly needs it.
• Set TMflow user accounts to non-default passwords. The default TMflow user account is a known value; if it is left default, any host on the same VLAN can push programs.
• If the cell must cross an IT-managed network, terminate FTP at a jump host or wrap the traffic in an IPsec tunnel rather than enabling plain FTP across the WAN.
• Audit the .rdk station file location. The FTP password is stored in the station file in plain text; restrict NTFS permissions on the folder that contains it.

12. Compatibility and Version Notes

The Omron Remote post processor has evolved across RoboDK 5.x releases. The table below lists known behavior by release.

Always regenerate the driver Python file after any of the following: RoboDK upgrade, post processor replacement, TMflow upgrade, or TMflow Listen node reconfiguration. The driver captures the configuration at generation time; it does not re-read the TMflow settings at runtime.

13. Commissioning Checklist

1. TMflow project contains a Listen node at the trigger register the post processor writes to.
2. Modbus TCP server is enabled in TMflow.
3. FTP server is reachable from RoboDK with the TMflow user account.
4. ping succeeds with < 5 ms round-trip and 0% loss.
5. RoboDK post processor is the Remote variant, not the vanilla TM post processor.
6. RoboDK version is the latest 5.5.x or later.
7. Post processor source matches the vendor's latest (not a user-modified copy).
8. Robot is in Auto mode and not in a latched safety stop.
9. Drive robot generated script once and verify motion completes.
10. Confirm RoboDK console reads program-complete status within the driver timeout.

14. Frequently Asked Questions