Pi to Arduino using ModBUS over WIFI

Hi all!

So I am fooling around with a Raspberry Pi and an Arduino Uno + WiFi shield.

I am using CodeSys and trying to write some values to the Uno using a ModBUS connection over WiFi.

Somehow the connection is not being made. When I monitor CodeSys the ModBUS slave is blinking.

My question. Is there any difference in a package (header?) if it is sent over WiFi or wired ethernet? Anyone else experimented using ModBUS TCP over WiFi?

First thing first, does it work over wired connection?

USPS is on its way with my ethernet shield.... Lol, I will let you know when I get it.

Thank you!

My approach would be to test using a PC based Modbus/TCP simulator like Chipkin Automation or ModScan32, so that you can also run Wireshark and monitor the traffic.

Which WiFi shield are you using ? Which Modbus/TCP library ?

My desk is currently littered with prototyping boards; Arduino Uno, Teensy 3.1, and MBED LPC1768, and I have some variation of Mobusino running over USB/serial on each one.

In general, Modbus TCP looks exactly the same at the TCP level, no matter whether it's been transported over WiFi or Ethernet.

That's a good idea, had not thought of that..

I am using the Arduino WiFi shield. I posted my code here, no need to repeat it .

http://forum.arduino.cc/index.php?topic=317755.0

I am pretty new to Arduino and PI. Played around with the MBED a little. It is easy to make a GEEK happy huh .

I tried the Wireshark thing, quick and dirty.

I am getting no connection in my Modbus tool, but in wireshark I see a response from the Uno, see attachment.

The Destination Port is changing with every message tho. Why is that?

I am pretty green when it comes to Modbus so please bear with me..

It's usually more helpful to attach the whole trace, but in this case what you show is useful. The response is a TCP RST which tells us the server is not listening on that port. The Modbus server or slave is not enabled, not running, listening on another port? I don't know that platform at all so can not help except to say no one is home there.

The client will typically use an ephemeral port to create it's connection, and use a different one each time it tries to connect. These are ports in the upper end of the range chosen to be disposable. They are used once and then new ones are chosen next time a socket is created, but of course there is wrap around. This is typical TCP behavior.

This is why you see the dst port change in this particular frame. Guess: it changes, but it is close, like 63869, 63870, 63871, etc?

Usually for TCP servers you need to call some form of listen so the port is available and then accept when a client connects (with a TCP SYN, as seen in Wireshark). I took a 30sec stroll through your code and found the port, set to 502 as it should be, but did not see any socket creation, or accept(). I could have missed it, or it could be done by one of the other function calls. A quick way to determine if this or any port is listening is through nmap or similar network scanner. For one port some just use Wireshark, but for those not so comfortable with this tool, nmap can be used. Point at port 502 and it needs to show as available before your ModbusTCP client will work.

Awesome! Thank you very much!

Yes you are right, the ports are very close to each other.

I will check that!

Ow.. How I do love this website....

I tried to scan the port and indeed it is closed.

But this snippet should open that up right?
WiFiServer MbServer(MB_PORT);

It is easy to make a GEEK happy huh

Click to expand...

Especially when the itch is so cheap to scratch. Yesterday I talked myself out of purchasing a Pololu A-Star Mini and an Adafruit Trinket to round out the stable of little controllers on my desk.

My favored TCP Port testing tool is TCPing; you can download it from Elifulkerson.com.

All the Mudbus (gosh, what a terrible name in the age of autocorrect) examples I can find are oriented toward the Ethernet shield instead of the WiFi shield, so I'm not sure what's failing to get configured.

Will WiFi.status return any useful information if WiFi.begin hasn't been called yet ?

Yes, that part is working. I think that is actually the status of the Shield, not the WiFi connection.

I returned some errors when I messed up the firmware upgrade of the shield .

I am positive that the WiFi connection is up. Just not the right port I guess..

Please upgrade the firmware
Attempting to connect to WPA SSID: 2WIRE697
You're connected to the networkSSID: 2WIRE697
BSSID: 74:9DC:73:F3:C9
signal strength (RSSI):-66
Encryption Type:4

IP Address: 192.168.1.84
MAC address: 78:C4:E:2:54:CC

Click to expand...

>>But this snippet should open that up right?
>>WiFiServer MbServer(MB_PORT);

Don't know. Can only say that it didn't. I did not see this source code for this from your link - so can not be sure (again, may have missed it). Not a code expert anyway, just a hack, so could not promise I could debug just by looking at it. I have a Udoo board with quad core ARM/Arduino, but I usually stick with the Linux side of things so never pushed the system this far.

If you are getting to the point of having a TCP RST come back from your connection attempt you can be pretty sure your networking infrastructure is good. Wireshark shows your issue lies with the application at this point - how to get a proper application executed. In my view, you cut the problem way down in scope, which is always useful.

On many full-blown OS's currently in use, we use netstat to see what is going on under the hood. So from inside out, we can use netstat, like

Linux: netstat -tnl
Windows: netstat -p tcp -a -n

and these will list the ports that are listening. With some other options, like -b for Windows or -p for Linux, we might even get the process that is handling those. So if your code was running on Linux, I would expect to see your process listed for what is listening on port 502 on my machine. But you have a common issue, as we usually do with embedded systems: no shell, and so no netstat. So only way to determine what is listening is from the outside in, with a port scanner. This is easier than it sounds - with embedded systems that are poorly designed, the very act of scanning the system can cause crashes and other issues giving no, or worse, false positive/negative results. It can also be problematic determining what is running or listening on that port from the outside. If it is a webserver or ftp server (for example; smtp as well) it might identify itself. For an industrial protocol server, forget it. You may be able to determine what is under the hood by specific behavior, but it can be tough.

Thank you for you help Robert!

I will wait for the wired shield and test it with that. I think you have pinpointed the problem to the creation of the socket.

Thanks again all, I really appreciate all the help!

WE DID IT!!!

I added the following lines to the library and it started working! You guys were right!!!

if (first == LOW)
{
MbServer.begin();
Serial.println("MbServer Begin");
first = HIGH;
}

Click to expand...

Thank you so much for all your help, wouldn't have known where to look otherwise!

If you get some "play time", I would be very interested to know if AdvancedHMI works on your setup. AdvancedHMI has a ModbusTCP driver and has been tested on the Pi using Mono. These are the details on getting it to work:

http://advancedhmi.com/forum/index.php?topic=666.0

The question was asked once whether AdvancedHMI could be used with CodeSys on the Raspberry Pi, but I wasn't sure if CodeSys supported being a ModbusTCP server to allow AdvancedHMI to read registers.