NI LabVIEW Modbus API Discussion

[MarcosBelgo]

Hi friends, anyone already used micrologix 1400 with this library? I have some questions:
I already configured the micrologix 1400 to talk through the ethernet port, but, how can I test the comunication? First, I use a CREATE NEW INSTANCE.VI - NEW TCP MASTER with the IP of my PLC. But, error 56 is showed. The PLC ping normally on the prompt.....

Thanks..

[MarcusTörndahl]

Hi, I have run into a timeout problem (Error 56) when setting up Modbus RTU communication to a device on the RS485-port on the NI cRIO-9030. The error explanation I get is:

Error 56 occurred at SubVIs.lvlib:RTU Data Unit.lvclass:Read ADU Packet.vi:5030001

Possible reason(s):

LabVIEW: The network operation exceeded the user-specified or system time limit.

I am running LabVIEW 2014 with the DSC-, Real-Time-module and the latest Modbus API drivers v1.1.5.39 (https://forums.ni.com/t5/NI-Labs-Toolkits/LabVIEW-Modbus-API/ta-p/3524019) installed. I have tested both the drivers from within the DSC/Real-Time module and the Modbus API driver but I get the same error. 

One thing to point out is that I am using the same driver (from DSC/Real-Time-module) to communicate to a device using Modbus TP without any problem. 

I have also attached a small sample of code (as a snippet) which I have used when debugging the problem.

[Shehzaada]

Hello SmithD, 

I've got a peculiar situation that I'd love to get yours and everyone's feedback on.

I've set up a laptop and two power quality meters and they are all on the same network. I'm querying the meters in two seperate loops using NI MODBUS library. The code works absolutely fine with Meter A (success rate > 99 %), however, in Meter B I have a success rate of only 50-60%. The meters are the same make and model, and I'm sampling them every 10 seconds over MODBUS TCP.

The error I get most often is 538170, which after reading some of your responses, suggests that the master and slave are out of sync. Power cycling the device has no effect - I'll get 3 good readings, then an error, then 2 good readings, then another error.

I'm a bit confused as to how to troubleshoot this setup. I've tried running one meter at a time, using the datalogger provided by the meter company, and see similar results. Any advice would be appreciated!

PS: I've just tried running the datalogging software provided by the company and my LabVIEW code at the same time and the success rate is up to almost 80% on Meter B. Both are using MODBUS TCP. Do you think this is helping somehow with the 'out of sync' issue? 

[MatthieuMag]

Dear all,

I have an issue communicating with a eurotherm 3504 temperature controller configured in modbus TCP. I manage to get the connection, but only for a limited time, after which I get an error 56, with the following message indicated at the end of this post.

Setup:

- Windows 10 - 64bits

- labview 2017-64bits

- modbus API 1.1.5.39 toolkit from here

The computer and the eurotherm are connected with a cross-over ethernet cable for the connection.

The computer has a two ethernet cards, one of which is used for the communication with the eurotherm with a fixed IP.

I have attached an example file for testing, the vi request the current PV (register address #1) from the eurotherm. The error doesn't always come after the same amount of time, nor does it seem to depend on the acquisition time. I have tried to reinitialize the tcp connection at each iteration or every so many iterations, it doesn't help.

Could it come from too high of a latency of the instrument or something else?

Would really appreciate any help.

IP Data Unit.lvclass:Read ADU Packet.vi:5030001<APPEND>

<b>Complete call chain:</b>
     IP Data Unit.lvclass:Read ADU Packet.vi:5030001
     Modbus Master.lvclass:Read Holding Registers.vi:2420001

[MarcusTörndahl]

Hi MatthieuMag,

To be able to debug what is the root cause of your timeout (error 56) problem, could you post your code or a sample of it?

I find it some what strange utilizing two ethernet cards, so I need to ask what is the purpose?

Best regards,

Marcus

[MarcusTörndahl]

..

[MatthieuMag]

Hi Marcus,

Thanks for your answer, is it sufficient to add it right after the opening of the TCP connection, as in the picture of the diagram attached (I'm testing this right now)?

I'm not too familiar with neither the modbus protocols nor the API though I've read quite a bit about it since I've had to setup communication with that eurotherm. If the lack of this call is the problem, then I don't understand why it would work without that for some time and then shut down every so often.

As for the ethernet cards, there are have been two on the computer we're using from the start. We're then using one for our network and one with a fixed IP to communicate with the eurotherm, there could be an issue in the setup of the cards in fact, but I haven't found anything there yet.

Thanks,

Matthieu

[MatthieuMag]

Update:

I still get the same error, though I may not have correctly implemented the definition of the unit.

I guess it was also working before because there is only one eurotherm, so one unit to control and to talk to.

Any idea?

[sup_SE]

Hi Matthieu,

I believe the Unit ID in modbus TCP is really used to identify the appropriate slave unit when a modbu Ethernet - Serial  hub is used. In a fully Ethernet network, the IP address itself is the unique destination identifier for a modbus TCP packet.

I noticed that you are not really using the modbus TCP connection you opened in the rest of the VI chain! So, I would recommend the following steps:

1. Use the modbus TCP connection you opened (refer to my diagram)

2. Remove the Unit ID node (refer to my diagram)

3. I believe there should be some setting in the Eurotherm 3504 device Ethernet parameters to select how the Unit ID should be treated for modbus TCP (If I remember right, the settings are Strict, Fixed etc..). Make sure this setting is not changed. The default setting I believe is such that the 3504 responds only to Unit ID 255 (which is the default unit ID when a Modbus TCP connection is opened in LabVIEW)

4. Try the VI for a single read first (without the loop). If successful, then add the loop.

5. If single read is not successful, try with the 'read input registers function' instead of the 'read holding registers' function.

Also, remember, if your 3504 goes into config mode/ restarts during the period when you are talking to it via LabVIEW, you will have to reopen the TCP master connection (as the socket will be dropped)

Thanks and Regards,

Supreeth

[Supreeth.K]

Hi Matthieu,

I believe the Unit ID in modbus TCP is really used to identify the appropriate slave unit when a modbu Ethernet - Serial  hub is used. In a fully Ethernet network, the IP address itself is the unique destination identifier for a modbus TCP packet.

I noticed that you are not really using the modbus TCP connection you opened in the rest of the VI chain! So, I would recommend the following steps:

1. Use the modbus TCP connection you opened (refer to my diagram)

2. Remove the Unit ID node (refer to my diagram)

3. I believe there should be some setting in the Eurotherm 3504 device Ethernet parameters to select how the Unit ID should be treated for modbus TCP (If I remember right, the settings are Strict, Fixed etc..). Make sure this setting is not changed. The default setting I believe is such that the 3504 responds only to Unit ID 255 (which is the default unit ID when a Modbus TCP connection is opened in LabVIEW)

4. Try the VI for a single read first (without the loop). If successful, then add the loop.

5. If single read is not successful, try with the 'read input registers function' instead of the 'read holding registers' function.

Also, remember, if your 3504 goes into config mode/ restarts during the period when you are talking to it via LabVIEW, you will have to reopen the TCP master connection (as the socket will be dropped)

Thanks and Regards,

Supreeth