LabVIEW Modbus API error handling

[patufet_99]

Hello,

in the LabVIEW Modbus API Master example there is no error handling.

Is there some function or method to explicitly check the status of the communication In case of communication interruption, Modbus Server restart or other modbus error,?

Should that be done by parsing the error codes if any when one read/writes registers and then re-trying the connection?

Thank you for your help.

 

 

[Ryan.Sheppard]

You might be better off asking this on the NI forums or the Github page for the library. I believe the NI Systems Engineering team supports the library.

[jacobson]

I see two general classes of errors. The underlying communication is just TCP/VISA primitives so, in many cases, the API will just throw standard connection errors (error 56). For specific Modbus protocol error codes (ILLEGAL DATA VALUE) should also be thrown as errors and look to have the value -389110 - ErrorCode.

Now what exactly you do with those errors is up to you.

[smithd]

On 9/5/2019 at 9:21 AM, patufet_99 said:

Hello,

in the LabVIEW Modbus API Master example there is no error handling.

Is there some function or method to explicitly check the status of the communication In case of communication interruption, Modbus Server restart or other modbus error,?

Should that be done by parsing the error codes if any when one read/writes registers and then re-trying the connection?

Thank you for your help.

 

 

Labview doesn't provide a way to check the status of the TCP connection except by trying to use it. Serial modbus has no physical way to check the connection except by using it. In both cases you need to use it to see if it still works.

On the master (client) side you will see any of the TCP error codes (56, 62 and 63 being the most common as I recall) for the TCP master. For serial masters, you will only ever see 56. I suppose some VISA-specific codes are also possible, like if there are parity bit errors or if you're using a usb-serial device that gets unplugged, that sort of stuff. Modbus protocol errors are - 389110  as mentioned above.

On the slave (server) side you will never see an error from the data access methods because the access is local. You can check (via a property node, I think) on the status of all connected masters (clients) for TCP. Serial is 1-1 and has no concept of a connection, so I think it just tells you the last error to occur for the serial comms process.

[Jedie]

Hi,

Just a question here. I have created Action Engines using the Modbus API from VI Package Manager and I have place those AE created in templates such as a QMH,  however I have been troubled by this error which keep occuring , how do I resolve this error in particular Error 538179, it occured at Transmission Data Unit.lv.class: Write ADU Packet.vi.180211. This error often occurs at Initialisation State whenever I plug my AE into  Is there any way to recover from the Error or resolve it? I have attached my AE in the message here, uploaded it using LabVIEW 2013 Version

Appreciate any help or advice given here. 

 

Thank you.

 

AE CURRENT TRANSDUCER X3 03 Folder.zip

Edited December 26, 2019 by Jed Ong

[smithd]

Cross post is here:

https://forums.ni.com/t5/LabVIEW/Errror-538179-Modbus-TCP-IP/td-p/3999197/page/2?profile.language=en

StephenD in that thread is correct. I don't have labview installed here, but the error literally just means that you are using the base class for something. The base class has no implementation, so I added an error which says "hey you just tried to do something with an uninitialized, dead base class". I added this error message because I think I had a case structure where I accidentally selected "use default if unwired" and so that case structure was returning an uninitialized parent object.

Other situations to look for:

• Uninitialized shift register (ie action engine) used before initialized
• Pass object through a for loop without using shift registers -- if the for loop executes 0 times the output will be a dead parent object
• case structures as described above
• diagram disable structures you forgot to wire through

You should be able to probe your code (turn on 'retain wire values') and you should see a point somewhere that the initialized object gets invalidated. Or you could put breakpoints in your action engine cases and see if one of the error cases is called prior to the modbus object being initialized.

As a general statement I don't use action engines/fgvs because I find them to be confusing to manage, but then labview objects are also confusing to manage. The modbus master object is internally reference based and the wire can be safely branched. I would typically not do this either -- I'd have a single loop which talks to a device and is responsible for writing data to that device or reading data from that device.