jdunham

Seems like it would be easier to use several graphs, hide all the Y axes except for the first, and use user events to keep the plots on the same Y scale. If you were insane, and had nothing better to do for the rest of the month, you could make it into a sweet XControl. Depending on how many traces you need to display, you can hide some of the graphs and recompute the others' widths to fill the plot area.

It costs thousands of dollars to process a clearance, and this cost is borne by the employer. I doubt you'll have much luck trying to get a clearance for a consulting gig. Plus your employer is probably not stupid. If you ask for a clearance when you don't need one, it will be obvious that you want it to help you go look for another job. Maybe you can just ask for a salary boost more challenges and skip the need to moonlight.

I usually use Notifiers rather than User Events. Many of my notifier subscribers don't run GUI loops at all. Otherwise, I don't think there's too much difference, but the APIs are very similar between Queues and Notifiers and it might clean up your code.

If you are updating the array with new values, you shouldn't need the in-place element structure. The replace array subset function should not make a copy in most instances. In-place really only shines if you are taking data out of the array, modifying it, and stuffing it back in.

I agree that it may not technically be a bug if there's some spec somewhere at NI that says this behavior is expected, but it's still a horrible design defect in the LabVIEW development environment. There's no reason bundle by Name and Unbundle by Name couldn't keep track of the names and break the VI if there were any change in the names, sort of like relinking subvis. The amount work to fix hundreds of broken subvis pales in comparison to the havoc wreaked by having your tested production code silently change its functionality. We've learned to be more vigilant about cluster name and order changes, and have added more unit testing, but there's really no excuse for NI permitting this. Re the current discussion, I don't believe the existence of this horrible design bug ought to inform the choice of whether to use OOP or not, though given that NI seems reluctant to fix it, maybe it does factor in. Jason

This happens to us all the time too. Like Daklu says, the lvclass files themselves don't change, and consequently they claim to need saving every time the project is closed. Therefore it's just LabVIEW putting an erroneous 'dirty flag' on the lvclass. We don't bother to save them, but it is quite annoying.

Right. It's a peculiarity of SVN that tags and branches are implemented the same way (http://svnbook.red-bean.com/en/1.1/ch04s06.html). At any rate, if you can get a meaningful, traceable tag into the About window, that's great. But my overall recommendation is to keep unique version numbers, and have a system where any version number can be easily traced to a specific snapshot of your code repository. The system we use, where version 1.4.2.12345 can also be called 1.4.2 for short, and either way can be traced to a specific snapshot and branch of code as well as the 1.4 feature spec, has worked out very well. This also allows us to make a small change and build 1.4.3 on very short notice, though we have learned to keep a virtual machine around with the same version of LabVIEW and the drivers on it, for patching those old versions. I have to add that all this I've written was learned by screwing it up at one time or another! Anyway, I hope this helped the OP. We don't build for multiple OS targets, but I don't think that would break this system.

For us, all minor releases (second number) with an even number go to the QE guy. If 5.0.4 passes his tests, he's authorized to release it. By the time it gets to that point, we should already be building 5.1.x regularly and getting it ready. 5.0.x builds are built off a branch which is frozen except for fixes. 5.1.x is getting built off the trunk. Once we are feature-complete and start building 5.2.x, it's quite possible we'll need to patch an old version. So it's no problem to build 5.0.5 too, off of the 5.0 source branch, at the same time as we are working on later versions. Not exactly sure what you mean. We do tag the source from every build, but it's redundant. If you have the source code URL and a version number, you have a traceable copy of what was built. Again this is not visible to the end user. The requirement is that the user can submit a bug report with the contents of the About window, and I can check out the exact copy of the source code. I may have answered part of this above. In SVN tags and branches are the same thing, but there is a convention that you don't commit any more code into a tag. So we have branches for all releases, 5.0, 5.2, 5.4, 6.0 (the numbers have been changed to protect the guilty). The odd number releases (5.3, 6.1) can be built out of any branch, either the trunk or some experimental branch, but during acceptance testing and for patches after release, the even numbered branches should always be built from the feature-frozen release branch. The least enforceable part is to actually freeze the release branch, but we do the best we can. The more you add features to a release branch, the more work you have to do to merge it back into the trunk (which for us is the everyday development code). Hope that helps, Jason

I checked out Hg. So what it if it's easier to branch and merge; the difficulty of the merge remains in diffing LabVIEW routines, which sux. SVN is working fine for our small team. I agree that the SVN revision number must be coupled with a URL for true traceability. But that should be kept in your build logs, not exposed to the end user. If you get a bug report by phone, and you ask for the version they are running, is it better to hear "5.0.3.64572", or "5.0 (EB63908A-031A-11E0-BEAA-C410DFD72085)"?

I think he was referring to programmatic setting of version numbers in the build specs. Basically you have to open the Project Reference, the Target reference, and drill down to the EXE Build Spec references, and then use the Set Tag method to change the TgtF_fileVersion.major, .minor, .patch, .build properties. For the Installer build spec, the tag is called INST_productVersion, and it takes a string of the format "1.2.3", whereas the EXE tags take integers. Oh, and in LV2009 and earlier, the tags were called App_fileVersion.* for EXEs, and ProductVersion for Installers. So I have some spaghetti code which handles this, but I'd rather try to make a real version before releasing it. You might have an easier time writing software to edit the lvproj file's XML contents directly. With LabVIEW's regular expression search and replace you could do this easily. Personally I would use 4.9.x for the development builds leading up to 5.0. It certainly suffers the defects you mention, but you can always write a VI that checks version numbers and treats an x.9.x version as an x+1.0 version. Also we try hard to minimize version-specific behavior. We immediately went away from this approach. In conversation (which is important), and more importantly in bug reports, people are going to say "5.0.0" rather than "5.0.0.6485", so it's important that "5.0.0" refer to a very specific, traceable piece of source code and executable. We've taken some pains to make sure our build system can't produce two successful builds with the same first three numbers.

I think the discussion has been interesting. My opinion is that encapsulation is what matters most in increasing maintainability and reuse and reducing bugs. Keeping as many routines private as you can, and minimizing the interface (the number and complexity of the public routines) is the goal. The LV library (lvlib), and it's cousin the lvclass, the have been a big help to the language in this regard, despite other annoyances. I think Shaun has some valid criticisms about the need to maintain more state when using an lvclass, so I only use them when I need dynamic dispatching. Another problem with classes (objects) is the difficulty of adding a new dynamic dispatch method to a bunch of existing classes. I find I get more work done if I can rapidly prototype and iterate to find a good design, but lvclasses encourage more upfront planning and careful architecture because reworking is pretty painful. This need to plan ahead encourages the waterfall development model, which everyone loves to hate. Jason

Also, LabVIEW ships with this VI: <vi.lib>\Platform\fileVersionInfo.llb\FileVersionInfo.vi which will dig the version number out of your EXE file (it's the same info that you get when right-clicking on the file in Windows Explorer). That's what you should be displaying in your about box etc., rather than some global variable that you save before building. Also you can use property nodes to make sure the EXEs and the Installers have the same version numbers.

We just started using a packed library, for our XControl. We have an XControl which uses a lot of our library VIs, and so whenever that is on any open front panel (i.e. when the xctl is locked), you can't edit any of those subVIs, and that's a major pain. Once the XControl has been tested, you can make a packed library of the whole thing, and then a separate copy of the whole shebang will be running in its own context. Unfortunately, it seems to have make dev environment run slower. It could just be stuff in our XControl, but the same stuff seemed to become more sluggish after the packed library was created, and there are more spikes in CPU usage while using the LV editing system. For us it's still worth it, but the performance hit is unfortunate, assuming it's really the cause of the lvlibp.

Our numbering system is major.minor.build.svn. Every build has a unique tuple of major.minor.build, and that's how we refer to the releases. We try to build all our exes at the same time with a script, so there may be several related EXE's with the same version number, but they have different names and installers. The last number is the SVN revision of the source code repository version from which the EXEs were built. SVN uses a global numbering scheme which always increases. This makes the code traceable. We also steal a page from Linux where odd minor releases are developmental, so 5.3.152.20534 (we'd call it 5.3.152) is yet another test build, whereas 5.4.3.25787 is a release candidate (denoted by "4" being an even number). We ignore the VI revisions.

Well, sure, and your next baseball game might rain out too. But the OP should try to get his or her company to do the right thing, and my point is that one doesn't necessarily have to go it alone. There shouldn't be any reason to contemplate buying your own LV license if you are working for a responsible company. If you are working at a new company and you find out they won't invest in the tools you need to do your job, or that they steal from other companies, that's a sign that you have not found a great place to work.

Also you could enlist the help of your local NI sales rep. You can find out his or her contact info at NI's web site. That person's full-time job is to try to get your employer to buy LabVIEW, so s/he might be really good at that. I have no doubt the rep would like to hear from you. That person pretty much has authority to let you use a full LabVIEW licesnse as long as your company needs while it is making a decision. Jason

If you try to invoke it on a reasonably clean computer, I'd imagine you would get a dialog box saying "This DLL requires the LabVIEW x.x Run-Time Engine." or some such thing. Jason

Lest we forget the obvious, you _have_ already rung up the company's technical department and asked them, right?

You can try the new "UI Builder", but I don't think you can import your existing code http://www.ni.com/uibuilder/

Virtual Machines are your friend!

Couldn't agree more. I goofed that up last week for the 400th time. If NI can detect the error cluster and allow special functionality for that, how hard could it be to fix the Not-a-refnum primitive?

Branches and merges should get a lot better with LV2010 if you separate the compiled code out of the VI file. However, merging may never be easy. Anyone who uses SVN or Hg with text-based languages is not going to have much guidance for us graphical coders. I don't think Hg is a silver bullet and it's quite possible that it may lead to more frequent and more difficult merges of your graphical code.

Here's an LV 8.6 version Populate Ring.vi

Don't you want the "mouse down?" event? Populate Ring.vi

I've been meaning to post this: I've been working on "LabVIEW Project.lvlib" but it's not really ready for prime time. Would be good to have some collaboration. Modify Conditional Symbol.vi