LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

shared variable bound to Modbus i/o not working in deployed executable

Solved!
Go to solution

I am building an executable which uses controls, bound to shared variables, which are aliased to registers of a Modbus tcp i/o server defined within the project. I am on Labview 2017sp1 32bit, DSC, windows 10 Enterprise 2016.

 

Now, on the development machine my program works as expected. The build specification for the exe deploys the right variable library. The controls show green triangle and mirror the registers of my modbus slave device. That holds both for the VI run in the IDE and for the built exe. 

 

I then want to port the executable to a deployment PC, installing only the application and the required RT engines. For that I have an installer build specification in the project. I took care of tagging the following additional installers: DSC runtime 2017, all LabVIEW runtime 2017, Variable Engine 2017.

 

On the deployment machine, the controls still show green triangles, but don't reflect the Modbus registers. I'm pretty sure I've taken care of usual firewall issues and of restart of the variable engine. I also exclude network problems, because direct modbus communication works in other labview executables, using the Plasmionique toolkit, on the deployment machine.

 

An additional piece of information is that the NI Distributed System manager, launched on the development PC, sees the shared variables of the deployment PC. However, while standard shared variables there are alive, can be set and change, those aliased to modbus remain "No known value" and cannot even be set.

 

What could I be still missing?

 

0 Kudos
Message 1 of 4
(4,509 Views)

Adding more information. I managed to install the NI Distributed System Manager also on the deployment machine, and I see that when the executable is launched the shared variables are deployed, but not the Modbus server they are bound to. On the development machine instead, it is regularly deployed. This explains the observed behavior.

A further confirmation that something is missing is that right clicking in the NI-DSM I would be able to create a new i/o server on the dev PC, but not on the target.

SystemManager_2018-06-27_16-44-05.png

However, this still doesn't tell me what I'm missing. In the installer build specification I'm tagging all installers which look relevant, that is NI-DSM 2017, NI-DSC runtime 2017, the whole LabVIEW runtime 2017, and NI Variable Engine 2017.

LabVIEW_2018-06-27_16-35-48.png

I wasn't able to find on the NI site any indication of possible missing installers. I thought at DSC on the target machine, but that would install only on top of a LabVIEW IDE.

What then? In the meantime I upgraded to 2017 SP1f3, but that didn't help.

0 Kudos
Message 2 of 4
(4,472 Views)

Or is it a licensing issue, like this and this and this suggest? But then, how to activate on a target which is both offline and missing the NI license manager? [we have here a blanket campus licence and DSC is part of it, is DSC runtime any different?]

Or a case for Enhanced DSC support? But I don't see any such option in my build specifications. And according to this, Enhanced does not work in LV2017, one needs DSC runtime. But where to get it then?

I wish someone could clarify....

0 Kudos
Message 3 of 4
(4,467 Views)
Solution
Accepted by topic author Enrico_Segre

For those running into the issue. The official answer I got from NI, is that the DSC runtime installer included by the Application builder provides only a subset of the functionality of the true DSC runtime engine. Only the latter supports Modbus servers, but it is sold separately and distributed on separate media. I still don't get what "Enhanced" implies and in what LV version.

My workaround has been to install LV IDE + DSC module on the deployment PC, even though I only run executables there.

Message 4 of 4
(4,389 Views)