Benchtop Measurement and Test
Distributed Measurement and Control
Systems Engineering Software
You can request repair, RMA, schedule calibration, or get technical support. A valid service agreement may be required.
Provides support for NI data acquisition and signal conditioning devices.
Provides support for Ethernet, GPIB, serial, USB, and other types of instruments.
Provides support for NI GPIB controllers and NI embedded controllers with GPIB ports.
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:
To prevent accidents, LabVIEW could reserve all the VIs/libraries that are part of the Build Specification:
*At least the FPGA build only blocks at the preparation stage, but that takes a while too.
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...
But if NI does this, I won't have time to sword fight on chairs.
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.
That's what build servers are for.
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.
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?
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
What do you need our team of experts to assist you with?
We'll be in touch soon!