-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include VISA-TCP for Modbus-RTU #3
Comments
I hadn't though of that use case. The responses don't include the data address. So without the transaction ID there is no way of checking if the returned data actually belongs to the last request. |
Thanks for the quick reply. I think that is something the developer has to take care of, e.g. it is often possible to allow only on TCP-connection on such a converter. The usage within one programm instance should be save as read/write is encapsulated within one VI (please correct me if I'm wrong here). My recent experience with the change depicted: It works out wonderful. The TCP-to-RS232 converter (or to be exact, it is an converter to RS485 with 4 modbus units connected in serial) is set to transfer all bytes sent or received ASAP. |
I have experienced this shuffled response behavior within a single program instance with a single master communicating with a single slave. If you have a bad Ethernet connection, transaction ID becomes very important. See: #1 I wouldn't recommend TCP-to-RS232 like this unless: |
Now I understand your concerns. In my current use-case the ethernet cables are really short and I do not have any EMI problems. So up to now I never had the issue that you discribe - perhaps also because I always switch between my 4 modbus-clients with different addresses - this can be distinguished by the protocol. |
Hi,
this is a feature request: I recently needed to connect to a Modbus-RTU device that is installed behind a TCP-to-RS232 converter. The installation of a virtual COM-port (often offered with these kind of converters) has been no valid option since the connection is issued from a cRIO.
My solution: usage of a TCP-VISA connection by defining my VISA-port as TCPIP::IP-Address::Port::SOCKET
I needed to make only one adjustment in your API in the VI "Open Serial Session.vi"
Please consider to add this to your API
Regards, Jens
EDIT: Changed the screenshot.
The text was updated successfully, but these errors were encountered: