The PLC100 has one RS-485 interface, and one RS-485 segment carries one master. Moving the cloud path off that segment clears the error. You can either connect the PLC100 to OwenCloud over Ethernet, or place an SP310P panel between the PLC and the PM210.
Where does the gateway's request stop on the RS-485 line?
Follow a single poll. The line is half-duplex. Only one transmitter may drive it at a time, and only the master decides when that happens. When the PM210 is also configured as a master, it sends its own frames on the same pair with no knowledge of the PLC's timing.
Two things fail as a result:
- Collisions: frames from the two masters overlap on the wire, and both sides see CRC failures or timeouts.
- No slave to answer: the PM210's request is addressed to the PLC100, but that port is running as a master. It does not answer as a slave at the same time.
OwenCloud receives no valid data for those parameters and marks them with error 255. The module side keeps working because the PLC still wins some bus time. That is why everything looks correct inside the PLC and fails only in the cloud.
Check 1: How many masters are on the segment?
List every device on the RS-485 pair and read its configured role from its configuration tool: the PLC project for the PLC100 and the OWEN configurator for the PM210.
| Device | Role in the failing setup | Role required |
|---|---|---|
| PLC100 (RS-485) | Master, polls the modules | Master, polls the modules |
| PM210 | Master, polls the PLC100 address | Not on this segment |
- Outcome: two masters. This is the root cause of error 255. Go to Check 2.
- Outcome: one master, error 255 still present. The fault is on the physical layer or in the serial settings. Check termination at both ends of the line, A/B polarity, and that baud rate, parity, stop bits and slave ID match on the PM210 and the polled device.
Moving the module polling into the PM210 does not help either. The PLC100 still needs those inputs to run its program, so the PLC must stay the master for the MV110 modules.
Check 2: Which free interface can carry the cloud traffic?
The PLC100's single RS-485 port is taken by the module bus. What remains is its Ethernet port. The next choice depends on one question: does the setpoint operator need a local HMI?
| Requirement | Path | Hardware added |
|---|---|---|
| Cloud monitoring and setpoints only | PLC100 Ethernet → 4G router → OwenCloud | Router with Ethernet port |
| Local panel plus cloud, setpoints from both | PLC100 Ethernet → SP310P; SP310P serial port → PM210 → OwenCloud | SP310P panel, PM210 |
- No local HMI: go to Branch A.
- Local HMI required: go to Branch B.
Branch A: Can the PLC100 reach OwenCloud directly over Ethernet?
Yes. This is the simplest path. The RS-485 segment stays exactly as it is when the modules display correctly: the PLC is the master and the two MV110 modules are slaves. OwenCloud reaches the PLC over Ethernet through a 4G router, so the cloud poll never touches the serial line.
- Take the PM210 off the RS-485 segment completely.
- Connect the PLC100 Ethernet port to the LAN side of the 4G router.
- Give the PLC100 a static IP, subnet and gateway that match the router's LAN. The gateway address must be the router's LAN IP.
- Add the PLC100 as an Ethernet device in OwenCloud, following the connection method OwenCloud documents for this controller.
- Map the module values and the program results the cloud should display as PLC variables. The cloud reads the PLC, not the modules.
Branch B: How is the SP310P wired between the PLC100 and the PM210?
Each link in this chain has exactly one master:
| Link | Master | Slave |
|---|---|---|
| Ethernet | SP310P | PLC100 |
| SP310P serial port (PLC port) to gateway | PM210 | SP310P |
| SP310P Download port | — | Configured as slave |
The panel acts as a data concentrator. It reads and writes PLC variables over Ethernet and holds copies in its internal registers. The PM210 polls those registers over the serial link and forwards them to OwenCloud.
- Keep the PLC100 RS-485 configuration unchanged: PLC as master, modules as slaves.
- In the SP310P project, create an Ethernet connection with the panel as master to the PLC100. Map the process values, program results and setpoint variables.
- Set the SP310P PLC port and Download port to slave mode. Assign a slave ID and serial parameters on the PLC port.
- Wire the PM210 to the SP310P PLC port. Configure the PM210 as master with the same baud rate, parity, stop bits and slave ID as the panel port.
- In OwenCloud, create the parameters against the panel's internal register addresses, not the PLC's addresses.
- Build the setpoint transfer logic in the panel project. A value written from the cloud lands in a panel register first; the panel must then write it to the PLC.
Recurring pitfall: the setpoint path is bidirectional. If the panel continuously reads the PLC setpoint back into the same register the cloud writes to, a cloud write can be overwritten on the next read cycle before it reaches the PLC. Keep separate registers for "value read from the PLC" and "value to write to the PLC". Trigger the write on change, from either the panel screen or the cloud.
How do you confirm setpoints move in both directions?
- Watch the MV110 input values in the PLC. They must update at the same rate as before the change. If they do not, the module bus still has a second master or a wiring fault.
- Watch the OwenCloud parameter status for every mapped value. Error 255 must be gone and values must refresh.
- Change a setpoint on the SP310P screen. Confirm the new value in the PLC variable, then in OwenCloud.
- Change the same setpoint from OwenCloud. Confirm it appears on the panel and in the PLC variable, and that it stays there across several poll cycles.
FAQ
Why does OwenCloud show error 255 when the PM210 polls the PLC100?
The PM210 was added as a second master on the same RS-485 line that the PLC100 already masters for the MV110 modules. The PLC port does not answer as a slave while it is a master, and the two masters' frames collide, so the cloud receives no valid data. Remove the PM210 from that segment and route cloud traffic over Ethernet or through an SP310P slave port.
Why does the PLC100 show module data correctly while the cloud fails?
The PLC is still the master on the module bus and gets enough bus time for its own polls. The PM210's requests to the PLC's address go unanswered. The failure shows up only on the gateway-to-PLC path.
Can setpoints be changed from both the SP310P panel and OwenCloud?
Yes, with the PLC100 as RS-485 master, the SP310P as Ethernet master to the PLC, and the PM210 as master on the panel's slave port. To verify, write a setpoint from the cloud and confirm it holds in the PLC variable over several poll cycles without being overwritten by the panel's read-back.