i have a large (1700+ VIs) application I'm producing. It works fine in LV2013. in moving to LV2013, I've hit a few snags. One of them, involving PPLs that are used by other PPLs, is solved by discovering that LabVIEW 2017 fixed an issue that I had to work around in LV2013.. Previous problem and solution Now I have another problem. The app is build of several parts. HOST.exe - this is the main part, running on Windows. ADDONS used by host - These are PPLs that the user can compile (in a separate LVPROJ). They get "attached" to the host, by being in a certain folder and operating a command on the host. PPLs used by host only - these are PPLs used by the host or by the addons, which provide data/code common to the host or to the addons. For example, the system configuration data is stored in one of these, and either the host or an addon can register and get notifications if the config has changed in a certain way. RTHOST.rtexe - this is the main program on an RT box (PXI 8196 in my case, others are possible) RT ADDONS - there are PPLS that the user can compile (in a separate LVPROJ). They get "attached" to the RTHOST, at the same time as the corresponding addon gets attached to the windows host. PPLS used by RTHOST ONLY - these are PPLs used on the RT box to share data/code between the RTHOST and the RT Addons. Similar to the Windows host above. COMMON PPLS - these are functions common to both the Windows host and the RT host. Common utilities such as circular buffer management, formatting text strings, TCP Transceivers, etc. Generic stuff. Altogether there are 25-30 PPLs built by my process. I haven't worked on the RT side in LV2017 yet, because I've had so much trouble with the host side. In LV 2013, as long as I followed two simple rules, I had no trouble building anything: 1--- Dependencies go only BACKWARD. If B depends on A then A has to be built first. No problem. 2--- if a PPL has something that is Windows-Only (like a function dealing with menus), then you cannot use that PPL on the RT side. If a PPL has RT-ONLY content you cannot use ANYTHING in that PPL from Windows. That's because LabVIEW must load an entire PPL at a time - if anything is broken, the PPL is unusable. To make that happen, I separated PPLs into the groups above. I "certified" that certain ones are RT-safe, and that means that they are usable on BOTH Windows and RT. As part of the "certification" process, I built the dual-use PPLs using the RT side of my projects. (Since I have far more Windows-only stuff than RT-only stuff). In LV2013, the dual-use ones were perfectly capable of being used AS IS, on either side of the fence. The same PPL was deployed in both locations and worked fine. But now, in LV2017, the same build process complains. Some of the PPLs built on the RT side of a project get complained about. LabVIEW reports that they are missing dependencies, yet refuses to tell me what they are. A visual exam shows that nothing in this PPL depends on anything outside of it. A list of VI DEPENDENCIES shows that nothing in this PPL depends on anything outside of it. Yet still, LabVIEW complains that it cannot find some "external dependency". Note that the VIs will all load correctly in the DevSys. It will compile without error. yet you cannot load it anywhere. If I move the LVLIB from the RT side to the MY COMPUTER side of the project, it will compile correctly and NOT complain about such things. Not ALL VIs within one of these will load broken. I haven't discovered a common answer among the broken ones. In one PPL, only one VI is complained about. In another, there are three. It's almost as if there are linkages behind the scenes that are different between RT and the host, and these show up differently between LV2013 and LV2017. I have the host part compiling completely now, having moved some of these from RT to the MY COMPUTER side. My guess is the RT side will screw up when I tackle that. So, is there a better plan to do what I am doing? Should I turn on some new option I haven't figured out? Should I (can I) build two versions (RT and MY COMPUTER) using the same source library? Ideas?

ni.com is currently undergoing scheduled maintenance.

Some services may be unavailable at this time. Please contact us for help or try again later.

LabVIEW

Bring on NXG gmodules eh?

Message 21 of 21

(239 Views)