Showing results for 
Search instead for 
Did you mean: 

Errror 538179 Modbus TCP/IP

Go to solution

Hi guys,

Would like to seek your help here.  I have attached the codes as reference. When I call the action engine in a while loop, the VI occasionally works and run a Variable Speed Drive Set, however, it has been giving me problems recently with Error 538179, could anyone advise on this issue.


Thank you.

0 Kudos
Message 1 of 13

Error 538179 is "The object used has been invalidated. A method was called on an interface class." So either you are not creating the modbus master, or you are closing it then passing the default modbus instance out to the shift register and not initializing it again before running one of the other commands.


Some other notes on your code, you are storing the error on an uninitialized shift register without any way of clearing it so once you hit an error it will always persist and I don't think any of the other functions called will do anything with an error in. Modbus over TCP doesn't care about the unit id, so setting it to 0 (which is also a little weird) doesn't matter. And lastly you have a lot of coercion dots on your block diagram. Keep in mind that a modbus register is a U16 so trying to get a double out of one register seems odd. 

Message 2 of 13

Hi Steven,

Thanks for the suggestion. In this case, I am using an action engine hence an uninitialized shift register is needed for the error checking. The Modbus Instance is passed using the shift registers, hence it will be stored and passed to the next case when called. The coercion dots can be fixed, with no issue on it, with a conversion to U16 in the Function Palette. I am using the AE to call in my main VI the TLB. I am thinking that the reference portion in the shift registers could be a cause of this issue whenever I call it, any suggestion to circumvent this issue?


0 Kudos
Message 3 of 13
Accepted by topic author cyongjed

Well like I said you are getting that error because either you have not created the master modbus instance before trying another command or you have closed it and the unwired tunnel is passing out the default (invalid) modbus instance. How are you using the action engine? Is it possible that it is being closed somewhere before you are finished with it? Is it possible that you are trying to run one of the other commands before initializing it?


Keeping the error on the shift register is ok, but you need some way to deal with it. I would clear any errors in the initialize case before trying to make a new modbus master so it will at least try. Something like this

Annotation 2019-12-12 103807.png


Message 4 of 13


Thanks, Steve for your suggestion. Appreciate the help provided here.

0 Kudos
Message 5 of 13

Hi guys,

I am facing some issue here when plugging the Action Engines using Modbus API from the NI Modbus Library into a TLB Template. The program either gives me Run-Time Errors, Error 56 or Error 538179. This happens quite often when I plug in the Action Engine that I configure for a Temperature Sensor or for the DAQ Reading from a current transducer using Modbus TCP/IP or Modbus RTU. I have attached my Action Engines used in the Message together with screenshots of how I plug in my Action Engines, lastly with one Error Screenshot that happened. Appreciate any suggestions given here or improvements that I could make to the AE to prevent this. Thank you.




0 Kudos
Message 6 of 13

Hi cyongjed,


Again, I think this is a timing issue where your action engine is closing before you are done with the modbus instance or isn't getting initialized before being used to read or write data. It would help if you could upload your "Main VI for" to see how those action engines are used.

0 Kudos
Message 7 of 13

Hi Steven,

Appreciate the help given. I uploaded a zip file with a state transition diagram for your reference...Do let me know if you need previous version for LabVIEW as I am currently using LabVIEW 2019... Thank you...

0 Kudos
Message 8 of 13

Hi Steven,

Earlier when I asked about this, you replied with the Clear Error Part suggestion which I had implemented but after a few rounds of testing out the Main Code Functionality, the problem emerged again for other connections to the other Data Acquisition Device, Adam 6017 Module, for the Modbus TCP/IP Devices or it happens with the Temperature Sensor using Modbus RTU which I linked up using USB. I have connected all via a Network Switch. 

The Device Configured is with the following IP as you see in the Main Code,

Adam DAQ:

VSD 1:


I was thinking could it be the timeout for the configuration of the Modbus Initialisation Part??? Because I have allocated Initialise DAQ Case, Initialise Temperature Sensor and plug the Action Engine in it, with the state control of Initialise each respectively as shown in the State Transition Diagram. When I testing out the functionality of the Main VI, from what I observe in the program by turning on the Highlight Execution or by running normally, it pinpoints to the AE in either of these cases I listed out and LabVIEW stops due to the error which occurred...

0 Kudos
Message 9 of 13

Timeout could certainly be a problem. All of your other action engines have the same problem, if they get any error they have no way to recover. I personally like to put hardware in their own loops controlled by a queue so that if there is some communication problem they don't hang the rest of the program and they can also have their own logic for how to deal with errors. 


I've been looking over your program for a few minutes now and have some suggestions. It seems a bit rube goldbergian to me (overly complicated). There is a lot of logic in the second loop that is hard to follow. Seems like a lot of that can be dealt with by deleting the "Action Queue". That queue is only used within one loop and I don't really see the purpose of it. I would get rid of it and just deal with what it does with case structures and/or sub vis. 


One other thing of note is that you have a couple places where you have free running loops that are the only time certain controls are valid. Is there a reason those controls are only valid for 5 seconds? Those loops also lock up the program and are not throttled at all (greedy loop!)

Annotation 2019-12-24 100449.pngAnnotation 2019-12-24 100504.png

0 Kudos
Message 10 of 13