MB serial receive

[ChrisIncotech]

The LabVIEW free Modbus library includes MB Serial Receive.vi. The first sequence structure in this vi includes the comment "The next subvi that process the whole string basically ignores the serial address for some reason. I guess he assumes that you are only talking to 1 device at a single time"

I am using Modbus RTU over RS485 to communicate to two motor controllers. Either one device at a time works perfectly. Both devices together reads the first and then fails with a 6101 Timeout Error from MB Serial Receive at the second. This would appear to be a known problem, but I can't find any solutions among the many posts that discuss this general fault.

[Alex.T]

Hi ChrisIncotech,

What I can see from the block diagram is that you're performing each step in a sequence, alternating between the reference for each motor you're wishing to interface with. As these VIs are fundamentally based on the NI-VISA VIs, I'd imagine that when you're trying to communicate with two different resources in this fashion the communication buffer is being filled with information from both devices at once. Thanks to your detective work, we can see that these VIs are predisposed to only interact with a single Modbus instance at a time. With this in mind, I believe we could get around this error by performing the full R/W interaction with an individual device and then sequentially perform another full R/W operation with the next device.

My suggestion is as follows:

Current Configuration:

Read Device 1

Read Device 2 <-- Buffer may become filled with irrelevant data.

Write Device 1

Write Device 2

Proposed Configuration:

Read Device 1

Write Device 1

//potential flush

Read Device 2

Write Device 2

The reason I believe that this will help is because the buffers will essentially be emptied of any previous data which is irrelevant to the current motor intended for interaction. If you want to compensate for multiple device talk simultaneously, I would suggest looking at how the Modbus Serial Receive VI has been written and create a similar read which is compatible for multiple data bytes. Some general overhead will be required in terms of how you program your Modbus interface to determine which order bytes of data come from what device.

Something that jumps out at me is that you're performing these Read operations before Write operations. In order to interact with these motors, aren't you required to first Write control information and then Read an appropriate response?

To remove timeouts, you could also try Flushing the VISA Buffer before performing another iteration via use of the 

VISA Flush I/O Buffer VI; this will erase any erroneous left over information. You could also try increasing the VISA timeout value by right clicking on the VISA Resource wire and selecting Create » Property for Instr Class » General Settings » Timeout Value, however judging from the behaviour we've discussed I agree with you in saying that the buffered communication data isn't being handled properly for multi-device communication, which is why it may be worth making use of the potential changes listed above.

Let me know what you think; just please keep in mind that I'm not exactly a Modbus wiz!

[ChrisIncotech]

Thanks for the reply. I am currently modifying the original vis so that I can access what's happening inside them. I will follow your suggestion, but my initial reaction is dubious, simply because Modbus is supposed to be a master-slave relationship which implies that there should be nothing in the read buffer unless I have specifically asked for it.

[Alex.T]

I understand. My point is that currently we're requesting two sets of data to be appended to the communication buffer in the Main VI, however  the Modbus Read VI only searches for a single interaction's worth. Because of this, it eliminates the useful data acquired from the second device. By reading after one interaction, then engaging another, we should be able to avoid this caveat of the VI!

[ChrisIncotech · Accepted solution]

Final post. The problem appears not to be with my LV coding. When I request information from drive 1, all devices on the bus receive the response. My PC can process the response, compile the drive 2 request and transmit it, before drive 2 has recognised that the message from drive 1 is of no interest and delete it. Therefore, my drive 2 request never gets "heard" because drive 2 is still busy removing unwanted stuff from its read buffer. I had intended to control and monitor both drives together, but have now rewritten the code to treat them separately. The root cause is that the drives have a much smaller and slower processor than the controlling PC and don't treat comms as a high priority.

Thanks for being there to bounce ideas off.

[GATTO]

upload it in labview 10 please