Hilscher Forum
connecting Mitsubishi via RS485 - Printable Version

+- Hilscher Forum (https://forum.hilscher.com)
+-- Forum: netPI - Ruggedized Industrial Ethernet Raspberry Pi (https://forum.hilscher.com/Forum-netPI-Ruggedized-Industrial-Ethernet-Raspberry-Pi)
+--- Forum: Hardware (https://forum.hilscher.com/Forum-Hardware)
+--- Thread: connecting Mitsubishi via RS485 (/Thread-connecting-Mitsubishi-via-RS485)

Pages: 1 2

connecting Mitsubishi via RS485 - COswald - January-2nd-2020

Hello together,

in the next days, I will get a "NIOT-E-TPI51-EN-RE" with a RS485-NPIX for testing with our machine PLCs. Beforehand, I want to know, if there are any experiences in connecting the device to a Mitsubishi FX3 or FX5 via RS485 and how to grab data from the PLC and present them in a OPC/UA-Server?

I'ved tested another EDGE-Gteway which simply used the Mitsubishi called "Computer Link" communication protocol to acquire data from coils and registers of the PLC.

If no specific knowledge is available for this, is a sample for getting data via serial MODBUS connection? Althrough this solution would be second best, because in this case, I have to write the MODBUS communication in the PLC.

Second goal is to write data from the OPC/UA-Server into the PLC. So this would mean, that informations must be written from OPC/UA-Server (Docker) to the MODBUS-Registers. I'm a little bin insecure about this, after reading the manual, due to the strict seperation between containers, operation system(s) and hardware.

Any help is welcome in this state.

Have a fine day, everyday.

Carsten Oswald

RE: connecting Mitsubishi via RS485 - Armin@netPI - January-2nd-2020

Hello Carsten,

I want to first mention at this stage that this forum was made for the device name NIOT-E-NPI3-51-EN-RE or called "netPI" as marketing name.

I agree that both devices NIOT-E-NPI3-51-EN-RE and NIOT-E-TPI51-EN-RE look similar, but they come indeed with different software preloaded.

The device NIOT-E-NPI3-51-EN-RE just has Docker preinstalled and you can add software to it as containers only whereas NIOT-E-TPI51-EN-RE (your device) comes with Docker AND Node-RED preinstalled. So with Node-RED you have a software ready-to-use to realize different kind of software connectivity.

Since this forum is made for netPI only and handles all questions around "Docker and Containers" preferable I can just give limited support for your device (which of course includes Docker also) but Node-RED as main software. Support for your device can be received through hotline@hilscher.com.

A word to the NPIX-RS485 module. First of all make sure you have a RS-485 module of #REV2. There is a bar code on the module and in the lower right corner of it there shoul be the value 2. This module or #REV2 just needs the pin BCM_TX_EN (GPIO 17) set to high = 1 to be enabled and then works in auto direction control for transmitting and receiving frames. The NPIX-RS485 is connected to the "mini" UART of the Raspberry CPU working in your device. This UART has some restrictions in term of UART functionality. These limitations are all writting the NPIX manual located here https://www.netiot.com/netpi/industrial-raspberry-pi-3/ in the download section. So you should check if the RS485 module in conjunction with the Mitsubishi PLC will work or not based on this UART restrictions.

As next a word to Node-RED as preinstalled software. This software has some nodes preinstalled which enables the communication over Modbus RTU and a lot more. I search on Google for "Computer Link" protocol and found some links, but what I did not find was any Node-RED function and support for this type of protocol. So I have doubts it will run with the PLC directly. So your fall-back as you said is "Modbus" which is supported by Node-RED.

The preinstalled Node-RED also includes the OPC UA nodes https://flows.nodered.org/node/node-red-contrib-opcua. If you read details on this page you see that it supports OPC UA server functionality as well. So if you get the Modbus Nodes connected to talk to the Mitsubishi PLC you could pass the data to the OPC UA server and from there it can be read out by any client.

The cool thing with Node-RED is that before receiving the NIOT-E-TPI51... device is that you can install Node-RED on Windows already and play with it immediately to get familiar with it. Here is a link how to do it: http://www.brainboxes.com/faq/items/installing-and-running-node-red-on-a-windows-pc

If you have more questions don't hesitate to ask


RE: connecting Mitsubishi via RS485 - Armin@netPI - January-2nd-2020

Hello Carsten,

there is one additional note. I told you about the similarities between the NIOT-E-TPI and NIOT-E-NPI devices. Both feature  Docker.

In the end this means that all Docker container that have ever been programmed for NIOT-E-NPI device work also with NIOT-E-TPI (your device).

There is a Docker Hub repository from where you can load Docker containers from that have been initially made for NIOT-E-NPI device.

It is located here: https://registry.hub.docker.com/r/hilschernetpi/

There is one container that includes Node-RED in order to support Node-RED on NIOT-E-NPI device also. You can use this container on your NIOT-E-TPI device too. But you need to disable the pre-installed Node-RED that is part of your device by default.
The advantage of this Node-RED container is the use of a newer version of Node-RED, the up-to-date nodes, and its update capabilities compared to the default Node-RED that is preinstalled in your NIOT-E-TPI. Additionally this container has much more nodes from the community installed in Node-RED than the default Node-RED.

The Node-RED container and its README how to get it started is located here https://registry.hub.docker.com/r/hilschernetpi/netpi-nodered

Here is a video that shows how to setup a container in principle: https://youtu.be/A-asfhl7b0c

Just understand this post as a tipp from my side.

RE: connecting Mitsubishi via RS485 - COswald - January-3rd-2020

Hello Armin,

to get things started I followed your advice and got the Node-RED package.
During installation, the npm-Installer thrown a error because of self-signed certificates in the Node-RED download.

This could be easy be managed by entering the following line at the command prompt
npm config set ca=""

I also added the OPC-UA nodes, while in th CLI
npm install -g node-red-contrib-opcua

Now I have a Node-RED test enviroment for the first steps.

Thinking, we will read and hear each other very soon. ;-)

Have a fine weekend,


RE: connecting Mitsubishi via RS485 - Armin@netPI - January-3rd-2020

Well Carsten just to make sure I understood everything well. You installed the Node-RED package under Windows or already on your device? This is not clear to me.

If it is "Node-RED for Windows" then I am sorry if the link I sent did not work right away.

I personally love Node-RED. My whole home automation system is based on Node-RED since 3 years. Node-RED is intuitive and easy to understand and you can create own applications fast. This is what counts in my eyes. Meanwhile there are over 2000 different nodes available on the market.

One tipp: instead of using the CLI to install additional nodes, you can use the Node-RED embedded installer with your mouse and keyboard. You can find it in Node-RED upper right corner settings.

RE: connecting Mitsubishi via RS485 - COswald - January-6th-2020

Hello Armin,

the old OPCUA nodeset seams to be to be obsolete. So I get the better supported IIoT 

node-red-contrib-iiot-opcua 3.12.0

With this nodeset, it was easy to get a OPC/UA-Server running with the needed capabilities to set up a UMATI compatible server.


Now I'm waiting for the device for testing.

Kind regards,


RE: connecting Mitsubishi via RS485 - Armin@netPI - January-6th-2020

Wow that was a fast setup. Thanks for sharing your experience.

I am using the https://flows.nodered.org/node/node-red-contrib-opcua package for OPC UA communications. It was updated 5 days ago, so this one doesn't seem to be obsolete still.


RE: connecting Mitsubishi via RS485 - COswald - January-13th-2020

Hello Armin,

the NIOT-Gateway came to my desk today. To transfer the OPC Server was made in the blink of an eye.

Next to do is the setup of the MODBUS-Interface. Here I'm feeling a little bit lost. MODBUS. The standard defines addresses for the slaves. So, if I cannot set a address to the MODBUS-nodes, does this mean, that the NIOT and the netPI are always the server?
Second, very confusing thread is, that the LEDs on the RS485-NPIX do not automatically reflect the corresponding state of the interface.

Do you have a working example for MODBUS RTU RS485 communication?

Looking forward a brighter future,


RE: connecting Mitsubishi via RS485 - Armin@netPI - January-13th-2020

Hello Carsten,

if you want to use RS485 for communication then you need to know which device is the master and which the slave. This is how Modbus RTU works.

I suppose your PLC is the modbus slave , or isn't it? I don't know. You need to get this information from the PLC. Here I can't help.

netPI - depending on the Node-RED node you use - can be either master or slave on RS-485 NPIX.

A statement to the RS485 LEDs: Since this interface is just solving the physics there is in no way a definition whether the protocol Modbus goes across it, nor the protocol M-Bus, Bacnet or any other serial protocol. This is all decided by the application side that is using the NPIX module during runtime ... so then a question back: how shall then the LED automatically know how to behave on the different type of protocols in use and when to be red or green or on and off. This can only be the responsibility as well of the application that uses the interface. This is why the LED of the NPIX Modules are free programmable.

I have no working example of Modbus RTU communication - respectively a Node-RED example. In best case it is just using the preinstalled Modbus client/master node within the Node-RED node catalogue. Client/Master if your Mitsubishi PLC is slave/server ... which you need to get out from somewhere as information


RE: connecting Mitsubishi via RS485 - Armin@netPI - January-13th-2020

one thing in addition. If your PLC is slave ... then it must have a slave address. You need to get out the baudrate, the serial port settings in general and finally the Modbus RTU slave address. It might be that you have to ask the PLC programmer for this parameters.