07-09-2018 11:57 AM
Just a quick update in case someone wants to look into this. I will keep digging and testing, but here is what I found:
Adding a shift register did not remedy the issue. So, I did some testing with a different program that reads a register from my PLC over Modbus TCP and it works as intended. I then decided to setup my vi to run the identical setup at the same speed, same parameter, and same amount of reads and it faults out on the 256th read. I am by no means well versed in Modbus TCP, but is there some sort of transaction ID rollover in the "read holding register.vi"?
I can post the wireshark snippets of both labview and the other program if requested, but I noticed the other program rolls over the transaction ID after 511 transactions. The Labview program rolls over after 255. What is driving this? Is the PLC looking for the next transaction to be 256 but Labview sends out ID# 0 and that mismatch is causing a fault?
Please advise.
07-10-2018 09:10 AM - edited 07-10-2018 09:11 AM
The server (slave) is supposed to just copy the transaction ID of the request into it's response. The value of the transaction ID is only validated by the client (master). It shouldn't matter that the transaction IDs are rolling over.
I might be interesting to try the latest version (v1.3.2) of the Plasmionique Modbus Master library. The transaction ID for each message is a random number between 0x0000 and 0xFFFF.
https://lavag.org/files/file/286-plasmionique-modbus-master/
07-10-2018 09:37 AM
@Porter wrote:
The server (slave) is supposed to just copy the transaction ID of the request into it's response. The value of the transaction ID is only validated by the client (master). It shouldn't matter that the transaction IDs are rolling over.
I might be interesting to try the latest version (v1.3.2) of the Plasmionique Modbus Master library. The transaction ID for each message is a random number between 0x0000 and 0xFFFF.
https://lavag.org/files/file/286-plasmionique-modbus-master/
Porter,
Thanks for that link as I've been doing some initial testing with the Plasmionique Modbus Master Library and no errors yet. I'm still curious why I was seeing these issues with the other Modbus Library, but for now this has allowed me to continue moving forward with my project.
07-10-2018 02:33 PM
Hi. I'm trying to connect to an Acuvim power meter with the Modbus library serial master, and I have repeatedly been getting "Error 56 occured at RTU Data Unit.lvclass:Read ADU Packet.vi: 5030001". I am using library version 1.2.1.42. Reading through earlier posts in this discussion, it looked like this is a timeout error? I've tried using the propriety monitoring software and it connects and communicates perfectly fine and quickly. I'm using the Modbus Master Example.vi program to attempt to connect. Any advice on how to get past this error?
07-10-2018 02:37 PM
Is it always the same error? How quickly are you sampling the Acuvim? I've run into troubles when sampling at subsecond levels with Acuvims.
07-10-2018 02:44 PM
Yes, it's always this same error. I'm currently using the Master Example vi, so I'm pretty sure it's only sampling when I press the "Read holding registers" button. I'm pretty new to labview though so I could be wrong
07-10-2018 03:02 PM
I made an example VI for you - try using it and see if the error persists. It simply opens the connection, reads 2 holding registers, then closes the connection.
1. Make sure the IP address is correct
2. Make sure the register number is correct. The constant in the VI is already set to display in hexadecimal form. Refer to the device manual for the location of specific registers for frequency/voltage etc.
07-11-2018 07:29 AM
I'm receiving a different error now: Error 59. This is a TCP connection though. I'm trying to communicate with it through a serial connection via this RS485 adapter. I've attached the VI which I had been using before
07-11-2018 09:09 PM
If you can save it for LabVIEW 2016 I can have a look, or post a screenshot.
Do you get any valid data at all? Or does the error persist over time?
07-16-2018 07:44 AM
My apologies for such a delayed response. The error occurs immediately after trying to read holding registers, and I've been unable to get any data at all. It connects and communicates correctly with Acuview proprietary software, leading me to believe my problem is somewhere with the labview code. Here is a screenshot of the connection code