DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Module version from 16 to 15

I tried to convert DQMH application with multiple DQMH modules to earlier version(15), unfortunately, i encountered an error(Start module.vi). i doubt if it was caused by my application, so i tried to convert build-in example(DQMH Fundamentals -Thermal Chamber) from 16 to 15, the error remains the same.  i have also checked the DQMH toolset version of both two laptops. it is the same.  anyone interested,please try if this issue exists in your machine. 

0 Kudos
Message 1 of 12
(6,164 Views)

Hi Snipper, 

 

I will take a look later today. In the meantime, did you make sure you had DQMH installed for LabVIEW 2015? 

 

Regards,

Fab

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
0 Kudos
Message 2 of 12
(6,141 Views)

It looks like something got corrupted in the Start Module.vi in two of the modules (Thermal Chamber Controller and Device Under Test) when you did the save for previous. Neither of those VIs will open (the error is 'unable to load block diagram').

 

I tried doing a save for previous of the installed example project on my system, from 2016 to 2015 (both LabVIEWs had DQMH 3.1.0.18 installed) and everything was fine. None of the VIs in 2015 were corrupted.

 

So my best guess (which isn't that great, unfortunately) is that something is corrupted in either your DQMH install(s) or your LabVIEW install(s). I suggest reinstalling DQMH on both LabVIEWs, and if that doesn't fix the issue, repairing both LabVIEWs. Sorry I don't have something more concrete to suggest.

Message 3 of 12
(6,138 Views)

Fab,  I make sure both two machines have DQMH installed with the same version.

0 Kudos
Message 4 of 12
(6,118 Views)

Hi Darren,

the error description is all what i wanted to say.    

you mean you have two version(LV16 and LV15) installed on the same machine, but i tried with two machines, one with LV16, and another with LV15, both LabVIEWs had DQMH 3.1.0.18 installed;  by the way, our OS is win64. but we installed LabVIEW 32 bit. so the directory is   C:\Program Files (x86)\National Instruments\LabVIEW 2016/5; i don't know if it will cause something.

 

i will try as your suggestion and feedback result.

0 Kudos
Message 5 of 12
(6,117 Views)

this afternoon i took following actions. but nothing works.

 

1. i doubt if some toolset will affect, so i uninstall G#, NI-GDS and etc, but it does not work

2. i  repair install LabVIEW 2016, then try again, but it does not work.

 

now i just save Thermal Chamber Controller_DQMH.lvlib to 15, but i still encounter the same error:  LabVIEW load error code 6, Could not load block diagram. 

 

i check this code in discussion forum, but found no available solution. 

0 Kudos
Message 6 of 12
(6,108 Views)

My only other idea is to clear the object cache in both LabVIEW 2015 and 2016. You can do that from Tools > Advanced > Clear Compiled Object Cache.

 

If that doesn't work, then there is something specific to your system that is going wrong, and I don't know how to troubleshoot it further.

0 Kudos
Message 7 of 12
(6,096 Views)

Hi Darren,

I followed your suggestion but unfortunately, i did not work. just inform you the result.     now i rewrite this vi manually to meet our time schedule. later i will try to install LV 16 and try if similar  issue exists there. 

0 Kudos
Message 8 of 12
(6,092 Views)

Just broke my DQMH modules too when converting back from 2018 to 2015 (necessary to get support for Fieldpoint targets...). The parts that get broken are the error constants, which I guess Delacor is aware of now from this thread: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Error-constant-ring-should-be-converted-to-code-when-...

 

Perhaps the verify modules function could add a fix for this?

0 Kudos
Message 9 of 12
(5,363 Views)

@Mads wrote:

... I guess Delacor is aware of now from this thread: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Error-constant-ring-should-be-converted-to-code-when-...

 


Stephen Loftus-Mercer has confirmed this will be fixed in LabVIEW 2018 SP1. In the meantime, he suggested to do the following:

To fix it:

Save attached file XSFP_18BackTo17.vi to

<LV2018>\vi.lib\ErrorRing\XSFP_18BackTo17.vi

and save ErrorRing.xsfp to

<LV2018> \resource\sfp\17.0\ErrorRing.xsfp

 

Those files will be included in the SP1. 

 

Looks like this would be the fix to save back to 17 and then you could save from there to 15. 

 

Let me know if this works out for you. Otherwise, on that idea exchange post, Stephen is suggesting this not-so-nice workaround:

 

"You could save to a version back before the error ring came into existence (LV 2011 or earlier). That will change the ring into regular cluster-building code. You might not want to save your whole project that far back, but the VIs that include error rings might suffice.

 

An annoying workaround, yes, but maybe it'll get you unstuck. I'm sorry for introducing the problem"

 

Regards,

Fab

 

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
Download All
Message 10 of 12
(5,360 Views)