hooovahh

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.

I'm not one that uses LLBs, so I'm glad I won't likely see this issue in this way, but regardless of how often I'm going to encounter a bug, I'm glad the cause of a bug was found. It had not occurred to me that LabVIEW might have different rules for saving files in an LLB than in the OS. Thank you.

Yeah I thought about a database, and did look into using your SQLite library, but honestly it works, it's human readable, and I haven't had any real problems so I didn't see much of a need to change it yet. I was using the OpenG INI stuff and with very large data structures it was a bit slow so I moved to MGI at some point and haven't had any issues since. I think the coupling between actors would still be there even if I went to a database. The coupling I was referring to could be minimized with several techniques, but the actual format of the file isn't going to change this, other design decisions could. Like if each actor was responsible for doing their own configuration control, but as I said my design didn't go this way, not that this could work. Oh and my setup did have a cancel option, which just wouldn't send out the 1-to-N message that a setting was changed, and it would re-read the config file, and re-write the controls in the pages. One other thing I forgot to mention is some times pages of the config, would rely on other pages of the config. So say I had a page that had a Show Advanced Settings checkbox. If this was on you wanted all the other pages to show the advanced settings if there were any. So when I sent out this 1-to-N message to the actors telling them a config was updated, I would also have that message go to each of the pages, so that they could then re-read from the global the settings from all the other pages, so they could show or hide the advanced settings based on the last applied settings. I used this same message to the pages if you canceled too, because a cancel may revert to some state where the UI in the page needs to be updated. I've thought about cleaning this up and posting it, but since it isn't an NI Actor, it uses a decent amount of the reuse library which would need to be made generic or released.

I don't use the Actor Framework, but do use an actor design (multiple parallel loops that are asynchronous and have dedicated tasks with messaging between). The design you describe sounds like it would work but here is a design I use. There is a configuration actor (module) that handles all the File I/O parts. It has a window just like LabVIEW's Tools >> Options dialog, where there is a listbox of settings, and a subpanel that a VI gets loaded into. The control values are what are saved and loaded into a single INI file. Each page in the config is a separate section in the INI. The page VIs are running, but they don't have to be, they can literally be just a set of controls but some times you want feedback so they run, and listen for the global quit message all actors get and stop if they see it. I also setup a slow polling so if the reference is invalid they pages stop too. This way hitting CTRL+. will stop them too, even though they are also asynchronous. On startup of the program, before any actors are started, a VI is called that loads the INI file and puts all the application settings into a global. Where they can be read but not written. Each actor during its init will read from the global the settings they want. Then when the user opens the config actor, makes a change, and then presses OK or Apply, the control values are all read, then re-written to the INI, and re-written to the global. Then a single message goes out to all actors telling them there are new settings that were applied. This is a 1-to-N message where there is no waiting on responses. In this message is data telling each actor which pages of the config were changed. This way each actor can look at the pages and determine if the data changed, is applicable to them. If I changed a COM port for a power supply, then the power supply actor now needs to cleanup and re-init with the new settings, but the DMM actor doesn't need to do anything. So in my setup one actor handles all File I/O, with the only exception is a single VI that is called before all actors start which does the initial read. Config is done in pages, which are just a collection of VIs and controls. This makes adding new settings easy, just add a new control, then read from the global which is a variant. This way when I add a new setting there is no type defs or controls that need updating, and no new code to write, just add the control to the page VIs, and now that setting is in the INI and global for the rest of the application to read. There is a chance for some runtime errors because of this, but these types of errors you see once in development, then make it the correct type, and never see again. You aren't changing the type of the data mid application. If I have a string data type that is Project Name, I'm not going to change that from a string, so once all the places that I'm reading Project Name are set to string you won't really see any errors again. In your design you mentioned each actor being responsible for their own settings, but I have a few settings that aren't specific to one actor. Under the Advanced page of my config I have a hardware simulation mode. If this is on each actor knows to pretend it is talking to hardware and return random, or semi-random data. I may also have multiple pages for each actor. I have a sequence engine, and it may have multiple sequences that could be in multiple pages, or a single page with a drop down of which sequence to edit. My point is I can have as many settings or as few, which can be shared between actors. A downside of this design comes when you want to just run a single actor without having to run the configuration actor. I realize my design adds some coupling that is generally not desired. So I had some extra code to detect if the configuration actor isn't running, and to use predefined defaults for that actor, if it's not.

Yeah I can't imagine what it is. I think that error is saying those VIs are broken (I only speak English), but the Read/Write Key (Variant) functions don't call out to external code as far as I'm aware. It is all just native configuration file calls, and I don't think has any kind of external DLL calls, which might not have been included in the build by accident. Very odd.

Attached is the VI performing the DLL calls and I think doing the same work as your original VI, notice there isn't anything in terms of error handling so you may want to check the return type to ensure it has no error. It should give you the prototypes you need to call this DLL outside of LabVIEW. Although I've never done this type of thing before, is there some legal notice that should go along with this DLL? I'd assume you are allowed to distribute it since building an EXE in LabVIEW will include it. Encrypt Decrypt Demo Using DLL 2014.vi

Decompiling any NI source is against the terms and conditions you agreed to when you install any NI software.