LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 
JKSH

Allow users to continue working when a build is in progress

Status: New

When a build is in progress (Application Developer or FPGA*), the entire LabVIEW IDE is blocked.

 

Since some builds can take a long time, it would be far more productive if users could continue working in parallel with the build. Example use cases:

  • Initiate a build for an RT target, then work on code for the PC server
  • Initiate a build for one project, then work on code for another project

 

To prevent accidents, LabVIEW could reserve all the VIs/libraries that are part of the Build Specification:

  • The call tree of "Startup VIs"
  • The "Always Included" VIs).

 

*At least the FPGA build only blocks at the preparation stage, but that takes a while too. 

Certified LabVIEW Developer

8 Comments
fabric
Active Participant

Kudos (with the "prevent accidents" option).

 

My workaround: Install 32-bit and 64-bit versions. While building in one version, use the other version to continue development. This workaround is almost certainly dangerous, e.g. editing a shared VI while building could break the build or give unexpected results...

--
Chris Virgona
crossrulz
Knight of NI

But if NI does this, I won't have time to sword fight on chairs.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
elset191
Active Participant

@crossrulz wrote:
But if NI does this, I won't have time to sword fight on chairs

I definitely have that hanging on my wall.  I need my compile time.

--
Tim Elsey
Certified LabVIEW Architect
GuenterMueller
Active Participant
My heart also beats for a faster builds. Blocking VIs that are in use for the build is acceptable. Much more I would prefer multi-threaded builds...
egraham
Member
JKSH
Active Participant

Argh, I can't seem to write a post without typos these days. My original is suposed to say "Application Builder", not "Application Developer"

 

 

> crossrulz wrote:

> But if NI does this, I won't have time to sword fight on chairs.

 

Love it! Perhaps I should retract this idea 😄

 

 

> GuenterMueller wrote:

Much more I would prefer multi-threaded builds...

 

+1. The vast majority of PCs are multicore nowadays.

 

 

> egraham wrote:
>That's what build servers are for. :smileyhappy:

 

What if we're a small company with multiple projects and 1 server, and that server is in the middle of a 40-minute compilation of an FPGA bitfile?

Certified LabVIEW Developer

tst
Knight of NI Knight of NI
Knight of NI

If you want a solution today, just make a copy of LabVIEW.exe and run it in parallel (or add AllowMultipleInstances=True to the LabVIEW.ini file). Once a VI has been loaded into memory, there should be no conflicts between the different versions, as each has its own copy open (with the obvious caveat that changes you make while editing won't be reflected in the other version until you reload). That said, I have no practical experience with doing this for builds, so there might be some hidden gotchas.


___________________
Try to take over the world!
egraham
Member

We don't create build servers on our own servers. We use Rackspace for build servers. That way you never have to worry about maintaining your own hardware.