fpga: how to retrieve bit files from completed compilation?

[kdnelson]

I started a long compile and disconnected from the compilation so I could start a second complilation.

When the server window was showing the first compile was done, I tried to "reconnect to compilation."  Labview thought the .vi had changed, so it started to re-create all the intermediate files.

I can see all the files from the compilation sitting in the server directory.  All I want to do is get them into a .lvbitx file so I don't have to redo everything.

How can I convince LV it doesn't need to start over?  Or how can I manually combine the server files into a .lvbitx?

Thanks,
Karl.

[T-REX$]

Hi Karl,

If the compilation did actually finish, your .lvbitx file should be located at the destination specified by your build spec (check the properties window).

Why did you disconnect before starting a second compilation? That shouldn't be necessary... I compile to multiple workers all the time without disconnecting first.

[kdnelson]

---

@T-REX$ wrote:

Hi Karl,

If the compilation did actually finish, your .lvbitx file should be located at the destination specified by your build spec (check the properties window).

Why did you disconnect before starting a second compilation? That shouldn't be necessary... I compile to multiple workers all the time without disconnecting first.

---

Unfortunately disconnecting from the compilation made it so the files were never retrieved back from the server and placed in my specified destination.  Normally, when you reconnect to a compilation, LV quickly retrieves the files.  But this time, it wanted to start over.

I disconnected because the LV told me to.  Something about already having a compile running, you need to disconnect first.

Karl.

[T-REX$]

Ah, gotcha. I create a new build-spec when I kick off a new compile. I'll often kick off 3+ compiles (of the same VI) from different build-specs to get them on different compile workers (local, remote, & cloud is common for my tests). This will let you have as many going as you want, without having to disconnect from anything. What likely happened is that the new compile started overwriting all of the intermediate files, and the signature changed.

Launching a new compile is likely your best option at this point  We do have some internal tools that I could use to build it up if I had your code, but it would likely require me to recompile your code anyway... so that won't be any quicker.

[kdnelson]

---

@T-REX$ wrote:

Ah, gotcha. I create a new build-spec when I kick off a new compile. I'll often kick off 3+ compiles (of the same VI) from different build-specs to get them on different compile workers (local, remote, & cloud is common for my tests). This will let you have as many going as you want, without having to disconnect from

Do you have a quick tutorial on how to use a build specification to do this? I'd love do exactly what you describe.

If I try to create a build spec for my target, I don't see any options that seem useful for this.  (LV 2009sp1)

[nathand]

---

@kdnelson wrote:

Do you have a quick tutorial on how to use a build specification to do this? I'd love do exactly what you describe.

If I try to create a build spec for my target, I don't see any options that seem useful for this.  (LV 2009sp1)

---

Unfortunately that option wasn't available in LabVIEW 2009; build specifications for FPGA targets were added in a more recent version.

[nathand]

Adding to my previous post... maybe you could create additional FPGA targets in your project (you don't have to have the hardware for them), add the same FPGA VIs under those new targets, and start separate compiles? Then the bitfiles will get unique filenames, and as long you only want the bitfiles at the end and don't need them to be associated with a particular VI (ie, you're going to open the bitfile reference, not a VI reference) you can rename them to something that makes sense after the compile ends.