For a week I've played with cheap modbus RS485/Ethernet adapters like USR-TCP232-304. I was assuming they would "speak" modbus TCP on the ethernet side and modbus RTU over RS485. After countless experiments I've found what that these adapters are actually expecting is RTU over TCP on the ethernet side, so they're not repackaging the ADU/PDU but simply relay.
Is this a standardized way of doing modbus or do I simply misunderstand what's going on?
Looking at the datasheet for the USR-TCP232-304 I see no mention of Modbus support; it's a RS485 Serial to Ethernet Converter only. These units makes no attempt to understand the data flowing over the link (if they receive a byte via RS485 they send it via the TCP link and vice versa). They can be used to talk to pretty much any device that uses RS485 (there are a lot of other protocols that run over RS485).
Modbus RTU transmitted via this kind of unit is pretty common if not exactly standardised (it's not mentioned in the modbus spec to my knowledge). Often these devices include drivers that present themselves as a serial port so, from the applications perspective, there is no real difference between direct RS485 and going via one of these devices (other than timings).
It looks like the next model up includes a modbus gateway function that will act as a Modbus TCP server (and there are plenty of other options; they generally cost a bit more because of the additional processing required).
Related
How to determine whether device connected to the network is modbus device after getting valid ip range through broadcasting mechanism or How to Auto Discover the slave id of modbus device connected to the gateway ?
In the context of Modbus TCP, slaveId is not used to identify a Modbus device. IpAddress is used to identify the Modbus device if the device supports Modbus TCP/UDP.
if you want to discover the Modbus devices in a LAN, as you mentioned, you can send a broadcast message to all the range of IP addresses. But, there is no predefined register address to poll. Each Modbus device may be configured different address location.
Send TCP connection request for each :502.
And then for each connected device, like the Modscan tool, you can write your custom logic to scan all the registers in each discovered Modbus device.
You can try using nmap:
here you can find the tutorial to use.
You can also use Metasploit-framework(msfconsole):
Modbus Client Utility, you can read/write to modus device
Modbus Version Scanner, to detect modbus service
Modbus find unit ID, it only works under modbus TCP/IP, it send the request "0x04" to all the modbus ID(0-254) and check the response.
I am in a dilemma that whether i can use Ethernet chip with ATmega 16 for performing socket programming or not?
I actually want to send the real time position signals over the internet to the server using client server model. But will the ATmega 16 be able to process such high data using socket programming? I will be performing socket programming in c just a basic one.
You cannot implement a useful application with TCP socket connections in 1k RAM. So you should look for an Ethernet controller with integrated TPC/IP stack, like the WIZnet W5100.
If wireless is OK, you may also look out for GPRS/UMTS or WLAN modules with integrated TCP/IP stack. They are much more common than their cable-based counterparts.
Our project involves streaming captured pointCloud images from Xtion Pro Live to be transmitted wirelessly from a raspberry pi to a laptop. We propose to use UDP over TCP since UDP is faster than TCP. However, we also wanted to let the raspberry pi detect if it has lost its connection to the laptop. But since UDP is connectionless, here are the solutions that I can think of:
1.) Use TCP for detecting connection and UDP for streaming pointCloud
2.) Use UDP for streaming PointCloud and in the raspberry pi, it has to receive a frame from the laptop within a time window which this should serve as the detection for connection.
3.) Use TCP.
What should I use?
TCP, would be the most pragmatic option. Look how many images we receive on a single web page - that's all sent using TCP. There would be a lot more work required than detecting dead peers if you were to use UDP - you would also have to deal with dropped and duplicate packets, congestion control...
I am building an Arduino based servo driver that I want to control with OSC commands from my iPad over the Internet.
Is it possible to send OSC commands over 3G / UMTS with my iPad or iPhone to control a device? So I will not be limited by the router's range when I send OSC commands to the controller when both devices are part of the same Wi-Fi network.
It seems that the applications I downloaded (TouchOSC, iOSC) can only send OSC data over Wi-Fi, however I'd like to send the commands over the Internet (with port forwarding settings in my router).
I would get one of these. Look ma, no wi-fi :)
OSC typically uses UDP (User Datagram Protocol), even if some newer OSC implementations also allow TCP/IP messaging (also see Difference between TCP and UDP?).
Unfortunately (as far as I know), UDP does not work over 3G, which seems to be your problem. In other words: two mobile devices cannot talk to each other on a cellular network. So it has nothing to do with OSC apps not being able to do this, it's just not available from the cellular network.
However (I think, not tested), I see two workarounds here:
try to use TCP/IP instead of UDP to send your OSC packets
if you need UDP on the Arduino side, you could use a server in-between
Do port forwarding on your router to forward port x to the Arduino, and then use the IP address from whatsmyip.com and use that one in the touchOSC app when inputting the IP address. That may work.
I would like to be able to develop an iPhone application that can communicate with Modbus devices, but I'm not sure how to proceed. Has anyone had experience with this or are there existing libraries out there for this purpose?
You will need first to know how to make a simple TCP client on your iPhone, and a simple TCP server on your computer that your iPhone client will talk to via WiFi. Make sure PING command works and firewall does not block your server port before any client/server experiments, and make sure that server port for experimenting is greater then 1024 and not already used. Then take a look at MODBUS TCP specification from official site, get familiar with function codes you are interested in, and study C code found here. Then make a simple MODBUS TCP client that can send a request to MODBUS TCP server and interprete an answer. The best way is to start reading single register value, then progress in time and add more functions.
I do exactly all above points, my iOS Modbus lib works fine, application is now up on AppStore, PLCLink read and set any modBus data into my Wago home automation.
Installation guide : http://pautex.fr/plclink