Efficient Real-Time Development Practices

[hooovahh]

So lets say I have a single project, and in it is two targets, a Windows host, and the RT.  Many of the libraries I use in the Windows side, I also use on the RT side.  But I think that this is causing lots of unnecessary "Compiling" of VIs over and over depending on which target I'm open the code from.

Here's an example.  I have a Windows Main.vi, and a RT Main.vi both under their appropriate targets.  If I open the Windows Main.vi it opens relatively quickly, and loads about 2000 VIs and shows the main.  But if I then open the RT Main.vi, it goes through and compiles about 200 of those VIs taking several minutes to open.  So after both are open I perform a Save All, thinking whatever it needed to compile and do it should be done with.  If I then close the project and re open it, and then open the Windows Main.vi it has to recompiles those 200 VIs presumably for the new target, and then if I open the RT Main it has to recompile those 200 VIs again.  Is this how it is supposed to be? Every time I reopen a VI on a new target am I supposed to see it recompile for that target back and forth depending on where it was opened last?

The project has a mix of VIs that have separate compiled code on and some with it off.  Not sure which is better for this.

My computer is relatively powerful, but lately doing LabVIEW development makes me feel like I'm using a 10 year old PC.  Everything about my computer seems fast except LabVIEW development.  Is there tips or tricks, or options I should be using to help make my LabVIEW development more responsive, and require less recompiling when switching targets?

EDIT:  It seems that the VIs that need to recompile all the time are VIs that are in a Polymorphic VI, so the majority of them are reuse and OpenG VIs.

Double Edit:  It seems this thread from an older post on LAVA claims that the compiled cache has separate entries for a VI on multiple targets, so I'm not sure why these VIs need to recompile every time...

[MarkCG]

LabVIEW is not recompiling my RT MAIN.vis  every time I open one of these projects. I do not have source separated from code either. I wonder if it has to do with VIs shared by both RT and Windows.

[odoylerules]

Its stuff like this why i don't develop a Windows target and RT Target in the same project any more.  Locked classes/libraries are such a pain.  I'm not sure that will solve your issue since it would still probably recompile on you.  Do you know if the items that are recompiled happen to marked Read Only in the OS?  That's caused me issues before on re-compiles and strange saves.  

 

 

Edited August 17, 2016 by odoylerules

[hooovahh]

The files I see it recompiling don't have a common theme other than the fact that they all seemed to be part of polymorphic VIs.  I saw some from OpenG, which don't have the separate compiled code on, I have some from our reuse library which do have separate compiled code on, and I saw some that are unique to the project which happen to have separate compiled code on.  I checked out my compiled cache file and it is almost 300MB, that feels a bit large so before I leave today I'll try deleting it, and having it rebuild for primary project I'm working on.

Separate projects is an option for this design, but like you said I'm not sure it would fix my issue, and might actually cause some more.  I do like how a project knows that I've been editing some code for one target and haven't synced my changes to the other.  I'm not sure that would happen between different projects.

[shoneill]

Below follows my personal experience and frustrations, YMMV.

I have been cursing this "feature" for a few years and have tried raising the issue with NI.  My dream would be context-free VIs.  There are certainly a few issues with saving VIs when using RT targets.

When working on multiple targets, apparently LV switches out certain libraries depending on the target.  Using one VI on a windows target and the "same" VI on a RT target may actually reference a different VI in the background with LV switching out target-specific VIs as required.  The user doesnb't get any feedback on this, it's all controlled by the IDE.  Unfortunately, the VI format is such that certain information about this specific VI is saved in the source code of the VI (Path, connector pane and so on).  So when deploying to a RT target, a save is forced which again forces the VI to produce a different source than before (other things can also lead to unneccessary changes to source code).  Going back to Windows target will then prompt a save when closing the file because..... I don't actually know why exactly.  Does the windows version of the file receive a notification that the file was since saved from a different context?

The very same thing happens with conditional disables, the currently active conditional disable is saved in the source code of a VI even though upon loading this is guaranteed to be overwritten anyway.  All of these things make code reuse over several targets a royal PITA.  I was hoping any future developments would fix these problems, but I'm as yet unsure if NI has understood how annoying this behaviour is.  I think any such pollution of source code by target-specific data (which is enumerated again on load anyway) should be avoided like the pest.  I have since written a VI which uses SVN command line tools to do an automatic LVCompare on the current on-disk VI hierarchy versus their pendant in the repository and auto-reverting if LVCompare detects no change.

Shane

PS:  Regarding saving of VIs between windows and RT..... "Funny" thing is when this all happens to VIs which are set to be inlined and actual code changes have been made.  My experience is that LV will mark the inlined VI as being changed, but not the owning VI (Whose compiled code actually contains the "old" version of the inlined VI).  When deploying LV will deploy the new inlined VI (which is a pointless exercise as the VI as such is never called) but will still deploy the old version of the parent VI (which now contains out of date compiled code).  This leads to all kind of fun with VIs running on RT not being marked as such in the IDE and vise versa.  Yay.  Productivity. .  My workflow has adapted to go through the entire VI hierarchy from the sub-VI to main VI one by one and saving each and every VI so that LV will actually propagate the changes in inlined code to the actual application being deployed.

[hooovahh]

Well this seems like a real issue, and one that people must have been struggling for for the past 10 years or so.  Yes I am a big proponent of reuse, banging that reuse drum all I can.  Which is partially why so much of my code is reused between targets, much of it resides in user.lib, or in libraries that are project specific but still reused between targets.  The conditional disable diagram is used pretty often.  Many templates used are the same between RT and windows targets, with slightly different things like timeouts and polling control values on RT, and disabling other fancy UI things when on RT.  Some of the VIs that it shows having to recompile over and over do have conditional disable diagrams, but some don't, some are reuse, some aren't.

Also last night I deleted my object cache, and reopened the project new.  The issue still remains, that if I open the RT target some VIs need to recompile, and then if I close and reopen the Windows target those same VIs need to recompile again, but oddly the number of objects that recompiling is reduced down to only 22 VIs, making life a bit easier.

[JamesMc86]

I've been lurking as I have nothing to add but to say your not alone!

I have taken to using multiple projects more often than I would like. I also have fun with classes and what I presume is a compile issue, my project generally wont run interactively saying random VIs are broken. If you open them, save (maybe force recompile) it will move onto another VI is broken. Eventually it will work. I depend on remote debugging instead now.

[shoneill]

Ooh, James, that's another interesting feature of RT deploys I forgot to mention.  Random broken VIs in classes which run perfectly well on their own.  I've seen this on many occasions also.

I mentioned these issues to some R&D guys at NI week and they seemed surprised at the information.  Where does all the information go when we send it to NI?

[hooovahh]

So it seems everyone here at least is passingly familiar with the issues I'm describing, but I wanted to document it a bit and I did this with some screen recording software.  I also posted this on the NI thread that is partially discussing this:

So last night I uninstalled all LabVIEW 2015 code, restarted several times, cleaned things up, and reinstalled 2015 and the RT module.  Today I still have some recompiling issues when going back and forth.  Here are two videos (because they are limited to 5 minutes using jing).  The first shows opening a project, opening the Windows Main, showing the compile window, then opening the RT main showing the compile window, then resave everything, close the project and reopen.  The second video shows re opening the Windows and RT main showing that files have to be recompiled yet again.
 
Part 1
Part 2

So separate projects is the solution people are using?  Man that seems like it could be a pain.  I'm going to continue having it in one project for now.  I have yet to see the brokenness but running issue.  Seems like there are many issues with developing for multiple targets, and for RT in general.  Honestly I'm surprised because like I said RT development has been a thing for around 10 years now.

[JamesMc86]

31 minutes ago, hooovahh said:

So separate projects is the solution people are using?  Man that seems like it could be a pain.  I'm going to continue having it in one project for now. 

It is a pain that I would generally avoid but my issues are that I have the same code on 2 different types of RT systems so everything is locked so that forced my hand more in this case.

[hooovahh]

21 minutes ago, JamesMc86 said:

It is a pain that I would generally avoid but my issues are that I have the same code on 2 different types of RT systems so everything is locked so that forced my hand more in this case.

Why is this the case?  If you have two different types of targets in your project, you have the code added to each target, and can open them independently right?  I guess I haven't developed on two different RT systems at once so I don't know I just assumed it worked like the two targets I have in Windows and RT, although those have different top level VIs which might make the difference.

[JamesMc86]

It still creates two different contexts in the projects so any libraries or classes that are in both (a.k.a all of them as it is the same VI!) are locked and you cannot edit type defs or add VIs.

[ShaunR]

3 hours ago, hooovahh said:

So separate projects is the solution people are using?  Man that seems like it could be a pain.  I'm going to continue having it in one project for now.  I have yet to see the brokenness but running issue.  Seems like there are many issues with developing for multiple targets, and for RT in general.  Honestly I'm surprised because like I said RT development has been a thing for around 10 years now.

I haven't done much recently with these targets so can't contribute much. But!.....

I wanted the project manager to be able to nest projects several years ago. That would solve this problem and enable developers to work and test on separate projects in parallel and pull them together as sub components much more easily-which is why I wanted it. So rather than being a separate target within the project. It would be separate project completely that you could add to another project. Every other IDE has this capability.

[GregSands]

I don't think multiple projects will work if using Network Shared Variables (ok, I know that using them is the main mistake, but they seem to work well and easily for my code).  But the difficulties in working with classes or reuse code on more than one target at once are challenging at the moment.  There's an old suggestion on the Idea Exchange relating to this, also detailing some of the issues in fixing it - I'm sure a few more kudos wouldn't hurt, though they may not help.

[hooovahh]

On 8/19/2016 at 10:05 AM, JamesMc86 said:

It still creates two different contexts in the projects so any libraries or classes that are in both (a.k.a all of them as it is the same VI!) are locked and you cannot edit type defs or add VIs.

See I didn't realize this was a limitation.  In my situation LabVIEW Libraries are the main container for code modules, not classes and this appears to be a limitation of LabVIEW classes which is why I've never seen this.  So in my situation I can open both Windows Main, and RT Main VIs at once, and run them independently, or develop in either context with few issues (one being you need to sync code after making changes).  Here is the article put out by NI (which was found in the idea exchange) that describes the issue with classes.

[SimplicityJon]

Just thought I would add my two cents. We develop RT applications using classes that span accross different types of cRIO and PXI targets. We see all the issues mentioned here previously, along with very long load times for projects with lots of classes (LV actually loads all VIs into memory when they are in a class, when you open the project). We have resorted to using multiple projects to get around some of the issues, I tend to have one windows project, one/two development RT projects (one for PXI and one for cRIO if using both) and one build project with all the different classes of target. Although there seems to be no getting round the random broken run arrows on perfectly fine VI's.

As we have multiple developers we did try using the 'seperate compiled code form source option' but this exhibited some even worse issues with some VIs not being updated on the realtime target after changes had been made (and deployed), regular deleting of the object cache seemed to be the only solution so we ended up disabling this option.

[infinitenothing]

I use RT a lot and actually haven't run into this much. Most of the time the only thing I share between the RT and Main are the control type defs and normally, when it blocks me from editing, I like that reminder. I just stop my RT code. A stop button is about the only thing I have on the top level front panel out there. I almost never edit things in libraries on the RT side. I was probably trained out of it. The RT code is usually fairly light and doesn't do fancy stuff for performance reasons. It's somewhat old school programming. On the Windows side I'm less concerned about memory so I'll let my data types get heavier and I'm more willing to create new threads.

[Jordan Kuehn]

I just found this thread and have been getting hit by this pretty hard on my current project. That and classes locking when I have a typedef used on two targets. LV 2020. Is the answer really just to break my projects apart into Windows and RT? I've not had to do this in the past, but I haven't had as extensive use of classes on the RT side before.

[hooovahh]

Since this thread I've been using separate projects for each target.  Debugging things aren't that difficult until it is some interaction between the two systems.  I'll build my RTEXE, deploy it, then run my Windows VIs from the Host Only project.  I might then realize the issue is on the RT side, so I then build the Windows EXE, close the Host Only project, open the RT Only project, open and run my main RT VI, then run my Windows EXE.  Lots of building, and deploying when debugging.  But since most issues I encounter are clearly one targets bug or the other it isn't too bad.  I'll just open that project and run the source and debug the issue, while the other target runs its binary.  It really seems like multiple targets in a project is one of those features that works in practice, and in the real world, falls short of expectations.

[Jordan Kuehn]

Thanks, that is almost exactly what I've taken to doing.