Issue with saving and compiling main vi in Labview 2015

[synchronster]

I'm having a development maintenance issue with Labview with saving the main vi in my LV 2015 32 bit  IDE development system which is on a PC running Win7 and 6 Gigs of RAM.  Due to contractual agreements, I am always forced to save the vi and all support vis in the project to an older LV 8.6 target system which runs the H/W on WinXP with only 1.5G RAM.  On the dev side, it takes almost 5 minutes to save/compile the main vi and even when editing in the BD, there are times when the mouse cursor becomes busy and for 30 seconds or so the compiler is doing something until the front panel appears and I can continue editing away. Labview usually hovers around 1.2G of memory during that time and then drops down to around 700M when the compilation is complete.

All I can say is that the vi is as modular as can be and calls several subvi's.  The main executive takes up to 70 measurements using 2 motor stages for positioning each measurement as well as NI digital I/O H/W and relays to make the desired contacts with either 2 different sets of measuring H/W that are all event driven.  The BD is very nested with as many as 12 stacked sequences within a case structure consisting of 35 possible cases based on a menu ring the operator can select.

There is an open ticket with NI regarding this issue, however, I feel I'm getting nowhere with tech support as they don't seem to grasp the fact that if I make tweaks on the target system, it is much more manageable and the compile time is much faster to save even with only 1.5G of RAM on Windows XP.  There is obviously some big difference between the 2 IDE's and I'm wondering if flaws or vi corruption is introduced when ping-ponging back and forth between the 2 LV versions.  Unfortunately, the XP target system is not going away any time soon.  

I have attached the memory info showing the differences between the two main vis noting that the LV2015 version is almost twice in file size.   Would running a newer LV version on the dev system help (i.e. LV2017 or NXG?).  It's getting quite difficult to maintain the project so suggestions are welcome.

[tyk007]

If I have understood you correctly - you develop in LV2015 but then backwards save it to 8.6 for actual deployment on the target machine? And you also make changes on the target machine and then import them back into LV2015?

This "ping-pong" as you call it will probably work ok in the short-term but I strongly suggest that you get yourself setup so that your development and deployment environments are the same version. Call me overly-cautious (you won't be the first) but there have been many changes between those two versions - LV is generally pretty good at picking up incompatibilities when back-saving to an older version but going back and forth constantly makes me a bit paranoid that at some point you'll encounter an issue that NI haven't detected before or patched. My suggestions would be:

• Get a VM running with LV 8.6 to match your deployment target
• Use source control every time you "deploy" to or "retrieve" from your target environment. Because you never know.

[natasftw]

---

@synchronster wrote:

Due to contractual agreements, I am always forced to save the vi and all support vis in the project to an older LV 8.6 target system which runs the H/W on WinXP with only 1.5G RAM.

There is an open ticket with NI regarding this issue, however, I feel I'm getting nowhere with tech support as they don't seem to grasp the fact that if I make tweaks on the target system, it is much more manageable and the compile time is much faster to save even with only 1.5G of RAM on Windows XP.  There is obviously some big difference between the 2 IDE's and I'm wondering if flaws or vi corruption is introduced when ping-ponging back and forth between the 2 LV versions.  Unfortunately, the XP target system is not going away any time soon. 

---

If you want focused help, we'd need to be able to see code to tweak and play around.  It sounds like that isn't an option.  So, I'll bring up these two paragraphs.

1) I find that hard to believe.  I fully believe you're contractually obligated to provide deliverables in the form of LV 8.6 VIs to be used on that machine.  I'd be pretty surprised if they demand you also develop in LV 2015 and require that you convert it back to 8.6 between each thing you do.  You're making life harder on yourself by developing in 2015 here.  Let's ignore the hassle you're dealing with for swapping back and forth.  You're also going to struggle with changes to the language where features don't exist in both versions.

2) Let's be fair.  It took me three times reading through your post to believe I might have an idea of what you're trying to accomplish.  I'm still not sure if you're claiming it's slower to save on the newer machine than the XP.  But, I believe that's what you're saying.  The problem with support is just as much your ability to explain the problem as it is anyone else.  That aside, it wouldn't surprise me to hear it takes longer to save on the 2015 machine than the 8.6 machine.  Why?  You're only saving on the 8.6 machine.  That's it.  When you open the saved VIs on the 2015 machine, there's a recompile that'll happen in the background.  But, the hit happens there.  When you're "saving" on the 2015 machine, you're doing a bit of back conversion that, even if negligible, would take more time than simply saving.

If just editing the code on the 2015 machine is causing you some heartache, I'd wager you've got a rather large block diagram and that's causing pain points you're not considering.  But, that's merely speculation.  From your description, it doesn't sound like there's a lot of value in downloading the VIs to take a look.  If that came through wrong and those VIs actually show the majority of the functionality, please feel free to correct me.

[synchronster]

Sorry if I didn't make this clear.  When 'saving for previous version' in LV 2015, I choose 8.6 and it saves the main vi and all sub-vi's in the same folder structure as the host dev system.  Then I replace the older changes with the newer ones manually (without the folder structure mess) since on 8.6 I just click the main vi and there is no project set up.  On the target system I debug my changes and if it needs a fix (usually does) I can make the change, usually the main vi.   When saving it on 8.6 target it takes no more than a minute!  Still slow but workable.  When going back to the host system I just copy that main vi over in to the dev folder, then when I work with it in 2015, again, we're back to those annoying 5 min saves/compile times.

From the responses, I take it that if my dev system used 8.6, this would be an ideal solution, however, our IT dept. is only distributing LV2015 licenses with 8.6 being too old.  Personally, I would think having to go backwards to s/w from 10 years ago is not ideal.

[billko]

---

@synchronster wrote:

Sorry if I didn't make this clear.  When 'saving for previous version' in LV 2015, I choose 8.6 and it saves the main vi and all sub-vi's in the same folder structure as the host dev system.  Then I replace the older changes with the newer ones manually (without the folder structure mess) since on 8.6 I just click the main vi and there is no project set up.  On the target system I debug my changes and if it needs a fix (usually does) I can make the change, usually the main vi.   When saving it on 8.6 target it takes no more than a minute!  Still slow but workable.  When going back to the host system I just copy that main vi over in to the dev folder, then when I work with it in 2015, again, we're back to those annoying 5 min saves/compile times.

From the responses, I take it that if my dev system used 8.6, this would be an ideal solution, however, our IT dept. is only distributing LV2015 licenses with 8.6 being too old.  Personally, I would think having to go backwards to s/w from 10 years ago is not ideal.

---

I believe that LabVIEW licenses are good for that version AND ALL OLDER versions, too.  In other words, your LV 2015 license is good for LV 8.6 as well.

[synchronster]

---

@billko wrote:

---

@synchronster wrote:

Sorry if I didn't make this clear.  When 'saving for previous version' in LV 2015, I choose 8.6 and it saves the main vi and all sub-vi's in the same folder structure as the host dev system.  Then I replace the older changes with the newer ones manually (without the folder structure mess) since on 8.6 I just click the main vi and there is no project set up.  On the target system I debug my changes and if it needs a fix (usually does) I can make the change, usually the main vi.   When saving it on 8.6 target it takes no more than a minute!  Still slow but workable.  When going back to the host system I just copy that main vi over in to the dev folder, then when I work with it in 2015, again, we're back to those annoying 5 min saves/compile times.

From the responses, I take it that if my dev system used 8.6, this would be an ideal solution, however, our IT dept. is only distributing LV2015 licenses with 8.6 being too old.  Personally, I would think having to go backwards to s/w from 10 years ago is not ideal.

---

I believe that LabVIEW licenses are good for that version AND ALL OLDER versions, too.  In other words, your LV 2015 license is good for LV 8.6 as well.

---

OK.  That's good to know.  Any idea where I could find the CD with the 8.6 version to install?

[UliB]

Hello,

here is a download link for LabVIEW 8.6.1: http://www.ni.com/download/labview-development-system-8.6.1/3446/en/

Choose: I am a current user of LabVIEW Development System

UliB

[Mark_Yedinak]

Couldn't this also be a good time to renegotiate the contract specifying you must use LabVIEW version 8.6? It will become an unsupported product if it is not already not to mention it will not necessary be supported on newer OSs. At some point in time there is a necessity to upgrade to current versions. LabVIEW 8.6 is nearly 10 years old and as it continues to age you will end up having trouble maintaining the system as HW gets replaced that 8.6 cannot support. Its is hard to fully develop the crystal ball functionality to know all that the future will bring.

[synchronster]

---

@Mark_Yedinak wrote:

Couldn't this also be a good time to renegotiate the contract specifying you must use LabVIEW version 8.6? It will become an unsupported product if it is not already not to mention it will not necessary be supported on newer OSs. At some point in time there is a necessity to upgrade to current versions. LabVIEW 8.6 is nearly 10 years old and as it continues to age you will end up having trouble maintaining the system as HW gets replaced that 8.6 cannot support. Its is hard to fully develop the crystal ball functionality to know all that the future will bring.

---

We are working on a new test set with new H/W and it will probably be ready for production by Fall of this year.  To work with the new test set, my goal is to deploy EXE only on a Win7 target system running a LV2015 (or higher) runtime engine and all the 8.6 stuff will be obsolete.  In the meantime, I guess I'll download that 8.6 link since there's no contract to develop with it.  Thanks for the suggestion although I still don't feel going "backwards" is the ideal solution.

The current contract requires me keeping the current target production system as is with the XP machine running LV8.6.  Ironically, in the current test set there is one piece of 3rd party H/W where they only provide serial communication using their automation server via activeX.  The vendor will not support future s/w development and their server only works with WinXP, go figure.  With the new test set, I ensured a new H/W vendor that is Win7/Win10 compatible.  Once the test set is qualified for release, there will be a new contract which will be more flexible going the EXE route.

[natasftw]

---

@synchronster wrote:

---

Thanks for the suggestion although I still don't feel going "backwards" is the ideal solution.

---

I'd argue this is more ideal than what you've been doing, regardless of saving time.  There's compiling changing in the background.  There's countless features, bug fixes, new bugs introduced, etc that take place between those versions.  You were gambling.  With the changes being nearly a decade, you're better off going "backwards" as you're remaining consistent.  Trying to go back and forth is a bad idea all around.