topic Re : Modbus problems with multiple clients in LabVIEW

Modbus problems with multiple clients

ChrisSp — Fri, 16 Apr 2010 14:31:34 GMT

I am having a problem communicating with a Modbus Server in a multiple client, serial network. I don't have the DSC module installed, so I'm using the modbus library. When I run the vi without any other clients the program runs fine, but it appears that when the network is 'flooded' with Modbus data, the Visa read function is not fast enough to recognize the slave address. This results in a very slow response, or even a complete loss of data flow.

Any help would be appreciated!

Chris

L.V. 8.6.1

OS Win XP

Re: Modbus problems with multiple clients

pincpanter — Fri, 16 Apr 2010 15:15:15 GMT

Having multiple clients in a serial network is a bad idea, unless the clients can perform a correct time sharing by means of an external clock. Concurrent access to the server may corrupt requests of all clients. If you can, you should move the server to an external node, building for example an Ethernet network instead of a serial one. The network server only would communicate with the Modbus device and dispatch requests from the clients.

Re: Modbus problems with multiple clients

unclebump — Fri, 16 Apr 2010 19:50:08 GMT

are you saying that you have multiple master devices on the serial network. or multiple slave devices and one master device?? What type of serial network?? rs232, rs485 multidrop, two wire or four wire rs485?? Are you polling all of the devices for info or using a broadcast mode where data is continuously transmitted?? How many devices and what baud rate are you using?? RTU mode or ASCII mode?? RTU mode will use half the characters. The VISA read function needs to wait for complete modbus data packets, either by calculating ahead of time how many bytes to receive, or waiting for a termination character.

The slave address should be contained in a full modbus data packet. I would recommend recalculating the modbus command checksum inside your labview code and comparing it to the checksum inside the data packet. This way you guarantee data integrity.

Re: Modbus problems with multiple clients

ChrisSp — Mon, 26 Apr 2010 11:14:50 GMT

Thank you for your reply, I was out of the office for a while...

Unfortunately the system's setup doesn't allow me to change to ethernet. I do agree Modbus IP is a lot easier to work with.

Re: Modbus problems with multiple clients

ChrisSp — Mon, 26 Apr 2010 12:29:24 GMT

The system consists of 17 slaves and a single master. My computer is one of those slaves. The network type is 2 wire RS485, RTU mode. I'm trying to use the Modbus Slave VI that comes with the Modbus Library. I have used it before, but only as a master. It seems the "MB Serial Recieve.vi" in the Deamon cannot detect the correct slave address, slowing the process.

When I ignore the slave address, it seems to work just fine, a bit slow perhaps. Still this is not the solution...

Perhaps anyone else ran into a simulair problem?

Re: Modbus problems with multiple clients

RavensFan — Mon, 26 Apr 2010 14:41:38 GMT

The slave daemon seems to be able to set the slave address. But the Serial slave example has a slave address of 1 hardcoded in it and sets the control value for the slave address in the daemon to that value of 1. (Look in frame 4 of the stacked sequence structure in the serial slave example.)

Not a real good example since it hard codes that. You may want to change that constant to match yours, or even turn the constant into a control.

Re: Modbus problems with multiple clients

unclebump — Mon, 26 Apr 2010 14:52:09 GMT

Back in the days of using modicon P190's to program plc's, we always used address 1 for the programming ports. When we started modbus plus networking plc's, this caused some issues with electricians getting into the wrong plc and modifying programs. So we made a rule to not allow any networked plc programming port to have address 1. Serial port still had address 1 for local programming and no bridge mode programming was allowed. You definitely don't want the slave daemon to be hard coded. NI should release a new version that corrects this implementation.

Re: Modbus problems with multiple clients

ChrisSp — Tue, 27 Apr 2010 10:52:13 GMT

Thank you for your posts!

Perhaps I'm using some other library, but I can't seem to find this hardcoded 1...

This is the one I am using: http://sine.ni.com/devzone/cda/epd/p/id/4756

The slave address is used in MB serial receive.vi, in frame 'no error', '0', '0', 'default'.

Re: Modbus problems with multiple clients

pincpanter — Wed, 28 Apr 2010 10:54:07 GMT

As Ravens Fans wrote, check MB Serial Example Slave.vi, frame 4, where a constant value 1 is assigned to the Slave Address control of the daemon vi.

You can assign another value, or better load the address from an ini file.

Re: Modbus problems with multiple clients

ChrisSp — Wed, 12 May 2010 10:55:40 GMT

I must have already spotted it before I got myself tangled up in this mess... Anyway the CPU load seems abnormally high (over 50%)when I run the 'MB Serial Slave Demon.vi' even without anything connected to my COM port. Perhaps I'm looking in the wrong direction?

Re: Modbus problems with multiple clients

pincpanter — Wed, 12 May 2010 12:03:05 GMT

With just the daemon running in LabVIEW development environment I got 1% CPU load only.

Re : Modbus problems with multiple clients

samapico — Tue, 21 Jun 2011 18:38:27 GMT

I have a similar issue... I think I tracked down the problem, and I'm surprised no one has noticed it yet.

In MB Serial Receive.vi, it reads the buffer byte by byte. When it finds a byte that matches its slave address (or 0, for broadcasts), it starts to read other bytes, until it has a message with a matching CRC. Basically, the only thing that delimits the end of a message is the CRC.

Thing is, if the master sends a message to another slave, or if a slave replies to the master, and that message happens to contain a byte that matches this slave address, it will try to read a message from that byte. But it will never get a matching CRC, so it will eventually timeout.

What it SHOULD do: Even if the message is addressed to another slave, read it until you find a CRC match, but don't process it.

Example:

Slave1 is a device, Slave2 is a labview app using this library.

Master -> Slave1: 01 ... CRC1

Slave1 -> Master: 01 ... 02 ... CRC2 (at this point, Slave2 reads "02 ... CRC2", but CRC2 doesn't match because it didn't start the right time. So it keeps reading until it times out)

Master -> Slave2: 02 ... CRC3

(Slave2 probably has something like "02 ... CRC2 02 ... CRC3" in its message at this point, but it still waits for more bytes to make a valid CRC)

Re : Modbus problems with multiple clients

ChrisSp — Wed, 22 Jun 2011 07:31:56 GMT

You are right, it does time out whenever it sees a number that matches a slave address. The modbus RTU timeout does not seem to be correctly calculated either (1.5 characters). However I don't know how to improve this serial slave, without consuming a tremendous amount of CPU.

Re : Modbus problems with multiple clients

samapico — Tue, 16 Aug 2011 20:17:41 GMT

I tried fixing the problem by having the slave listen to all messages, even those not addressed to him, and stop listening once it finds a matching CRC.

But I thought: "What if 2 bytes in a message happen to match the CRC of the previous bytes? Bleh, that'll never happen..."

I tested: The master first sends a msg to slave 1, slave 1 replies. (LabVIEW is slave 2) That very first reply... was:

01 10 07 D6 00 01 E1 45

The CRC-16 of that msg is 0, obviously, but the CRC-16 of this message is also 0: (according to MB CRC-16.vi, anyway)

01 10 07 D6 00 01 E1

So it stopped listening after "E1", and considered "45 ... <whatever the next message was>" to be a message intended to slave #45(hex).

So the only way out of this is to effectively detect the end of a message by detecting a "silence" of at least 3.5 characters... I have no idea how to modify the current code for that, though.

Re : Modbus problems with multiple clients

unclebump — Tue, 16 Aug 2011 20:46:38 GMT

One way around that might be to send a fixed numbers of registers to the slave each time. This way the number of bytes should be consistent between messages. Then you could wait until the bytes at port reached that value. Then read the data and decode the modbus info. Recalculate the CRC inside labview code to verify it matches the CRC in the message. Might be helpful to use an opc server as a slave on a computer. Then use portmon to watch the data transfer to see how it is handled.

Re : Modbus problems with multiple clients

samapico — Tue, 16 Aug 2011 20:51:11 GMT

The problem is with messages that are addressed to OTHER slaves on the bus (and their replies to the master). I have no control over the content of these messages. Well, we can control the master, but it has to send specific messages to the other device it communicates with.

And as said earlier, if I just ignore these messages (like the code was doing in the first place), there's no way to know when a message should start.

Re : Modbus problems with multiple clients

ChrisSp — Wed, 17 Aug 2011 07:07:28 GMT

The timing seems to be the key. First the message needs to be buffered, in an array, 1 character per index. Knowing the BaudRate, you can calculate the '3.5 character time' and maybe determine the message's start and end. Then look for the correct slave nr. and CRC.

Re : Modbus problems with multiple clients

samapico — Wed, 17 Aug 2011 13:27:33 GMT

I just stumbled on this:

http://iatips.com/modbus_rtu.html#char35

It basically suggests that you can know the length of each message, depending on the function, instead of using a strict 3.5 chars timeout.

Re : Modbus problems with multiple clients

ChrisSp — Wed, 17 Aug 2011 14:20:26 GMT

After reading this article, I agree that network switches etc. (for Modbus IP) or other factors might influence the 3.5 char pause.

However this would mean rewriting the existing Modbus slave, having to process each byte that is read, look for a slave nr, length, then calculate full message lenght, and then check CRC.

Re : Modbus problems with multiple clients

samapico — Wed, 17 Aug 2011 14:33:40 GMT

Yep... exactly...

I'm already knee deep in MB Serial Receive.vi, so I guess I'll give it a try.

If anyone has a better suggestion for debugging it: I had to plant a named notifier in there to throw out some strings that I can read from my test program 😕 I think the VI is dynamically called, and has to be reentrant, so I couldn't figure out how to probe wires in there.