Searching \ for '[EE] MODBUS over XBee' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=modbus+over+xbee
Search entire site for: 'MODBUS over XBee'.

Exact match. Not showing close matches.
PICList Thread
'[EE] MODBUS over XBee'
2011\01\20@180642 by V G

picon face
Hey all,

I've been designing and implementing a temperature control system for my
university.

It is as follows:

There are two remote terminal units powered by PIC32s in two different
chambers. They are connected to a desktop PC through CAT3 ethernet cables in
a multidrop configuration. The network is RS485 and the protocol is MODBUS.

I recently decided to use XBee instead of a physical connection since it
will make expansion much much easier.

Basically, the desktop computer is running MODBUS (master) software and is
monitoring temperature, humidity, and so on from each of the RTUs and is
signalling them to control relays to turn heaters and humidifiers on and
off.

* I would like to implement MODBUS over XBee. Would this be relatively easy
to interface to a PIC32 on the RTU end?

* Also, how would I go about connecting an XBee module to the desktop
computer? Are there any adapters available?

* Currently, the MODBUS software is communicating to a physical serial port
(RS232) on the computer which is connected to a RS485 converter module which
is connected to the multidrop cable. Therefore, I'd need to emulate a serial
port on the desktop which communicates with the XBee. How difficult would
this be to do? Is this *unheard* of?

Do you guys have any other suggestions for this

2011\01\21@025408 by Christopher Head

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 20 Jan 2011 18:06:24 -0500
V G <spam_OUTx.solarwind.xTakeThisOuTspamgmail.com> wrote:
[snip]
> * I would like to implement MODBUS over XBee. Would this be
> relatively easy to interface to a PIC32 on the RTU end?

I don't know anything about MODBUS. In transparent mode, however, an
XBee is preconfigured with the address of a peer device and acts as a
farily dumb serial pipe which takes 8-bit asynchronous serial data.

>
> * Also, how would I go about connecting an XBee module to the desktop
> computer? Are there any adapters available?

Digi sells XBee PKG-U boards, which are small USB dongles with an FTDI
on them and a socket into which you can plug an XBee.

>
> * Currently, the MODBUS software is communicating to a physical
> serial port (RS232) on the computer which is connected to a RS485
> converter module which is connected to the multidrop cable.
> Therefore, I'd need to emulate a serial port on the desktop which
> communicates with the XBee. How difficult would this be to do? Is
> this *unheard* of?

See above, Digi PKG-U with FTDI. However, the multidrop issue changes
things a bit. While XBees can do multipoint communication, the sane way
to do this is in "API mode", where you use a frame structure for
communication which includes the address of the receiving XBee
(depending on how much modification you want/are able to make to each
part of the system, this may or may not be reasonable for you to use).
Alternatively if there are relatively few devices to communicate with
(say just 2 or 3) you could just have a separate dongle on the computer
for each device, preconfigured with the corresponding device's XBee's
address, and use them in transparent mode as completely independent
communication channels.

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: GnuPT 2.7.2

iEYEARECAAYFAk05O5sACgkQXUF6hOTGP7evpgCfUf+aCxe3iZqWz3jEk0yCZBBK
b4UAoIxo2fc9g36nqt72KdjZg3Dfetlr
=iy+r
-----END PGP SIGNATURE-----

2011\01\21@055941 by Ruben Jönsson

flavicon
face
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, 20 Jan 2011 18:06:24 -0500
> V G <.....x.solarwind.xKILLspamspam@spam@gmail.com> wrote:
> [snip]
> > * I would like to implement MODBUS over XBee. Would this be
> > relatively easy to interface to a PIC32 on the RTU end?
>
> I don't know anything about MODBUS. In transparent mode, however, an
> XBee is preconfigured with the address of a peer device and acts as a
> farily dumb serial pipe which takes 8-bit asynchronous serial data.
>
If the XBee doesn't hack up each modbus telegram in smaller chunks on the receiving end it could work by just setting it to the correct baudrate and other serial line parameters and use transparent mode.

The telegram has to be a continuous stream since the modbus protocol recognizes an end of telegram frame with a silence of 3.5 characters length. Silence for more then 1.5 character lengths but less than 3.5 characters means that the telegram should be aborted.

{Quote hidden}

If transparent mode is used and the modbus telegram frame can be sent in a continuous stream, the modbus protocol should take care of the addressing - all XBees receives all communication but it is only the addressed one that replies.

==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
rubenspamKILLspampp.sbbs.se
==============================

2011\01\21@065934 by V G

picon face
2011/1/21 Ruben Jönsson <.....rubenKILLspamspam.....pp.sbbs.se>

> If transparent mode is used and the modbus telegram frame can be sent in a
> continuous stream, the modbus protocol should take care of the addressing -
> all
> XBees receives all communication but it is only the addressed one that
> replies.


So transparent mode should take care of everything and I should be good to
go

2011\01\21@072245 by Ruben Jönsson

flavicon
face
> 2011/1/21 Ruben Jönsson <EraseMErubenspam_OUTspamTakeThisOuTpp.sbbs.se>
>
> > If transparent mode is used and the modbus telegram frame can be sent in a
> > continuous stream, the modbus protocol should take care of the addressing
> -
> > all
> > XBees receives all communication but it is only the addressed one that
> > replies.
>
>
> So transparent mode should take care of everything and I should be good to
> go?

I think so. Unless you have any gaps (even relatively short ones), introduced by the XBee, between characters for one telegram in the receiving end. After all, it is a radio which must have an own over-the-air protocoll that takes care of the radio traffic. It may very well be that the serial character stream is divided into several radio packets that is sent separately over the air.

/Ruben


==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
rubenspamspam_OUTpp.sbbs.se
==============================

2011\01\21@150220 by Christopher Head

picon face

On Fri, 21 Jan 2011 13:22:42 +0100
"Ruben Jönsson" <@spam@rubenKILLspamspampp.sbbs.se> wrote:

> I think so. Unless you have any gaps (even relatively short ones),
> introduced by the XBee, between characters for one telegram in the
> receiving end. After all, it is a radio which must have an own
> over-the-air protocoll that takes care of the radio traffic. It may
> very well be that the serial character stream is divided into several
> radio packets that is sent separately over the air.

This probably won't work, transparent mode has a packetization
threshold (it accumulates bytes and then sends them as a packet). You
can adjust the timing and threshold, but I doubt you'll get that fine
resolution on it. In fact I doubt 802.15.4 *CAN* get that close
resolution, since each byte would need a whole radio frame around it.
Maybe, MAYBE, at low speeds. YMMV a lot. I didn't know when I sent my
first message that MODBUS had such strict timing constraints.

Chris

2011\01\21@152153 by Bob Ammerman

flavicon
face
>> I think so. Unless you have any gaps (even relatively short ones),
>> introduced by the XBee, between characters for one telegram in the
>> receiving end. After all, it is a radio which must have an own
>> over-the-air protocoll that takes care of the radio traffic. It may
>> very well be that the serial character stream is divided into several
>> radio packets that is sent separately over the air.
>
> This probably won't work, transparent mode has a packetization
> threshold (it accumulates bytes and then sends them as a packet). You
> can adjust the timing and threshold, but I doubt you'll get that fine
> resolution on it. In fact I doubt 802.15.4 *CAN* get that close
> resolution, since each byte would need a whole radio frame around it.
> Maybe, MAYBE, at low speeds. YMMV a lot. I didn't know when I sent my
> first message that MODBUS had such strict timing constraints.
>
> Chris

While the MODBUS specification states that the message is determined to be complete based on a time delay of 3-1/2 character times after the last byte, many (most?) implementations use other means of determining when the message ends. Depending on how your MODBUS device is implemented you may find that character delays do not affect the result.

-- Bob Ammerman
RAm Systems

2011\01\21@235951 by V G

picon face
On Fri, Jan 21, 2011 at 3:21 PM, Bob Ammerman <KILLspamrvammermanKILLspamspamroadrunner.com>wrote:

> While the MODBUS specification states that the message is determined to be
> complete based on a time delay of 3-1/2 character times after the last
> byte,
> many (most?) implementations use other means of determining when the
> message
> ends. Depending on how your MODBUS device is implemented you may find that
> character delays do not affect the result.


Damn. I really don't want to be modifying protocols at this stage

2011\01\22@054456 by Ruben Jönsson

flavicon
face
> On Fri, Jan 21, 2011 at 3:21 PM, Bob Ammerman <RemoveMErvammermanTakeThisOuTspamroadrunner.com>wrote:
>
> > While the MODBUS specification states that the message is determined to be
> > complete based on a time delay of 3-1/2 character times after the last byte,
> > many (most?) implementations use other means of determining when the message
> > ends. Depending on how your MODBUS device is implemented you may find that
> > character delays do not affect the result.
>
>
> Damn. I really don't want to be modifying protocols at this stage.

Just test it. It may work. If not, then you can start to worry about the protocols.

If you want to go wireless, I think you will have the same issues with any radio module.

/Ruben
==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
spamBeGonerubenspamBeGonespampp.sbbs.se
==============================

2011\01\22@172850 by Bob Ammerman

flavicon
face
> On Fri, Jan 21, 2011 at 3:21 PM, Bob Ammerman
> <TakeThisOuTrvammermanEraseMEspamspam_OUTroadrunner.com>wrote:
>
>> While the MODBUS specification states that the message is determined to
>> be
>> complete based on a time delay of 3-1/2 character times after the last
>> byte,
>> many (most?) implementations use other means of determining when the
>> message
>> ends. Depending on how your MODBUS device is implemented you may find
>> that
>> character delays do not affect the result.
>
>
> Damn. I really don't want to be modifying protocols at this stage.

Did you write the code on both ends of the link?


--- Bob Ammerman
RAm Systems

2011\01\23@002035 by V G

picon face
On Sat, Jan 22, 2011 at 5:28 PM, Bob Ammerman <RemoveMErvammermanspamTakeThisOuTroadrunner.com>wrote:

>  Did you write the code on both ends of the link?


I did not. On the master side, it is some standard MODBUS control software.
On the slave side, I'm using someone else's protocol, but my own code

2011\01\23@175248 by Bob Ammerman

flavicon
face
In this case chances are good that it'll work with random character delays.

-- Bob Ammerman
RAm System

2011\01\23@180237 by Bob Ammerman

flavicon
face
whoops, trimmed too much context....

VG was describing the provenance of his Modbus implementations.

----- Original Message ----- From: "Bob Ammerman" <rvammermanEraseMEspam.....roadrunner.com>
To: "Microcontroller discussion list - Public." <EraseMEpiclistspammit.edu>
Sent: Sunday, January 23, 2011 5:52 PM
Subject: Re: [EE] MODBUS over XBee


> In this case chances are good that it'll work with random character
> delays.
>
> -- Bob Ammerman
> RAm Systems
> -

2011\01\24@020033 by Ruben Jönsson

flavicon
face
> whoops, trimmed too much context....
>
> VG was describing the provenance of his Modbus implementations.
>
> {Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2011 , 2012 only
- Today
- New search...