Ryan Podsim

I would slightly disagree with @ShaunR on 1 point. I would split this into 4 parts, the DAQ, Data storage, UI, and Analysis. I would use a Pub-Sub system here. The DAQ Publishes the data to whoever is listening( idea is the Storage and UI). This so depend on how 'real-time' you system needs to be and how the systems become live. I can see the following layout: DAQ pushes to storage Storage Consumes from DAQ UI pulls from Storage Analysis pulls from Storage Or DAQ pushes to Storage and UI UI consumes from the DAQ Analysis pulls from Storage Separating the Storage from everything will allow you change different elements in the future. Whether you choose pushing to the UI or the UI pulling will depend on your update rates. If you have a high DAQ update rate, then I would suggest having the UI pull from Storage. High meaning over 50 times per second.

I rarely use the accessor unless I need to access that property outside of the class. If I can access it by an un/bundle node I use that.

Done and would be interested in the results.

I don't think VIPM is licensed with GPL either. Either way, I don't think that even applies to the individual packages, if it did then the system would not be usable. It is possible that the library you want to use is GPL, in which case your would be correct. You will need to check the licensing for each library and package to verify. The fact you used VIPM to install the package, I think is irrelevant.

I currently use (drive):/projects as the location for the all projects I work on and (drive):/build for executables and installers. The build location is set by out IT, otherwise LabVIEW builds get seen as viruses. Within Projects I usually use Code, Documents, Prototyping, Test. With the project code under the Code folder; Documents is requirements, design, etc; Prototype is initial design and testing code; with Test used for unit type testing.

I don't quite understand, Why do you need to store Equipment Module in a class that inherits from Equipment Module? Child classes can have access to the Parent's data through accessor functions and don't need to maintain a separate copy of the parent. Also what is the difference between the Interface Equipment Module and the Abstract Equipment Module? As I understand it, neither an Interface nor Abstract class should provide code for the defined functions. I looks to me like that should be one class.

It is because the Button is never changing values. As soon as you click outside of the String, its Value Change event fires opening the dialog. Since the Boolean is set to Latch on Release, the OBD interrupts the Release of the Boolean and never changing the value. Set the Boolean to Latch on Press and you will get both event firing.

3,6,9 Due to data dependency and loop iteration, the calls are sequential. Since the subVI must be a shared clone, only 1 clone is ever needed and thus 1 data space.

Looks good. Unfortunately most stuff I work on is still 32 bit, but I will be making use of this. Request: Can you turn this into a VI package?

Looks really COOL!! Couple notes/issues: Not seeing any footers. Don't know what they should look like, but I don't think I'm seeing them based on the strings in the sample. I don't quite get the "Expand more Details" sample. This may be related to the lack of the footer? Not sure if the Window Title is working since they all say LabVIEW.exe. Is there an option or ability to make the dialog modal? I can certainly see a use for this, I like the idea of using the Windows dialogs. This was tested/used with Win7 SP1 64bit and LabVIEW 2014 32bit Side note: I would recommend using an event structure instead of building an array and using a case structure, this makes associating the button with the VI much easier. Overall, I like it!

Sounds to me like your grandchild class should be a sibling, you will have some duplication of the common code. Either that or you need to refactor your structure to move the special functionality out of your parent class and into a seperate grandchild. Alternately, so you don't have to change a bunch of code, insert a new class between your grandparent and parent. Place the common functionality in the new class.

Just be careful of spaces! More then once I have found errors in my string based SM due to an extra space in the middle or ,more importanly, at the end of the state name; both in the case structure and the constant defining the next state. Over all though, the JKI SM is a handy too; but remember it is just a tool, not a end all, be all method.

I have the same situation. I moved the MDF and Update folder to a secondary drive and have not noticed any problems so far. That was about 2 months ago. I left the NIFPGA, since in place since I figured it was used for compiling. I just looked at the ProgramData\National Instruments\MDF\ProductCache and it's sitting at 800MB, as opposed to the 15GB it was before, so it seems to be repopulating. Anyone know what the MDF folder is for?

Yes these were projects created in 2013. So it seems to just be something on work PC. I tried it at home and it behaves as it always has. Hmm... I did start from a clean slate at work, so didn't migrate the labview.ini. Update: Okay, so the problem seems to be isolated to 2 specific projects. I've semi rebuilt one of the projects and it works, so it looks like I have a corrupted project. As a side note: anyone know an easy way to rebuild/copy a project instead of rebuilding by hand (Save As didn't work)? Update2: The issue is strictly related to have a Target-Host or Host-Target FPGA FIFO that uses Fixed-Point for the data type. I think this is related to an error I had during installation of the FPGA Module and the Fixed-Point determination. Repairing the installation did not help.

I just started using LabVIEW 2014 and one thing hit right away as a major problem. In 2013 and prior when I close the project explorer it closes and unloaded all VIs associated with that project, but 2014 does not that do that. In 2014 all the VIs stay open and I have to close them all before I can get back to the Getting Started window, but that doesn't mean that anything left memory. This becomes an issue if some top level VI is running with a hidden FP, I can close everything I see, but can never get to the Getting Started window since a VI is running forcing me to kill LabVIEW. I'm hoping I'm missing some option somewhere that would close all Project VIs when the Project closes, otherwise I might be sticking with 2013.