From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
your own instrument VIs in instr.lib ?
Solved!
@JÞB wrote:
@billko wrote:
@DavidBoyd wrote:
I find this thread interesting in the variety of replies and insights, and hope there will be more replies. Here's mine:
I'm a longtime LV developer in a small team, and though in practice we tend to work as individuals on separate projects, we share code whenever we can.
As far as placement of one's own and/or modified code goes, I've followed the following cardinal rules:
- NEVER modify anything in (or add to) vi.lib - that's NI's standard library, and gets replaced with each new release.
- Use user.lib for anything that looks like a good reuse candidate, apart from instrument control.
- Use instr.lib for any code developed to be instrument specific. Whether NI-supplied, manufacturer-supplied, or organically-grown drivers.
Just about all my user.lib and instr.lib development is LVLIB encapsulated, for namespacing, icon patterning, reference documentation, and palette consistency.
Dave
I usually build packages with VIPM to install into either user.lib or instr.lib (as appropriate) and keep the "source" in a development folder. That way I'm not editing "live" code.
Bill, can you show an example of how that is superior to a Source Distro Build? (That is an "Ask not a question my friend,)
Dave, you also make some good points!
Both of you have been apparently triing to distribute source code to co-developers. Brian will probably chime in as well.
Mostly, I feel it is size of team, scope of projects, and a combination of developer skil vs development training / archeitecture. I would welcome lessons.
Serendipity is nice - merge with if you think it is appropriate
I don't really know if it is "superior" in any way. I guess that since there is an installer, it leaves a trail of breadcrumbs so you can more easily keep track of build info. Also, it's easy to insert your own palette into an existing one. Even though some would list the ability to build for different versions of LV as some kind of advantage, it's just as much work to do that in VIPM as it is doing it manually. To me, anyway.
Is that what you were trying to get at? Your question wasn't really too clear to me. Sorry.
I've never tried to take a driver out of instr.lib. Let me try and then see what my workflow would be.
@DavidBoyd wrote:
Bill,
I tried - once - to walk through building a package in VIPM Pro of an instrument driver I'd created. I came away frustrated by the fact that VIPM would not let the package source be taken from under instr.lib. (I did my dev work under instr.lib just so I could fuss with palette menus and such and see them properly displayed under Instrument I/O->Instrument Drivers.) Is it really as simple as copying everything out from under instr.lib and placing it somewhere else to make the package build work correctly? ISTR that the project library tried to resolve all the VI paths back to <instrlib>\drivername\ after the move, so I figured VIPM would be just as confused. Or does it fix all the relative path problems?
Can you describe your workflow for driver development and subsequent packaging?
Dave
Since instr.lib is in your search path, you probably need to move the folder instead of copy it. I moved a driver out of the instr.lib folder and it only complained that the library was loaded from the new path.
