Leaderboard

............................................________ ....................................,.-'"...................``~., .............................,.-"..................................."-., .........................,/...............................................":, .....................,?......................................................\, .................../...........................................................,} ................./......................................................,:`^`..} .............../...................................................,:"........./ ..............?.....__.........................................:`.........../ ............./__.(....."~-,_..............................,:`........../ .........../(_...."~,_........"~,_....................,:`........_/ ..........{.._$;_......"=,_......."-,_.......,.-~-,},.~";/....} ...........((.....*~_......."=-._......";,,./`..../"............../ ...,,,___.\`~,......"~.,....................`.....}............../ ............(....`=-,,.......`........................(......;_,,-" ............/.`~,......`-...............................\....../\ .............\`~.*-,.....................................|,./.....\,__ ,,_..........}.>-._\...................................|..............`=~-, .....`=~-,_\_......`\,.................................\ ...................`=~-,,.\,...............................\ ................................`:,,...........................`\..............__ .....................................`=-,...................,%`>--==`` ........................................_\..........._,-%.......`\ ...................................,<`.._|_,-&``................`

Thanks for the diagram, that makes some things clearer! I hacked up a diagram similar to yours, but showing where VIPM might fit into the system. See attached. Notable differences: Package Building is simpler because VIPM takes care of the hard parts of the OGB/OGPB hassle. Instead of a Network Share, built packages are stored in a VI Package Repository on the network. Note that this is exactly like NI's LabVIEW Tools Network repository, or the VI Package Network repository used by OpenG, but it contains your packages. Instead of manually getting packages from the Network Share, each project developer uses VIPM to download packages from the Package Repository, and creates a VIPC file for each project. This VIPC file specifies exactly which packages are in use on the project. When switching between projects, the developer just "applies" the new project's VIPC file and he/she knows the correct packages will be installed. EDIT: To clarify my 3rd point above... The project-specific VIPC doesn't just allow a single developer to switch projects easily; it also makes it easy for one developer to hand a project off to another developer because in ensures everyone's environment has the correct packages when they start work.

I assure you that if I hadn't done it, someone else would have. Anyway, there was a poor user on the other end of that thread who was innocently trying to help, so I didn't feel good about letting them keep at it. And, hey, at least you came out of it with a VI which simulates AN ENTIRE UNIVERSE. That's something, right?

Another quick note on this. Depending on what you want to do with the information (see my post above where I don't quite understand what that is ), you might be able to do exactly what you want with VIPM's Custom Actions. You can create special VIs that run at pre-/post-build, pre-/post-install, and pre-/post-uninstall time for each package. This gives you a tremendous amount of flexibility in terms of mangling your VIs or various support files exactly the way you want, in an automated way. Install Actions and Uninstall Actions are available in VIPM Community. Build Actions are available in VIPM Professional and Enterprise. Correct. I'm not a hardcore mercurial user so I can't comment intelligently on exactly how that would happen, but in SVN, if you had a directory of packages under source code control you'd have to delete the old package and then Commit that change. However, this is another advantage of VIPC files. The VIPC file contains a list of packages (and their versions!) so you can never have the duplicate package problem you're describing. You'd handle your package upgrades this way: Build the new package. Open your existing VIPC file for a given project and drag the new package into it (requires VIPM Pro). Save the VIPC. Commit the modified VIPC file to SCC. Use a commit comment like "Upgraded blackpearl_lib_kraken_tracker.vip to 2.0.1." This way you're not "adding" or "removing" files from SCC -- you're just updating the package configuration (VIPC file) that you're already tracking.

I think that, since I work for an NI Alliance Member, I'd have close to the best LabVIEW job - as any other NI Alliance Member employee can probably attest to. The coolest thing about LabVIEW is that it opens you up to such a broad selection of projects, applications, new technologies, and industries. In the past year, I've: 1) Architected and led a team of testers to implement a TestStand/LabVIEW Embedded Software Integration testing strategy and system, that now currently runs every night and covers over 400 test cases for an AUTOMOTIVE product 2) Frantically learnt LabVIEW FPGA, to help build a prototype signal detection/analysis system using FlexRIO and Peer to peer streaming technology, for a BIOMEDICAL application 3) Assisted in the development of LabVIEW RT/FPGA for a viscosity measuring device, to be used by the PHARMACEUTICALS industry. 4) Currently re-designing a high-speed signal acquisition/processing application to be run on an R-Series DAQ Card (more FPGA), for the PAPER industry. 5) Currently playing with an EVS RT Vision Controller, learning about Vision to develop a Vision inspection system for the MANUFACTURING industry. Writing LabVIEW is the easy part. Understanding the application is the tricky bit! OK cool, my first post over and done with!!