NI LabVIEW Modbus API Discussion

[smithd]

Icebaer--the older version's issue is that it rails the CPU (normal priority) in an attempt to detect the edges of the modbus packets, because modbus RTU doesnt have start or end bits.

Error 60 means the port is in use for TCP. The way the code is written, it should release the port fairly quickly after you press the stop button. However, as an asynchronous process LabVIEW will not immediately command it to exit, so I had to add that in myself and it takes time (another polling mechanism and I wanted it to be efficient). This is why you see the different behavior between restarting the master (works) and restarting the slave (will eventually work). I figured this was acceptable because in normal operation, a daemon should not stop. However I didn't take the case of test into account.

[smithd]

Hey Perhult,

I notice at the end of the trace you seem to be reinitializing the port over and over again. Are you re-opening the modbus master on a regular basis here, or is something else going on?

I looked around the line you mentioned but I do not see an error. There are a few normal warnings, but no timeouts that I can tell. However I looked earlier in the file and did see timeouts. Interestingly it is an actual visa timeout. This could mean a few different things:
Data is being lost on the wire.

The library is incorrectly calculating the end of a packet for some reason and attempting to read past that point--so data actually isn't available.

...probably something else.

Anyway, I'll keep poking around and let you know what I discover.

Thanks,

Daniel

[perhult]

I have designed the application so if there is an error I try to close and reinitialize the communication. But with this error it never succedes so the program keeps closing and reopening (I guess I should put a counter there to only try a couple of times before shutting down)

And that is why I know the error is just before where I start to reinitalize over and over.

Thats correct, no error in the trace a that time, only in the program. I never notice the earlier timeouts in my program.

[samsharp99]

Just thought I'd pop on to say that I used this toolkit to read some data from an Ethernet DAQ Device (ADAM-6017) and it was very easy to use - no more difficult than using DAQmx etc. This is only the second time I've needed to communicate with a MODBUS device and I used the old library (over serial) the first time around and it was nowhere near as intuitive as this new library!

Thanks!

[smithd]

Hey Sam,

I'm glad to hear it .

Hey All,

I've been doing some testing with the NI USB serial adapter--which I assume behaves similarly to third-party usb->serial adatpers--and I've seen pretty significant issues with it and the library currently posted. Please take a peek at the following post,which might help, but I wanted to also provide the result of my investigations here, separately.

Basically, USB to serial converters do not seem to operate in a manner that ensures proper operation of the modbus protocol. RTU requires silence on the serial line in order to recognize a data packet, and technically a wait time between characters of more than 1.5 character times indicates a transmit failure (11 bits*1000 ms*1.5/baud<2 ms for 9600 baud). I added in pretty significant wait timers (>5 character times) into serial read code and I was still able to see gaps in data sets when transferring between a usb laptop and a compactrio target. At present, I am inclined to blame the converter because <emulated com port> to <emulated com port> comms work perfectly and cRIO to cRIO works perfectly, but there may be something I am missing. The code also worked well when baud rate was bumped up to the much faster 19,200 baud.

Hi Perhult,

Sorry for the radio silence. I think the following post should be able to help with your situation, but its hard to be sure.

In your program that has a timeout, does it always consistently time out on the same request? What is the data? I ask because it sounds like my assessment was correct, which means that the crc or lrc may be wrong, or, as described above, the serial protocol is indicating a failure.

Thanks,

Daniel

[smithd]

Hi All,

Attached is a new preliminary build of this API. I am looking for people to try out the code, particularly the serial portion.

Basically, what changed is how serial works. Originally, the code was intended to be interoperable between transports (serial, tcp) and protocols (TCP, serial RTU, serial ASCII). In reality, it is impossible for a serial protocol to run over TCP because modbus did not include data length in the packet header until the TCP packet was introduced. This version of the library utilizes this gap to look for data in a less dynamic way. Each serial protocol type (RTU vs ASCII) now has a connection handler. In addition, the serial protocol code was modified to talk to that handler, rather than the port itself. The end result is that there is now a process handling the VISA session while all your user code actually does is read or write from a queue.

The tl;dr version of all this is that the serial code is much better and much more tweakable in the case of errors.

My hope is that some of you nice people out there can try the code, let me know how it works, and let me know if this is the right direction for the API to move. I know that my test hardware now works, but you guys have real-world applications and thats what actually needs to work

Thanks,

Daniel

[perhult]

Smithd>> My setup is communication with 115.2 kBaud, two different units (differents addresses), I read four holding registers over and over for each unit, the same command all the time.

Sounds good, I would like to test the new version. Unfortunately I lost network connection to my remote equipment so for the time being I am not able to access it. I will test when I get it working again!

[smithd]

Hi Perhult,

What I was trying to get a better idea of is if its possible for your data to be the same every time you got a timeout. If the crc is wrong and the data is the same, that could be the source of the issue. It is, admittedly, kind of grasping but I didn't have any better idea at the time. One check you could do is see if the data coming from your sensors is usually pretty close just before the timeout.

That having been said I read through your posts again and something else occurred to me when I read the whole sequence. You have two devices. Are you using a multi-drop connection and changing the unit ID? Do you have a representative screenshot which shows how you configured the devices? What I'm specifically trying to get to is this--is there any chance the two devices are talking on a single visa port at the same time?

Thanks,

Daniel

[perhult]

Hi smithd,

Hard to say in that case since I never get that last measurement with wrong CRC. But I think it is unlikely for the data to be exactly the same since I am fetching data from very accuracte pressure transducers and the physical pressure is constantly changing. But then again I fetch data quite fast, so over a certain time I suppose it could be the same.

Yes, I have two devices with multidrop with a single VISA port. See the attached vi, this the part that handels the modbus communication (sorry for the ugly wiring, but I think you can follow it).

I have not used the "Set Unit ID", maybe my approach is incorrect?

Instead I created two masters, but they should not be talking simultaneously. Actually I think I tried with one master and the Set Unit ID but I never got it to work, do not remember why, I could have been due to some other reason.

[smithd]

That code looks OK as long as the port configurations work, but the set unit ID function really should work as well. Because labview classes are by reference you should be able to create one master instance (which creates a single lock on the core visa reference), split the wire and set unit IDs correctly on each wire, then bundle those reference into an array and call your request in a for loop...but thats unnecessary. You're totally right, what you're doing should work.

Is there ever a particular read which causes issues? Ie, is it always the second read or always the first? It looks like you have the timeouts set to 500 ms for both reads and writes--does the error go away if you use the default timeouts (admittedly the default is a ridiculously long 5 seconds, but...).