modbus-example for receive

[maji]

hi

i have a Device that send me data with MODBUS (serial modbus) 

i need a simple example ( for LV8.61) for receive data from it.

please help me.

[RavensFan]

Have you seen the Modbus library for LabVIEW?  It has example VI's in there as well.

You will need to provide a little more detail for your application.  What is the device you are talking to?  Is it a slave or does it behave as a master?

Devices don't just send data with Modbus.  The modbus protocol is set up as a master/slave relationship.  One part of the network is the master.  It sends commands to the individual slaves on the network.  Commands can be read or write for "coils" (meaning booleans), holding registers, input registers, multiple coils, multiple registers, ...  It is always in a query/response manner.

[clohars]

I have the same problem EVEN with the examples running from the LabView library (as a master).

I am using a Simeas P50 (as a slave) from Siemens on a 9600/no parity/RTU/COM1 setting (note that COM1 is the only com port I have on the pc, so no messing up there).

So I'm am trying to get to read some registers on which I know what information there is (ID, date of calibration, etc), to begin with.

The thing is that I get some values that make no sense what so ever. and for consecutive registers I get consecutive readings. For example:

register 40040 (1 quantity) *data:     9C 68 00 01 9E 46 01 84 01

                                          *register 26624   414   17921   33793

register 40041 (1 quantity) *data:     9C 69 00 01 CF 86 01 84 01

                                          *register 26880   463   34305   33793

register 40042 (1 quantity) *data:     9C 6A 00 01 3F 86 01 84 01

                                          *register 27136   319   17921   33793

Note that  in these registers I'm supposted to have a 03, a 10 and a 02 (in this or a reverse order. I'm having trouble seeing that, so any help is most welcome.

Also, I'm using a RS232 to RS 485 powered cable for all of this.

Adrian

Message Edited by clohars on 11-17-2009 09:12 AM

[clohars]

Message Edited by clohars on 11-17-2009 09:10 AM

[RavensFan]

Are you sure you are requesting the correct register?  Although the register looks like 40,040, the initial 4 is dropped.  So you are actually looking for register 40 in addressing that begins with 1.  And usually in LabVIEW, that means you have to reguest address 39, since the communication protocol address begins with 0.

[clohars]

Yes, I'm sure.

I tried a trial version of another software (http://www.calta.com/) and i get the information I expect of the 40040 register (by the way, the number of this register is provided by the Simeas P50 producer, so it is the correct one - www.siemens.com.tr/i/assets/content/.../simeas-p/simeas_p_1456259.pdf).

This is what i get on the calta thing: TX: 01 03 9c 67 00 03 9a 44 (Written data)

                              and the reply is RX: 01 03 06 30 33 31 30 30 32 bb a7 (Read data)       

Note that in register 40041 i get d12339 which is 30 33, in 40042 i get d12592 which is 31 30, and finally in 40043 i get d12338 which is 30 32.

So, if one takes the 3s as separators one can read  031002 which is exactlly what I am looking for.

Now, my issue is that with LV, and using the same setting and 'spying' with the same serial monitor, i get the following traffic:

written data: 01 03 9c 67 00 03 9a 44

    read data: 01 03 9c 67 00 03 9a 44 01 03 06 30 33 31 30 30  32 bb a7   ..œg..šD...031002»§

 So, you see, LV makes up the correct request, and receives the correct answer BUT  it gets a copy of the request before that. So my guess is that this is the problem all together.

And...if it tries to 'recover' the registry after the 3rd byte (which would be 06) it gets on its request, and not on its answer.

...I am anywhere close? any help with this one?

Note that what I use right now is a VI I got from http://zone.ni.com/devzone/cda/epd/p/id/6153#0requirements. Is it incomplete? (previously one may see a 9c 67 which is 40039, but i took care of that, and even if i request a 40040, the VI subtracts 1, after my alteration of it, to compensate -  this goes to answer the actual question I'm replying 🙂 )

Adrian

[RavensFan]

---

clohars wrote:

Yes, I'm sure.

I tried a trial version of another software (http://www.calta.com/) and i get the information I expect of the 40040 register (by the way, the number of this register is provided by the Simeas P50 producer, so it is the correct one - www.siemens.com.tr/i/assets/content/.../simeas-p/simeas_p_1456259.pdf).

This is what i get on the calta thing: TX: 01 03 9c 67 00 03 9a 44 (Written data)

                              and the reply is RX: 01 03 06 30 33 31 30 30 32 bb a7 (Read data)       

Note that in register 40041 i get d12339 which is 30 33, in 40042 i get d12592 which is 31 30, and finally in 40043 i get d12338 which is 30 32.

So, if one takes the 3s as separators one can read  031002 which is exactlly what I am looking for.

Now, my issue is that with LV, and using the same setting and 'spying' with the same serial monitor, i get the following traffic:

written data: 01 03 9c 67 00 03 9a 44

    read data: 01 03 9c 67 00 03 9a 44 01 03 06 30 33 31 30 30  32 bb a7   ..œg..šD...031002»§

 So, you see, LV makes up the correct request, and receives the correct answer BUT  it gets a copy of the request before that. So my guess is that this is the problem all together.

And...if it tries to 'recover' the registry after the 3rd byte (which would be 06) it gets on its request, and not on its answer.

...I am anywhere close? any help with this one?

Note that what I use right now is a VI I got from http://zone.ni.com/devzone/cda/epd/p/id/6153#0requirements. Is it incomplete? (previously one may see a 9c 67 which is 40039, but i took care of that, and even if i request a 40040, the VI subtracts 1, after my alteration of it, to compensate -  this goes to answer the actual question I'm replying 🙂 )

Adrian

---

It sounds like you are handling the addressing correctly, and since it sounds like you are getting the data you expect in the reply, then the register addresses don't seem to be your problem.

Yes, it definitely looks like you are getting an echo back of the original request, and the Modbus library wasn't designed to handle that as far as I know.  What are you using to communicate with the server?  Is it a PC, or a device like a compact Fieldpoint, or something else?  Are you using RS-232 or RS-485?  And if it is RS-485, is it 2-wire or 4-wire?

Does the device have some setting that can be turned on or off that tells it whether to echo back the orignal request?

I know that with some of NI's devices that are RS-485, (like a cFP controller), they are intended for 4-wire communication.  You can use 2-wire, but you wind up with the transmitted data also showing up on the receive lines of the serial port.  They say you will have to use special code to handle that situation.

The answers to the above questions will help determine what is the best way to handle this.

That example you linked to seems to be complete.  But I think there is an even better example (or at least is has more LV code shown in it) in the NI Modbus palette called MB  Serial Example Master.vi

[clohars]

Thanks for the answer, first of all.

I use a PC as the master device. And the cable uses a  'R232 to R485' converter ( the R232 connects to the computer and the R485 to the device).

This is the converter on the producer web page http://www.wut.de/e-86000-ww-daus-000.php?a=86000&b=0 so it's a RS485 4-wire.

And I've looked everywhere but I don't find any reference about the echo situation. So my guess is that there is no option on the device for that.

About the VI you indicated, actually that's what I'm working on right now, and I'm taking it step by step to try to follow the information flow through it. So, at this moment I'm in MB Serial Master (Example).vi Block Diagram->outer sequence on 1, inner sequence on 0->MB Serial Master Query.vi(clone) Block Diagram->MB Serial Receive.vi (clone) Block Diagram->outer sequence to 2-> MD Serial String to Modbus Data Unit.vi

.. I know it's a bit of a long of a path, but if you're into looking it up, please do! So, this is as far I got into this programming, and my guess now that this is where I need to tackle it, because I provide the query string and the outputs seem wrong (wrong slave adress and wrong function code).

As a side note, even 'forcing' these values to the correct ones, the output here tends to be somewhat large (20 byte for the Modbus Data Unit). But at this point I'll put up with anything, as long as it works 🙂

 So, I've worked on both VIs (MB  Serial Example Master.vi and the ModBus Example.vi), and they look kind of similar to me, if not identical at times (I think that from the MB Serial Master Query.vi inward they're the same).

thanks in advance for any answer,

Adrian

[RavensFan]

The link you sent does have some mention of echoing characters in the manual http://www.wut.de/pdf/e-86000-ww-prus-000.pdf on page 4 paragraphs 3.2 and 3.3.  Although the titles of those paragraphs are a little ambiguous and might only apply to the 2-wire RS-485 control.

You might even want to try a different brand of RS-232/485 convertor to see if that changes anything.  I've used this one successfully http://www.bb-elec.com/bb-elec/literature/4WSD9TB_2605ds.pdf, but my applications have been 2-wire based.  It has an explicit DIP switch for echoing.

I think your best bet is to figure out why its echoing the command and try to eliminate that.

If you want to do it in software, I'd recommend making a backup of the NI modbus library under a different name before modifying it.  I drilled down through the path you gave.  I think that frame you pointed to would be the right place to correct the incoming data.  If you were to take the Modbus command string that was written, possibly by passing the string out of the Modbus Write VI through a new connector, pass it into the Modbus Read VI through a new connector.  You could do a search of the incoming string on the Modbus read and do a Match pattern with the command string to eliminate it and only return the data after that.  Then you could pass that remaining string into the MB serial string to MB data unit.vi.

It would basically require small modifications to MB Serial master query and MB Serial Transmit, and a bigger modification to MB Serial Receive.

Message Edited by Ravens Fan on 11-19-2009 04:09 PM

[clohars]

Switching to some other piece of hardware may be out of the question. I had a hard time getting what I have here, and I will have to work with this one.

So I'll explore the sofware aproach for now. I'll let you know how's that coming up.

Once again thanks for the answer 🙂

Adrian