hooovahh

I've certainly worked with other ones, but they mostly all suck for one reason or another. Another issue is all the other cheaper, crappier ones, are so forgettable I don't remember the brand or model. I've heard good things about the BK, but haven't used one programatically before.

Certainly not lots of cases, but even if there are two it is some times easy to update one, and forget about the other. Especially if some other developer is the one maintaining my code.

In this case scripting is your friend. You can have a tool that finds all instances of a type def, that is a constant, and then replace that constant with the updated one. You might have a problem with typed controls that contain that type, that now need to be updated. As for combo box, it isn't terrible, but again if I have a function that really only has three modes I want an enum and then I'll update it later if a 4th mode is added, and every place I have a case structure without that new case being handled, my VI will be broken (assuming no default case which you can do with an enum). With a string you have to have a default case which handles all cases not handled. Also there would be added code to handle if a case is called that doesn't exist, where I know that can't happen with an enum. But again all of this could probably be wrapped in another abstraction layer and these issues could go away with more code.

Yup, there are just some places where rings are so damned convenient. I can have a list of common baud rates for hardware on the UI like 500K, 250K and it translates to a decimal value of 500,000, but then I can have an Other option where the user types in what they want and my code does its best to work with it. Having to translate that back into enums, from enums back to rings, while supporting an "Other" mode, and saving and loading from disk can be a pain. Come to think of it, this would probably be a good place for some OO and classes to handle all of this. But still this is a bit of a band-aid when the IDE could support sparse enums.

While NI takes applications into the project provider, there are some unofficial ways to use it. Of course this comes with no real documentation. It's a bit of a mess really, NI seemingly didn't put in the effort to make this a polished API likely due to the fact that few people would want to do this. Adding items to the menus are a much easier process and in most cases just take putting a VI in the right folder, and then setting it to run when opened. http://digital.ni.com/public.nsf/allkb/2ED4443B186788E18625714000757C03 Oh and while QuickDrop can make the editor a bit easier to use with scripting functions, there are only so may keys you can use, and then there is the fact that you need two shortcut keys to invoke your function. A better idea might be to put something in the tools menu, then invoke it through a single shortcut command. This can't happen today, but there is already an idea exchange item for it.

Based on how seldom the toolbar has changed over the years, I suspect it is not a plugin based design. The buttons you see are the same buttons that have been there (with a few exceptions like cleanup) since 2004 or earlier. If it changes that little, I doubt NI made it a plugin design. You can put things in various menu bar items, like Tools, and File which can be useful for calling VIs to perform actions on the open VI. And there is the Project Provider Framework, which has the ability to add items to the project toolbar, but not many people do this because it can be a pain to work with, and is somewhat incomplete. That being said this is probably a good idea for the Idea Exchange.

Yeah I don't like how the features of one I want in the other. It some times means writing code that will go from a ring, to an enum. Here is an idea exchange for making enums have non-sequential values. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-sparse-enums-to-LabVIEW/idi-p/925224 Even so I would expect a strict-type def ring to update a constant, but I guess it doesn't.

I've had good luck with the Genesys Lambda TDK supplies. Rack mountable, modern, and a few features I don't see in a lot of supplies. We've had cases where we would need 3 power supplies in one test rack. Maybe a low current high voltage, high current high voltage, and low current low voltage. Or there might be designs where we have one power supply for each nest location so each UUT gets a separate supply. Normally for serial devices this would mean one RS-232, or RS-485 for each supply. Or you can go with the more expensive GPIB. But these supplies can be daisy changed and addressed. So one RS-232 port out of a computer can control I think up to 16 supplies. Another neat feature is the quick ability to change out of remote mode which some might see as a hazard but I think it can be disabled. There might be times I would command the supply to something using the software, and then I would want to manually override it with the controls on the front. All you have to do is press the remote/local button and then the controls on the front are enabled. After I command a new output using my software it turns back into remote mode. As for drivers, every Genesys I've used work with the same drivers found here. Pretty clean, and much better than some I've seen in the driver network. It's what I recommend for new systems, and using the same drivers for a large range of capabilities makes swapping them out easy. Of course a IVI compatible supply can say the same thing.

Yup another vote for MGI. I believe it does read/write the whole file so some trickery might be needed to make it as modular as the OpenG calls. The reason it is slow is because the OpenG functions call the NI INI functions under the hood. And each line in the text file is a call to the NI function, where the MGI write their own INI parsing code, and reading and writing is just one call to a file I/O primitive. Basically if you have a file that is 5KB in size or so either will work fine, but if you get clusters of arrays of clusters and your output file is larger than that, then you'll end up with slow downs. Another option I used in the past was to flatten large structures into binary blobs. This would mean the OpenG INI writing would only need one call because that binary section would be just one line. Of course the down side is that data type won't be human readable in the file, and changes to the data type will cause errors, where the INI parsing does a decent job at preserving it.

Topic split. Next time feel free to make a new thread when you have a question which isn't related to the original thread.

Have you used a version of LabVIEW from the past 6 years? It seems your preferred version is 2009. I've used every major version of LabVIEW between 2009 and 2015 on at least one real project, and stability has been the focus more or less for the last few years. It is far from perfect but I think the statement about stability and performance being a focus is true. I think we can agree that the focus certainly hasn't been groundbreaking new features.

Sweet, thanks for sharing.

Yeah I can't remember why I didn't make that method a type def. Regular expression is a good improvement too. Just in most of my situations I have controls named a specific way if I want their references. Like maybe I'll have all controls starting with "Initialize:" for controls that should be shown during an initializing state. Then I can find all controls that start with "Initialize:" and disable them all at once.

I think I saw this error when I was on LAVA from chrome on my phone.

This is probably because a copy of the XNode is in memory. Just like an XControl you can't edit an XNode while it is in memory in another instance. At least I think that is what is going on here. They shouldn't be locked. Neat addition feel free to post your contribution if you get anything working. Super cool BTW.

The truth is I call this place home more than any other, and I suspect I'm not alone. I still learn the most here, I still contribute the most here, and some of the best frank conversations take place here (as shown by this thread) Based on your line of questioning I'd suspect you are having a change of career, or internal struggle. In either case these are going to be very personal feelings, and somewhat unique to your situation. I'm happy, others are happy, if you aren't happy I can see why you might want to change something.

I'm sorry you've been somewhat disconnected from the community. Obviously I'm a bit biased but LAVA and the NI communities serve very different groups. If I was forced to migrate to an NI community I think you'd be harder pressed to find a group like this with as good of code repository, discussion, and light heartedness. LabVIEW in my career is hardly obscure. Job postings I applied for a year ago are still looking for experts. Restructure isn't a terrible idea and a LAVA face lift is a good start.

Well you shouldn't need a license to edit them, they are just XML and can be read in a text editor. I haven't yet figured out how to link to a specific post in this new format, but the New XNode Editor 2012.zip I posted here should allow you to look at all the abilities in an XNode and do some basic editing like add other abilities. EDIT: Oh I figured it out, this is the actual post.

I can't say for certain but I'd say based on what I know, the XNode would need to support this feature. An XNode doesn't inherit from a property node in this case, so methods that cause a property node to be updated, won't work on an XNode, even if its appearance is that of a property node.

"This" is a term I've heard NI use to refer to these types of references. If a reference is a This reference (like the This VI, or This Application, or This Control) then yes closing it is a no-op. The reference simply cannot be closed because it is being used. One way to know if your reference is a This or not, is to cast it to a U32 and look at the refnum. If the number changes with each run of your VI then it is a new reference and should be closed. If it is the same then there isn't a need to close it. I've also done a test where I run the VI using the run continuous and see if the memory in task manager increases. If it doesn't then what ever references I'm opening and is enough for a stable system.

There is no converting it is using both as a tool. You can check out JKI's State Machine for an example of what I was talking about. Or in LabVIEW go to File >> New... and under From Template, Frameworks, Design Patterns there are several to study which use event structures. There's also plenty of white papers on NIs site discussing design patterns.

Yup, the only potential memory leak is if this function opened a new VI reference, but didn't close it, or return it to be closed. The way the function works now, it will take a reference it assumes is already opened and then not close it. Generally if you open a reference, it should be closed in the same place it is opened. But honestly most of the time I use that function it is with a This VI reference which doesn't need to be closed anyway.

The same way you would with any other application. What part of an event structure is making error handling difficult? Generally what I do is put my event structure in a state machine. Then if an error happens go to the error case, where I can take action based on the error. This might mean log it, prompt the user, re-init or whatever.

The VIPM file format is somewhat open. The VIP, VIPC, and OGP files are just zip files, if you rename them zip you can see the file structure. You can unzip these files and in them is a spec file that is plain text which describes the version, the files, where to put them, dependencies, etc. Also in the zip is the actual files organized by groups, and an icon. Long ago I wrote a tool for installing VIP, and OGP files without VIPM, but honestly I saw it as a wasted effort for installing files. VIPM is pretty solid, and it is installed with LabVIEW in most situations. Besides VIPM does other configuration management things like installing dependencies, and checking for compatibility. I agree that VIPM development seems to have slowed down, but what more do you want from it? I'm not a super user of it, but it seems to have all the features I've wanted, and has been stable for several versions.