NI LabVIEW Modbus API Discussion

[xtabi2]

Hi,

I'm using the ni_lib_modbus_library-1.1.2.29.vip package you posted. I don't know if anyone else has this problem, but I'm running Labview 2013 on Windows 8 and notice a fairly constant 10-12ms of delay coming from either Labview or Windows before bytes are even placed into the read buffer. I noticed that you doubled the standard 3.5 char wait time, I assume to try and get around this issue. Could you make that character timeout in ms a parameter you can set in the Create Serial Master.vi? That way the developer can adjust the characters or constant ms to best fit their system.

By the way, this is a great package. Really appricate all the hard work.

Thanks,

David

[smithd]

ShinaBaba wrote:

Hi Smith,

I figured out what the problem is, it is a time out issue from my device, I changed the  read response timeout configuration on my gateway and this solved the problem.

Thanks,

Regards,

Shina

Glad to hear it worked out. Thanks.

[smithd]

xtabi2 wrote:

Hi,

I'm using the ni_lib_modbus_library-1.1.2.29.vip package you posted. I don't know if anyone else has this problem, but I'm running Labview 2013 on Windows 8 and notice a fairly constant 10-12ms of delay coming from either Labview or Windows before bytes are even placed into the read buffer. I noticed that you doubled the standard 3.5 char wait time, I assume to try and get around this issue. Could you make that character timeout in ms a parameter you can set in the Create Serial Master.vi? That way the developer can adjust the characters or constant ms to best fit their system.

By the way, this is a great package. Really appricate all the hard work.

Thanks,

David

Hey David,

You are correct that I extended that wait time, due to the issues I described in this thread with usb-serial converters. This is likely what accounts for your long wait time. The other part of it will be the fact that I always wait--something I realize now that I should change. There is a road block to this whole situation with RTU performance.

Specifically, I am experiencing significant issues on LinuxRT with similar symptoms to the issues I saw with vxworks and usb-to-serial which caused me to up the wait time. In my "read" function I poll the "bytes at port" property repeatedly to detect when the serial port stops recieving data. What I was seeing with the USB-to-Serial was a fairly short split in the data--only a few extra ms here or there--which caused me to jump to the conclusion that it was the fault of the packetization on the usb converter (plus I read this on a few websites--but of course this could also be conjecture from everyone else). With two 9068 systems connected directly together I am seeing a significant gap in the data set--as much as 50 ms. Given that my entire data set should transfer in under 20 ms at 9600 baud this is a pretty serious issue and I am investigating with R&D to find the appropriate workaround. It may be that I simply need to break the protocol abstraction for serial RTU and "guess" the correct data length. I believe I said previously in this thread that I'm really not a fan of this, but it may be the only solution.

Besides this issue, I'm a bit wary about exposing the wait as a parameter for two reasons:

-First, it is technically not standards compliant. Since I am breaking the standard slightly anyway I guess its not too big of a deal.

-Second, I am full up on connector pane inputs on the modbus serial slave constructor. I could simply say that only serial masters can set this parameter, but since slaves and masters both run the same code thats not a great solution. I also can't easily change the connector pane without messing up the large amount of code already running with the current connector pane (although I suppose there is significantly more TCP than serial, so it might just be that I need to take the risk. Or I could add another constructor which exposes it, but just hide it from the user. Or I could simply add a global and people can set it if they so desire. Tons of options, just none of them fantastic. Do you have any thoughts on what you would prefer as the correct solution?

Thanks,

Daniel

[xtabi2]

Thanks for getting back to me. I didn't even think about the usb to serial causing the delay, but that makes perfect sense.  I've run into similar serial communication issues trying to get various advantech and our own instrumentation to communicate. I see your concerns with adding the extra parameter.  I wouldn't worry about adhering to the Modbus character timeout standard. In my expereince it is rare it actually equates to 3.5 characters and if you can figure out how to expose that as an input then it's on the developer to conform to the standard or not.

Could you add a parameter to your transmission data unit class to be character timeout in ms. Add it as an optional parameter in the Set Timeouts.vi. And then make that an output in Read read operation timeout.vi

If you can do this you could set the default as 0 and specify that if 0 is passed in the Read ADU packet.vi will compute the timeout based on baud rate otherwise it will use the value given. You could do that functionality in your Get 3.5 char times.vi. Is any of that possible or make sense?

Thanks,

David

[matteci]

Hello Smithd:

Thanks for your work on this. I am using your library to communicate to some RS485 devices as well as an HMI over ethernet from a 9068 (Acting as serial master, TCP slave). I have made a gateway-like vi which reads registers from the 485 devices and passes them along to TCP registers. To do this I have setup multiple TCP slaves using TCP ports 502 for controller data, 503 for modbus data from 485 device 1, and 504 for modbus data from 485 device 2. These three ports are for the same ip address on the same ethernet device.

485 communication is reliable, but I am having difficulty getting the TCP connections to relaibly connect to the HMI. Looking at TCP connection count for each of the three tcp slaves, they will sometimes connect and sometimes not, in random configurations. If I stop and restart my RT application I get a different one connecting each time, and sometimes I'm lucky and get them all to connect.

I have tried making an error case, in which if I have no connection count I shutdown the instance and then try to recreate one, but this does not work to reconnect. The only thing which works is stopping and restarting the RT toplevel vi. I have also tried making sure that the three create tcp slave vis are executed sequentially by wiring the error lead through them with no difference made.

I did finally wire an error indicator to the daemon error property node terminal and see error 60 when this occurs. I saw that earlier in this thread but didn't understand your answer... do I need to wait longer after shutdown before trying to reconnect? How can I force LV to release the TCP port?

I'm sure I'm doing something wrong but can't figure out what. Any advice would be greatly appreciated.

[smithd]

Hey Matteci,

I'm not sure I understand everything you're trying to accomplish, but let me start with what I do know. The reason you are seeing that behavior with the TCP slaves is that (in my mind), a TCP slave should never need to be shut down. Basically the slave is a state machine which has to wait on two asynchronous inputs--rather than creating two parallel loops, I compressed it into a single loop and the check-for-shutdown case only executes every once in a while (multiple seconds, I think 3 or 5). Thus when you call the shutdown function, it is really sending a message to another process and that process may take as long as 5 seconds to get its act together and shut itself down. For TCP, each connection has a loop and all loops share the same notification, so they should release the port in roughly 5 seconds. However, depending on the situation the ports may enter a time-wait state (http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/). This is more severe of a problem in a situation like this where the server (modbus slave) uses a fixed port (502). The end result of all this is that (a) you may be recreating the slave before the original shuts down, so port 502 is already in use OR (b) the slave has shut down but the port entered a time-wait state, meaning that from LabVIEWs point of view the port is still in use. Both cases lea to error 60.

So, this gets us to the parts I am not clear on. If I am understanding correctly, we really need to nail down two issues:

(1)-Making sure TCP comms work correctly

(2)-Making sure you are accomplishing your goal in the best way possible given the API

For (1), I think I need more information from you. How is your code configured? Can you share some pieces of the code or a diagram to clarify the situation?

For (2), I need to have a better grasp of your goals. For example, if you want to just make a gateway then it makes sense (potentially) to share data models across multiple slaves, or to create a network component which forwards messages from one device to another. If you are happy with the current solution this isn't necessary, but I don't want you to reinvent the wheel if its something easy to do in the code.

Thanks,

Daniel

[smithd]

xtabi2 wrote:

Thanks for getting back to me. I didn't even think about the usb to serial causing the delay, but that makes perfect sense.  I've run into similar serial communication issues trying to get various advantech and our own instrumentation to communicate. I see your concerns with adding the extra parameter.  I wouldn't worry about adhering to the Modbus character timeout standard. In my expereince it is rare it actually equates to 3.5 characters and if you can figure out how to expose that as an input then it's on the developer to conform to the standard or not.

Could you add a parameter to your transmission data unit class to be character timeout in ms. Add it as an optional parameter in the Set Timeouts.vi. And then make that an output in Read read operation timeout.vi

If you can do this you could set the default as 0 and specify that if 0 is passed in the Read ADU packet.vi will compute the timeout based on baud rate otherwise it will use the value given. You could do that functionality in your Get 3.5 char times.vi. Is any of that possible or make sense?

Thanks,

David

Yes, that makes sense. I'd like to avoid changing it for now, though, until I get the entire serial situation resolved. It may be, as I mentioned before, that I need to rewrite the state machine again. For now you should be able to modify the VI yourself locally, and then I'll provide an update once I have a resolution. My hope is that its this week.

Thanks,

Daniel

[xtabi2]

Sounds great. I'll keep an eye out for the update. And thanks again for putting this package out, it's very impressive.

David

[Jozo]

Hey smithd

im using Modbus Master Example.vi for communication with Modbus slave simulator between 2 serial ports interconnected through 2 USB2RS485 converters on my PC (because i dont have PLC yet).

Communication is working with following problem:

I cannot get rid of this error (Error 56 occurred at RTU Data Unit.lvclass:Read ADU Packet.vi:5030001)

Do you have any suggestions?

Thanks,

Joz

[Varun_ECK]

Hello Smithd

Is it possible to Read/Write more than 125 registers? If not then is there any way out ?

Thanks in Advance

Varun Garg