modbus RTU vis RS485 timeout error 6101.

[Uzair90]

Hello All,

I have a code which basically communicates with around 20 devices using an RS-485 network. The devices include:

1. https://www.automationdirect.com/adc/Shopping/Catalog/Process_Control_-a-_Measurement/Temperature_-z...

2. https://www.laurels.com/products/search.php?modelnumbers=L80104FR

The code takes measurements from all of those devices plots them on a graph which get updated every couple of minutes or so and then broadcasts this VI on a webpage. We have a wireless network setup then through which we can view the webpage from any other computer on the network.

Both of which support modbus communication. At the computer which contains the labview I use a USB 2.0 to RS485 converter to connect it to the USB port.

The code was written in LabView 2011 and I recently transferred to a new computer which contains LabView 2013. The NI Libraries that I am using are: NI VISA 16, NI Modbus 1.2.1, Internet ToolKit 2012.

Right now I keep getting this timeout error (error code 6101) and I can't seem to figure out why. The stop bits are set to 2 in the code and also in the devices. The communication mode is through RTU and parity is set to none. Baud Rate is 9600.

I have checked my serial connection by running a manufacturer software for SOLO 4848 temperature controllers. I can speak to them through that software but not through my own code.

I have attached my VIs and project here. The main VI is the ara2.vi

[RavensFan]

Did your code work before?

It sounds like you changed two things.  The PC it worked on, and the version of LabVIEW.  I don't think changing the LabVIEW version would've caused your code to start timing out.  So I'm thinking it is something about the PC or the way the com ports are set up in the PC.

PS:  When you auto-index on an array, you do not need to wire the array size function to the N terminal of a for loop.

[Uzair90]

Thanks for the reply RavensFan!

The problem is that I did not write or run this code before on the previous machine. The code was last run 3 years ago and the guy who wrote the code left the collaboration and is working somewhere else now. The people who ran the code told me it used to run fine except at random times it would restart and cause the counters to also restart for some odd reason. One of the guys here thinks that might have been due to memory being filled up of the previous machine but he is not sure. The previous machine got backed up and disposed of so I don't have access to it right now

I just saw this code for the first time a couple of days ago and I have never done serial communication or such complex coding in Labview before. I have worked with DAQ assistants and write to measurement files VIs and made graphs and waveforms and at maximum used instruments which had the Plug-n-Play feature but I am new to everything about this code. Can you please guide me on how should I go to debug this code or fix it?

I also want to understand how to work with Modbus VIs in Labview. On the other threads I have seen here people use VISA VIs instead of the modbus ones and I can't seem to make the connection between the two.

I also did the serial loopback test today on my USB to RS485 adaptor and it seems to work fine. So there is nothing wrong with the serial communication.

[RavensFan · Accepted solution]

Check NI for newer libraries.

There is this link for version 1.2.1.  http://www.ni.com/example/29756/en/

But there is also a link to a newer version in there https://forums.ni.com/t5/NI-Labs-Toolkits/LabVIEW-Modbus-API/ta-p/3524019

If you have the Data Supervisory Control Module (DSC), it comes with another set of Modbus VI's.

The Modbus libraries are based on VISA, they just encapsulate all of the structuring of the data commands and responses so you don't have to.

Double check all of the settings for the serial port.  If your LabVIEW code doesn't explicitly set something like the baud rate or stop bits to what you need, then it relies on the VISA settings in MAX, or even go back to the settings in Windows device manager.  So perhaps a "default" serial port setting is being used and it is set differently on the new PC compared to the old.

One other thing I remember.  I've been using the older versions of the library, that have evolved to the 1.2.1 version library.  I remember that the VI that initializes the serial communications hard coded some of the serial port settings in it (I think the stop bits) that did not match the device I was working with.  So I did not use that subVI and just used a regular VISA Serial Port Configure to explicitly set all of the serial parameters to what I needed.  Something to look into.  It probably wouldn't explain your situation because if parameters are hard coded in and worked before, I'd expect them to work now.

[Uzair90]

I got it running but now there is another error coming up.

It was not a library issue. Just to let you know I have the library that you showed me in the first link and the one in the second link does not install in my computer. The VI package manager says that for some reason (which it does not tell me ) its not compatible with my OS or LabView.

So I went to check out the properties in MAX and also in Windows control panel. In both the places the stop bits were put as 1 whereas in my case all the devices have stop bits 2. After correcting this that error disappeared.

Now the erroe that is coming up is about the Shared variables.

Hex 0x8BBB0005 Unable to locate the shared variable in the Shared Variable Engine (SVE). Deployment of this shared variable may have failed, the SVE has not started or SVE is too busy to respond to this request.

This error or warning occurred while reading the following Shared Variable:

\\MyComputer\aracgi\cgi_tracedata

\\192.168.1.119\aracgi\cgi_tracedata

My libraries seem to deploy. And I also tried manually deploying them which was fine but I got the same error. My firewall is completely shut off right now.

I read this link : http://digital.ni.com/public.nsf/allkb/A12707C3AA00F5598625737C0066D4F6?OpenDocument

I can't seem to get my head around what is DCOM or what is OPC and how would it be related to the code I am working on. Can you guide me on how can I debug this issue?

I think it might have something to do with copy pasting of the code from the old to the new machine where the cgi path might somehow have been messed up. But I am not sure.

[Uzair90]

Thank you Ravens Fan!

The shared variable engine error was due to some strange reason. Somehow the SVE had stopped and I had to manually start it off again.

For anyone who comes into this post:

1. Go to MAX and check your port setting.

2. Go to Control Panel and check your COM port settings

3. Go Inside the ModBus Init.vi and manually set the stop bits to whatever you are using. Even if you set correctly at the port settings you still have to set inside the Modbus Init.vi

[RavensFan]

---

@Uzair90 wrote:

For anyone who comes into this post:

3. Go Inside the ModBus Init.vi and manually set the stop bits to whatever you are using. Even if you set correctly at the port settings you still have to set inside the Modbus Init.vi

---

I'm glad to hear you've got it working for you.

But I don't recommend your tip #3.  Why?  Because you are modifying a VI that is part of a library.  That setting may not work for you on a different project on a different device.  And if you later get a new PC with a new LV installation and a newly installed Modbus library, you won't have those changes you just made.

The best solution is to not use the MB Init.  Just build directly in your VI the settings that you need using Serial Configure VI.  You can open up the MB Init to see what they are doing, but don't modify it.  Just duplicate what you need and fix what you need and put it in your own VI.

[Uzair90]

I do agree with you that RavensFan. I just did not have alot of to reprogram the whole thing so I just went with just making it work for now. Although I do plan to modify it later.

Also I am having one more problem now regarding shared shared variables and Internet toolkit CGI interface which I have posted on another thread over here:

https://forums.ni.com/t5/LabVIEW/HTML-table-does-not-show-up-on-webpage/m-p/3678282

Can you check that out and see if you can help me out in any way over there?

Thanks again!

[Uzair90]

Hello RavensFan!

I just had another question for you. I wanted to switch all of the modbus VIs from this code to the ones that are available from the newer modbus libraries. ( https://forums.ni.com/t5/NI-Labs-Toolkits/LabVIEW-Modbus-API/ta-p/3524019 )

If I do this everything stays pretty much the same except the way I initialise the modbus connection. In the newer libraries when you initialise the Modbus Serial Master you have to provide a unit ID. From what I understand the unit ID is the address of the slave with which you want to communicate with. However in this case since I want the master to communicate with all of my slaves then how would I do that?

Let me know if my question makes sense to you

[smithd]

There are several newer libraries:

• https://forums.ni.com/t5/NI-Labs-Toolkits/LabVIEW-Modbus-API/ta-p/3524019
• The above library was then migrated in to the product and is available for labview RT or DSC. If you have neither, it is fine to use the NI Labs version
• DSC/RT have (for a long time) had a "modbus I/O server" which I can't recommend.
• Because I no longer support the first, and not everyone has the products above, what I recommend to people now is https://lavag.org/files/file/286-plasmionique-modbus-master/ if they only need a master. Porter (the author) is still actively using it and developing it, although sadly his most recent version is v1.2.1, the same # as the very very old library you are using. Also, Porter's implementation is better for serial modbus due to some issues with interaction between a 40 year old specification and modern abstraction layers.

In any case, your question is about talking to all slaves. There are a few ways to do this but you have to be very careful. Fundamentally, modbus is a request response protocol (like your web browser) but with a shared resource (the serial port).

Option 1: Use modbus broadcast (slave ID 0) to tell all slaves to accept data. What if you want to read? Broadcast does not work. When a slave gets a packet with an address of 0, it performs any associated action but does not send a response.

Option 2: Poll through all devices. With the libraries above there are two ways to do this but they both basically end up with the same result, which is an array of modbus master objects which all hold the same NI-VISA reference but with different slave IDs. I'd recommend just using a for loop+property node to copy a single master instance, setting the slave ID for each. The alternative is that you set the slave ID before every write. In any case, you have to be very careful because in fact you have only one serial port, so each master instance talks on the same port even if they appear to be different sessions. This means that you *cannot* branch the wire and call two "read" functions at once. The same restriction is not true of TCP, only serial.

An issue worth noting (technically not a bug) with the first library is that it refuses to allow port settings not in the spec--for example, no parity+1 stop bit. This is not permitted by the specification. I don't recall if Porter kept this same restriction with his library. If you run into this issue, I recommend following ravensfan's suggestion with a tweak: use the normal "create session" function but use a property node to change the port settings right after, before performing any I/O.