Generate Target Includes crashed Labview 2017 32bit

[bdiesel]

Trying to generate Target Includes crashes labview.  I was trying to add a UI module to monitor the values on the tag bus, and could not generate the Target Includes.  Now, having removed the UI module, labview is still crashing.

Some further information:

Creating a new dcaf config with:

- single Boolean tag

- dds module that writes to that tag

- Modbus module that reads that tag

- UI to display current value of tag

When generating Includes - LabVIEW crashes as per screen shot attached.

Further update - creating a new config, with dds, Modbus, cvt, but without ui, does not crash LabVIEW.  It appears that the combination of UI and DDS causes the crash.

[MattP]

I tried this on my 2017 machine, and was able to generate a new target includes file from that config both with and without a UI Reference module included.  

Can you post a screenshot of your VIPM installed packages, filtered to show DCAF packages?  This will let us know if there might be a version mismatch we're not aware of.

[bdiesel]

Hi Matt,

Screenshot is attached.  

Further updates on the behaviour.  It appears to be caused when I generate the includes for a second time after having added a module.  I have just had it crash when I added a CVT module (without UI module in the config).

So, current pattern I believe is happening:

1. Set up a clean dcaf config, with dds and modbus and others (e.g. UI or CVT) Target Includes generates fine.

2. work on the code.

3. Add another module in to dcaf config (has happened with UI and CVT) and try to regen included -> crash.  

4. Unable to roll back at all - even if I try to roll back to previous dcaf config file using git.

5. Write a new dcaf_config file from scratch.  Generate target includes, then rename new dcaf config file to original so engine can run,

Bruce

[Jacobson-ni]

If you haven't already try to use a new, blank, VI for your includes file. I've gotten into states where the includes generation crashes (seems to be after package updates/installs) and starting from scratch has worked for me.

[MattP]

Hi Bruce,

So far, still unable to reproduce.  I've tried the following:

Open your config.

Generate includes (new file - "original").  No crash.

Add UI module.  

Generate includes (new file - "UI").  No crash.

Generate includes (overwrite "original" file).  No crash.

Add CVT module.

Generate includes (new file - "CVT").  No crash.

Generate includes (overwrite "original" file).  No crash.

Generate includes (overwrite "UI" file).  No crash.

Tried above sequence both with and without saving the .pcfg file after adding modules, no difference.

Might be more related to your "work on the code" step than anything else.

An easy way to test if it is scripting related is to manually drop the runtime class constant for each of the modules you use into a blank VI and see which one it crashes on.

[MattP]

I also know the DDS module's dependency (the RTI DDS package) likes to be installed with VIPM running with admin privileges.  You might consider closing out of LabVIEW, launching VIPM as admin, uninstalling and reinstalling the RTI DDS package. 

[bdiesel]

---

@MattP wrote:

Hi Bruce,

So far, still unable to reproduce.  I've tried the following:

Open your config.

Generate includes (new file - "original").  No crash.

Add UI module.  

Generate includes (new file - "UI").  No crash.

Generate includes (overwrite "original" file).  No crash.

Add CVT module.

Generate includes (new file - "CVT").  No crash.

Generate includes (overwrite "original" file).  No crash.

Generate includes (overwrite "UI" file).  No crash.

Tried above sequence both with and without saving the .pcfg file after adding modules, no difference.

Might be more related to your "work on the code" step than anything else.

An easy way to test if it is scripting related is to manually drop the runtime class constant for each of the modules you use into a blank VI and see which one it crashes on.

---

Okay, attached is a zipped up project which is causing my labview to crash.  Maybe that will enable you to recreate it?

[bdiesel]

---

@MattP wrote:

I also know the DDS module's dependency (the RTI DDS package) likes to be installed with VIPM running with admin privileges.  You might consider closing out of LabVIEW, launching VIPM as admin, uninstalling and reinstalling the RTI DDS package. 

---

I'll try that.  Although I have had no problems working with DDS outside of DCAF.

[bdiesel]

---

@Jacobson-ni wrote:

If you haven't already try to use a new, blank, VI for your includes file. I've gotten into states where the includes generation crashes (seems to be after package updates/installs) and starting from scratch has worked for me.

---

I have tried that, unfirtunately it didn't help.

[Jacobson-ni]

---

@bdiesel wrote:

Okay, attached is a zipped up project which is causing my labview to crash.  Maybe that will enable you to recreate it?

---

My LabVIEW does crash using your project but only if I attempt to script pointing at the Target Includes.vi when it is open. If the VI is not opened or if I point it to Host Module Includes.vi which is blank things seem to be happy.

I also noticed that when you start scripting the file, the VI pops up with the three green arrows showing that the VI is open in multiple application instances. If I remember correctly, VIs run from the tools menu are not in the normal LabVIEW application instance so I tried launching the editor not from the tools menu but from "C:\Program Files (x86)\National Instruments\LabVIEW 2017\vi.lib\NI\DCAF\Tag Editor Core\Standard Editor", and I didn't have LabVIEW crash on me when I did this.

Edit: Open is probably not the best term. If the VI or project is open LabVIEW will crash. If I just open the DCAF Editor, it will not crash on me.