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.

I work in a small but important corner of the company that does not require security clearance. I assume there would be more options available to me if I obtain clearance, exactly what those opportunities are is hard to say since they are secret. I have been a very good performer so far, perhaps I can request it as a perk even if my current job does not require it.

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.

3. SO systems can use queues for passing messages. PS systems must use user events. Writing apps where some components use users events to send messages and some components use queues to send messages is kind of ugly.

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.

First, it's not a bug. To clarify, while it is undesirable behavior from the developer's point of view, it's not a "bug" in that the cluster and bundle/unbundle source code is faulty. Rather, it is an inherent design limitation due to clusters not maintaining a history of their changes. The issues arise because people use typedeffed clusters in ways that (probably) were not originally intended--namely, as a robust mechanism to pass data between independent components.

Second, NI has already implemented the solution. Classes. There may be some bugs in Labview's OOP code, but they will be fixed over time. It's unlikely clusters will ever be "fixed."

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.

I thought the terminology was different - i.e. a tag being a bookmark of code (revisions), and branch being actually code?

But like I said I don't use SVN (only dabled with it wrt SF).

In Perforce bookmarks are called labels, branches are branches.

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.

So tying back to Dave's question, are you saying that you prefer to jump versions of releases to clients e.g. 5.0.0 (rtm), 5.0.1 (internal test), 5.0.2 (internal test), 5.0.3 (internal test), 5.0.4 (rtm) etc.... ?

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.

(I don't use SVN) But wouldn't using a label (tag) be a good idea?

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

Everyone still on SVN?

Using Hg, you get a GUID (4 words Hex), that identifies the code (a branch in any repo somewhere). Thats more acccurate in a branching enviornment than the current rev.

And then just make the 5.0 a shining decoration without real meaning.

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)"?

Here's a little snippet on how you can use this code:

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.

I like to do this too. One thing I haven't figured out is how number a test build for a new major release. I'd like the released build to be version 5.0.0, but then I run into the irritating mathematical property that any version number less than 5.0.0 is part of the version number set defined by 4.x.y, which defeats the purpose of using the major version number. How do you deal with that?

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.

I guess that is why the build number can be important.

E.g Test App: 5.0.0.123; RTM App: 5.0.0.234.

Your new App is of the 5.0.0 version and the build number can either be transparent to your clients or included (whatever is preferred).

But your comparison logic will not fail.

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.

I would like to settle on a consistent version management method that will give me basic version numbering on the software components in my system.

I have 3 types of HMI (windows) and 2 flavors of cRIO code. I would like to have one global software version embedded in each exe so that it can be locally and remotely verified.

The problem I have is how to reconcile all the different version numbers that exist such as the SVN revision, the LV build revision, LV VI revisions and now

an additional project based version vi that I am starting to include for all builds.

I was hoping to hear from others who have navigated these waters before and might

have some tips to offer.

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.

This can backfire quite spectacularly...

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.

My problem at the moment is i've got a new job which starts tomorrow. But they may not necessarily buy Labview immediately, thats one of the reasons why i'm looking into my own license.

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

I have created one DLL through labVIEW long back, now i want to know from which version of Labview it is created......Is it possible to identify?????

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

Assuming your device has a 32-bit counter... >> For example if your device uses a 19.6608 MHz clock source and a 32 bit counter, your dt will be 5.08626e-8 and your maximum time will be 218.4533, all within the error of the clock source of course. 19.6608 MHz was the closet common timing chip/crystal I could find based on your values and the assumption of a 32-bit counter.

If you can open up the serial device you may be able to easily identify the clock source and lookup its frequency. Be aware of voiding any warranty.

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/

Actually, I've currently got 3 LV licenses, all with SSPs. It was more a matter of finding a box to install them on. But last week I remastered a laptop and have done a clean install of LV2010. Hopefully I'll get some time in the next couple weeks to do some testing. Then I need to find a spare 64-bit machine somewhere and see how *that* works...

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?

I have been using TortoiseSVN and I gave up long time ago on branches and merges. It was a nightmare, the Fogcreek guys made it sound like in Mercurial this was not an issue and they use TortoiseHg, which would make the transition easy. I will just need to remember that there is an extra layer involved and push/pull needs to be done besides the commit/update. They also mentioned a tool that converts a SVN repository into a Hg repository.

Anyway, before going on this "adventure", I wanted to make sure I asked you guys how it has been working for you. Should I stay on SVN? or jump on Mercurial?

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 use several conditional disable symbols in my project. I'd like to create a build script for each spec that sets the symbols to a value appropriate for that build. Is there a way to retrieve the symbol names and values using scripting or vi server? This is as far as I got when I realized I have no idea how to proceed...

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