Skip to content
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

Open
jgr1969 opened this issue Aug 7, 2020 · 4 comments
Open

Include VISA-TCP for Modbus-RTU #3

jgr1969 opened this issue Aug 7, 2020 · 4 comments

Comments

@jgr1969
Copy link

jgr1969 commented Aug 7, 2020

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"

grafik

Please consider to add this to your API

Regards, Jens

EDIT: Changed the screenshot.

@rfporter
Copy link
Owner

rfporter commented Aug 7, 2020

I hadn't though of that use case.
I can add it, but its not compliant with the modbus standard. Sending modbus serial packets over TCP like this could get you in trouble. There is no transaction ID. Under certain circumstances TCP packets can get received out of order.
Eg.
--> Request IR 1
<-- Timeout
--> Request IR 2
<-- Response IR 1 (Taken as value for IR 2)
<-- Response IR 2 (Ignored)

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.

@jgr1969
Copy link
Author

jgr1969 commented Aug 7, 2020

Thanks for the quick reply.
I think, I understand your concern, the TCP-to-RS232 converter opens the possibility that several Masters can connect to the same slave.

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.

@rfporter
Copy link
Owner

rfporter commented Aug 7, 2020

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:
1- The master is connected directly to the TCP-RS232 converter (no switch or hub in between)
2- The Ethernet cable is short and routed through an area that you would expect low EMI/RFI

@jgr1969
Copy link
Author

jgr1969 commented Aug 10, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants