Hello

I want to develop the following project:

I have several buildings where I perform periodically an energy audit.

Every building needs an energy sensor (modbus rtu), a water flow meter (modbus rtu) and a gas flow meter (modbus rtu). Every sensor is very far from each other, so one of my design criteria is go wireless (modbus over the air, ie: wifi, rf etc).

My main question is: what is the best and cheapest way to create this local modbus network (wirelessly) for every building and then gather all measurements from modbus device using a remote server.

More question

- Do I need a modbus rtu/wifi converter in every sensor?

- If I have two sensors very close, can I use a rs485-wire and connected to this wire a modbus/wifi or a ethernet/serial like (http://www.chiyu-t.com.tw/eng/products/i/bf-430431450.htm)

- Which is the main difference between a modbus rtu/modbus tcp and a ethernet/serial converter?

thanks
jaime

 

Hello,

You can connect the Modbus RTU sensors located close using RS485 (up to 1500 m).

If you are looking for cheap solution you should use the Modbus RTU to Modbus TCP/IP converters and WiFi routers (with port forwarding configuration).

Regards
Andrzej
www.modbus.pl

 

>Every sensor is very far from each other

Very far means 10m, 100m, 1000m or 10000m?

How many buildings? How far apart?

The instruments are all Modbus RTU. Copper wire daisy chain them over RS-485.

If the buildings are networked on an ethernet LAN, then use a serial-to-ethernet server (one that offers Modbus, not all do) in each building and piggyback on the existing LAN for HMI software access.

If the buildings are not networked on a LAN, then there are numerous vendors of serial Modbus data industrial radios that can handle this. In the US, you can use 900MHz, much preferred if available.

If you're outside the US, you probably have to use 2.4GHz.

So if you have to deal with 2.4GHz and buildings aren't too dispersed, you could try cheap, and use a serial-to-ethernet server to get the RTU networked links on ethernet and use consumer grade WiFi to connect building to building. I don't shop consumer grade but there might even be WiFi components with remote antenna connections, allowing you some latitude in getting an antenna outside the building.

>Do I need a modbus rtu/wifi converter in every sensor?

Not if you can daisy chain them on RS-485.

> If I have two sensors very close, can I use a rs485-wire and connected to this wire a modbus/wifi or a ethernet/serial like (URL).
Yes, if the server device handles it.

I only use Digi, Lantronix and HMS Anybus because I know they work and I can't afford to experiment to save a buck and lose hours trying to make an alternative brand work.

That isn't to say your brand device won't work, but I don't know because I've haven't used it.

>Which is the main difference between a modbus rtu/modbus tcp and a ethernet/serial converter?

I assume you're asking what is the difference between those serial server devices that specifically state that they handle Modbus and those that don't. I honestly don't know. But I know that people who mess with the cheaper ones that are not Modbus specific run into all sorts of issues, as evidenced on this and other fora.

Mr. Linse is known to comment on this forum. I understand he codes for that category of devices. Perhaps he will enlighten us as to the differences.

 

Unless you are the building owner, I would avoid WiFi like the plague - it will ensnare you with IT politics, plus the distances it supports (as low as 100 feet) are pathetic. If you do own the building, then you can convert serial Modbus into Modbus/TCP-over-WiFi.

For non WiFi systems, find any of the dozens of firms making 900Mhz or 2.4Ghz 'wire-line replacement' modems not based on WiFi. They will allow a Master with RS-232 or RS-485 to treat the entire set of remotes as-if one big RS-485. Distances for these are commonly in the 500 feet to thousands of feet range (or even dozens of miles!) Plus since you are not doing 'WiFi', the building IT department probably won't even know you are there.

Digi sells them (like: http://www.digi.com/products/wireless-modems-peripherals/wireless-range-extenders-peripherals/), and dozens of other companies do as well.

 

jaime: <i>What is the best and cheapest way to create this local modbus network (wirelessly)...</i>

Well, I'm not sure I can tell you the best OR cheapest, but I do have some ideas on how it can be accomplished.

jaime: <i>Do I need a modbus rtu/wifi converter in every sensor?</i>

Possibly. If you want every device to be wireless, then obviously yes. However, there are other ways to skin this cat. If your devices are RS-232 or RS-422, there are serial to Ethernet adapters with multiple serial ports. So you each building could have one serial server and one WiFi access point. Moxa, Lantronics, Digi, etc. all have multi-port serial servers. You could even use a slice I/O module with multiple serial cards. Wago, Beckhoff, B&R, Turck, Phoenix, etc., etc., etc.

You can also use a straight serial-to-wireless adapter. Digi, Lantronix, Moxa, etc. all have solutions without needing an extra step. You might even pull this off with the slice I/O style. I'll also point out that the B&B Electronics Zlinx series transmit serial wirelessly and then switches back to SERIAL, skipping Ethernet altogether. That could be handy under certain circumstances.

jaime: <i>If I have two sensors very close, can I use a rs485-wire and connected to this wire a modbus/wifi or a ethernet/serial</i>

Sure. It might add a bit of an addressing headache.

jaime: <i>Which is the main difference between a modbus rtu/modbus tcp and a ethernet/serial converter?</i>

A generic Ethernet / serial converter has no understanding of protocols. This is often fine. You run a driver that makes the Ethernet device look like a COM port, and your software has no idea that the conversion is taking place. The converter doesn't care what protocol is being sent, it just makes the data show up. Thus your software is expecting Modbus-RTU on a COM port, and that's what it gets. Things get trickier if you're running on a system that can't have the driver. Now you'd be force to interpret raw TCP/IP packets that have RTU embedded in them, so you'll have to understand how both protocols are laid out to extract (or insert) the data you want. This is where Modbus/TCP to Modbus/RTU adapters come in. Modbus/TCP is dead simple, and has a straight forward conversion to RTU. Writing Modbus/TCP even from scratch is pretty easy, and many devices and operating systems already have it.

That was a long and rambling answer, as usual. Here's a hopefully more succinct version:

1) You have a PC with an application that expects to talk RTU to a COM port: use a generic serial-to-Ethernet converter.

2) You have a PLC or other device that does not give you the ability to install a proprietary driver, but you do have the ability to talk Modbus/TCP: use a Modbus/TCP to Modbus-RTU converter.

Hope that helps.

-James Ingraham
Sage Automation, Inc.

 

Hello James

Digi at first sight seems to fits my needs with PortServer TS (http://www.digi.com/products/serialservers/portserverts.jsp) in terms of tunnellize serial devi over digiport protocol which has several benefits in terms of latency, security and server overhead reduction. Digi serial servers expose a limited serial devices (depending of server serial interfaces 1,2,4...) toward a remote com. Based on that fact digi serial servers are unable to map an entire rs485 loop serving several serial devices, this seems to eliminate any future upgrading.

From your experience with digi is this correct?

I am planning to manage hundreds of serial servers at the same time (if DIGI is the bust for this task), which from your point of view could be the best way (Network Service Daemon, SCADA Server (OPC), etc) to ensure reliability, scalability, connecting issues logging, data collection, data exchange with another energy management platform?

thank you for comments

 

jaime (slightly edited): <i>Digi's PortServer TS seems to fits my needs.</i>

I wouldn't be surprised. Digi makes good stuff.

jaime: <i>Based on that fact digi serial servers are unable to map an entire rs485 loop serving several serial devices, this seems to eliminate any future upgrading. From your experience with digi is this correct?</i>

I have never actually tried this, and the manual is vague on details, but the PortServer TS MEI looks like it can handle several device off of one RS-485 port. This is probably a better question to ask the Digi folks; they are generally quite helpful.

jaime: <i>I am planning to manage hundreds of serial servers at the same time</i>

Wow. I've never tried to deal with that much serial traffic, so I'm afraid I'm not the best person to ask.

Good luck!

-James Ingraham
Sage Automation, Inc.

 

> Digi at first sight seems to fits my needs with PortServer TS

(First - the disclosure that I am an engineer for Digi and have worked for them or competitors in the same field for about 20 years)

Most of Digi's "Ethernet to Serial" products support the Modbus/TCP to RTU bridging, so you can also just use Modbus/TCP from your host/SCADA/OPC. This include the WiFi-to-serial products.

You mention "hundreds of serial servers", so the performance limitations would be within the PC running your hosting app. Digi has a customer with Sun servers running up to 1000 serial ports via 'realport'. For Windows or Linux I've only heard of customers in "many hundreds" range. However, imagine a PC with COM1 up to COM250? Even keeping track of which device is COM133 or COM207 becomes a challenge. (Many of the less-serious competitors choke at a dozen ports)

However, you'll find using the Modbus/TCP whenever possible lightens the load on your Ethernet and host because Digi realport literally moves RS-232 control signals, plus data-buffer "sync & flush" messages back and forth over the Ethernet. So if your Modbus/RTU driver asserts RTS, sends a request, then drops RTS, you'll find your host is sending from 4 to 8 TCP packets PER Modbus transaction & receiving another 4 to 8.

Whereas with Modbus/TCP you'd have fewer packets - just the request & response, plus the TCP acks. This will allow your host to support more remote devices.

 

Hi Jamie,

One such architecture that we have used for building automation is using our Wireless zigbee modules with 1 slave in each building connected serially via RS-485 connection to each Zigbee slave. The polling computer would be connected to the Zigbee master and be able to poll the status of each I-7000 series module. The module you select depends on the combination of I/O that is required. You can connect up to 256 I-7000 modules to 1 Zigbee. If you want an Etherent solution, we have that as well.

RS-485 Serial solution
http://www.icpdas-usa.com/products.php?PID=3378
http://www.icpdas-usa.com/products.php?PID=3377
http://www.icpdas-usa.com/products.php?PID=3316

Ethernet Solution
http://www.icpdas-usa.com/products.php?PID=3290
http://www.icpdas-usa.com/products.php?PID=3316
http://www.icpdas-usa.com/et7000table.php

 

You can use www.wiicom.it

>I want to develop the following project:

> I have several buildings where I perform periodically an energy audit.

---- snip ----