[Bug?] DSC - Enhanced DSC Run Time Breaks Built Application (Standard Run Time Does Not)

[jgcode]

Hi VTHokie - (lol @Fat Penguin)

The code compiles and runs fine in the standard Run Time Environment - so that fact that it needs more memory is IMHO not that it actually needs more memory.

Including the BD (enable debugging) actually allowed this code to run in the Enhanced DSC Run Time.

Been busy building so haven't had a chance to repair LabVIEW, but its good to hear you have heard of that problem before!

I will need to open a support line on Monday to NI when I am back at work.

But please keep any help coming my way.

[Greg_J]

---

1) Real Time Licensing Issue

I made use of some Real Time Target System Replication functions to create a NI Distributed IO Sniffer.

That work fine in the Standard Run Time.

Using the Enhanced DSC Run Time broke my build, with LabVIEW complaining of Licensing issues:

---

Regarding the apparent issue with RT licensing (above), does this error occur during the build process on the development computer or upon deployment and running your code?

- Greg J

[jgcode]

---

VTHokie wrote

 

Regarding the apparent issue with RT licensing (above), does this error occur during the build process on the development computer or upon deployment and running your code?

- Greg J

---

Hi Greg

It breaks my build - so when I run my executable (which was built without errors) - I get the above error dialog.

[jgcode]

Email from AE has a workaround to (4) to stop the loading screen from happening.

In your ini file, you can include the line: ShowLoadProgressDialog="False"

Sweet! Thanks

So in the Standard Run Time it must be False by default?

As I configure the build spec to use a blank .ini file in both cases.

[jgcode]

From further investigation Point 😎 Run Time Menu Corruption seems to be related to both Run Times.

However when I run the same executable on another machine, it is fine!

This post is on LAVA 

[quote]

John Lokanis: Oh, and every now and then, my IDE will switch from English to Chinese for no apparent reason.

[/quote]

Don't know if it is related? But thought it worth a mention.

[Greg_J]

Great to hear you're knocking them out one-by-one.  Error 1 that I mentioned above seems to point to a problem with the Real-Time Module Deployment License.  While it's not clear why this would change between standard and enhanced DSC run-time, I am still curious if you know the status of your RT deployment license.

Also, could you explain in a bit more detail the specific components you're using that require you to enable the Enhanced DSC Run-Time support... are you using NI_DSC.lvlib;ProcessToLib.vi, NI_DSC.lvlib:SharedVariablesToLib.vi, or any VIs or property/invoke nodes that are dynamically creating shared variables or other project items?  Any specific VIs in the Real-Time Target System Replication that may incorporate them?

Finally, how are you deploying your executable?  Are you creating a custom installer from the Application Builder and including the enhanced DSC development support for LabVIEW, or are you just installing the DSC run-time system to the deployment machine?

- Greg J

[jgcode]

---

@Greg_J wrote:

Great to hear we're knocking them out one-by-one.  Error 1 that I mentioned above seems to point to a problem with the Real-Time Module Deployment License.  While it's not clear why this would change between standard and enhanced DSC run-time, I am still curious if you know the status of your RT deployment license.

Also, could you explain in a bit more detail the components you're using that require you to enable the Enhanced DSC Run-Time support.  Are you using NI_DSC.lvlib:ProcessToLib.vi, NI_DSC.lvlib:SharedVariablesToLib.vi, or any VIs or property/invoke nodes that are dynamically creating shared variables or other project items?

Finally, how are you deploying your executable?  Are you creating a custom installer from the Application Builder?

- Greg J

---

Hi Greg

1) Yes, good news to me too

2) Are you saying that using the RT Library as per my post means I need to buy a Run Time License for each PC I want to install this on?

I have not used RT code in a PC app before, and thus far I have only been building on dev machines (which usually have RT module installed) and have not got to the stage of testing on a clean PC

Are you saying it will break?

If so I would like to know that now rather than later - (time for some more testing).

RE: RT Deploy Licence - What info can I provide you with that would help from my PC?

3) This is what currently confuses me:

I didn't think I used anything like this in the app, and I just did an explicit search on NI_DSC.lvlib:ProcessToLib.vi, NI_DSC.lvlib:SharedVariablesToLib.vi and they are not used.

As a bit of history - this app was put on hold then I have come back to it. We used LV2009, from memory it used to run fine in the Standard Run Time as the other components used are in the DSC Run Time (which the client will have to purchase but I obviously have the DSC Module on dev PC) i.e. writing tracing etc...

Now I have to build it with the Enhanced DSC Run Time option checked or I get error dialogs when I tried to run the exe as per the 7) Miscellaneous Stuff. Anyways the only thing I can think of that would have changed is that I am using LV2009.SP1 now? I don't know if that is relevant? 

I do, do Registering for Shared Variable Events - but that requires a Licenced DSC Run Time not the Enhanced DSC Run Time? Is that correct?

4) At the moment I am testing the build by running it out of the dist folder (i.e. right-click on Project Build Spec >> Run).

But I will be creating an Installer for the final deliverable - I should probably test this to. 

5) I ran out of Edit time on an above post - RE: Run Time Menu corruption:

From further investigation Point 😎 Run Time Menu Corruption seems to be related to both Run Times.

Also this is a post by John Lokanis on LAVA

[quote]Oh, and every now and then, my IDE will switch from English to Chinese for no apparent reason[/quote]

Don't know if it is related? But thought it worth a mention.

If I run the built executable on my PC I get these errors:

If I run the same executable (not rebuilding - just copying it and running it) on another PC then the above is in English.

Repairing LabVIEW did not fix this, this is a weird one.

[jgcode]

Ok, my DSM 2009.SP1 is in Chinese too!

But DSM 2010 is fine?

Must be a 2009.SP1 Run Time thing?

[Greg_J]

While I'm not familiar with what hardware you are deploying your RT code to, all NI Real-Time Targets include a deployment license in the hardware, as seen in the Tutorial: Deployment and Debug Licenses for NI Software

The only reason I brought that up was because it was listed as one of the potential causes of some of the errors that you were seeing.  I think the best piece of information form your PC would be the status of your Real-Time licenses in NI License Manager.  Are both the development and deployment licenses activated?

Also, regarding the run-time menu corruption, you could try backing up the LabVIEW.ini file, moving it to another location temporarily, and seeing if that changes any obscure configuration that could be causing the issue.  Otherwise, if a repair didn't do the trick then a reinstall may be your best bet at this point.

- Greg J

[jgcode]

---

@Greg_J wrote:

While I'm not familiar with what hardware you are deploying your RT code to, all NI Real-Time Targets include a deployment license in the hardware, as seen in the Tutorial: Deployment and Debug Licenses for NI Software

The only reason I brought that up was because it was listed as one of the potential causes of some of the errors that you were seeing.  I think the best piece of information form your PC would be the status of your Real-Time licenses in NI License Manager.  Are both the development and deployment licenses activated?

---

Hi Greg

This thread is about compile issues using the Enhanced DSC Run Time, therefore my target is a standard PC, not a Real-Time target.

I just want to make use of a function I found in a NI Library online to sniff out NI Targets on the network in my PC application.

I checked my NI Licence Manager - I don't have a Debug Deployment licence only a Development licence.

However, the License issue only killed the build in the Enhanced DSC Run Time - not the Standard LabVIEW Run Time.

---

@Greg_J wrote:

Also, regarding the run-time menu corruption, you could try backing up the LabVIEW.ini file, moving it to another location temporarily, and seeing if that changes any obscure configuration that could be causing the issue.  Otherwise, if a repair didn't do the trick then a reinstall may be your best bet at this point.

---

I will give that .ini swap a go (although the run time should not be read it?)

As per my DSM 2009 v 2010 example I think it is a 2009.SP1 Run Time related issue?