LLB management of compiled custom device

[ABPar]

This might be a bit of an odd question, but I have recently joined a company where they have compiled custom device files for Linux based CRio's, but do not have the project itself. I wish to make changes within these custom devices, but without the project, I have reached a bit of a dead end

Now let me go a bit on the structure of these compiled LLB's, there is the main configuration, and then the configuration for different operating system and different LLB's. Simple enough so far. But...

There are in total 4 files that are directly related to custom devices (Aside from individual sub VI's). They are to do with initialization, the RT driver, the pages, etc.

Now obviously, the main configuration LLB does not have the RT driver, those are within the separate operating system LLBs.

My issue is that I wish to somehow make changes, which do not involve me having to recreate everything. As you are aware, LLBs packaged like these for custom devices also include stuff like ClearErrors etc in the LLB itself, which means using it while also having another project open is basically not viable, and nor is copying from the VI itself.

Does anyone know of a way to manage to either extract the project from these LLB's, or just the ability to modify the individual files within this LLB compiled for a Linux subsystem, without wrecking the LLB itself and making it undeployable on Veristand?

I feel that this is not possible, and that I will have to basically recreate the custom device from scratch and then make the changes I need to make, but I wanted to ask first if this is possible at all.

Getting the original project is not possible, but I do have a project which is about a couple of versions removed from what the end product is, so even some guidance on managing to get a couple of vis from an LLB without absolutely wrecking dependencies would be helpful. 

Thank you, and sorry if this question is too rambling or not clear enough.

[altenbach]

Classically, an LLB file (*.llb) is just a container for LabVIEW files and, using the "llb manager", you can move file around. I have no idea what a "compiled llb" is. Can you explain?

A project file (*.lvproj) does not contain any code, it is just a specially formatted text file that contains information where things are located and how things are configured (and much more, of course!).

is it possible you are talking about lvlibp , for example?

[rolfk]

Are you sure you talk about LLBs and not LVLIB(P)s? There is really not such a thing like a compiled LLB, although you could build an LLB where the diagrams were removed, but that is an additional step during build actions and I never have seen this effectively used. If this is what you mean, there would be no way to get the diagram back and to make changes to these VIs. The same applies to LVLIBPs, they are compiled LVLIBs and by default do not contain any diagram. The diagram can be retained for debugging purposes but even in that case it would be rather tedious to retrieve the VIs and put them back into a normal LVLIB to be able to edit them in any way.

So you should clarify a little what it is you really have. As it stands your explanation is somewhat confusing.

[ABPar]

Hey,

Sorry for being unclear. I think I fundamentally misunderstood LLB's. It is a simple LLB, but they got it by compiling a source distribution for a Linux x64 system, so in my head it was different from a normal LLB. Obviously, I don't have the original project, only the LLB.

I still have the issue that if I make a change, it changes the VI to polymorphic. I have found a workaround by adding the LLB to a new project, and then creating a new distribution LLB for a Linux system and deploying that to veristand. 

Thanks, the problem is solved, but if there is a better way to do this, I would still like to know!

[altenbach]

LLBs existed way before LabVIEW projects and you can easily convert them to a folder full of files and the only thing you'll lose is the designation of "toplevel" for some VIs. Most programmers no longer use llbs and instead use the folder structure of the OS. Safer!

If this collection of files was generated by building a source distribution (I would not call it "compiling"!), there probably was a project that define the source distribution. For some odd reason, building a source distribution does not allow including the *.lvproj file as part of the build specs (see also), but I have a custom script that does it..

Creating a new project is easy. Just add the toplevel VI and the dependencies will follow.

---

@ABPar wrote:

I still have the issue that if I make a change, it changes the VI to polymorphic.

---

You are still throwing around terms that make no sense! There are billions of ways to "make a change"! Can you narrow it down a bit? A VI cannot change to polymorphic, but you can create a polymorphic VI from multiple similar VIs. Please clarify!