Leaderboard

NI Week was a blast and while there I got to mention a few things I was trying that I'd like to share with the community. One of them is this thing I'm calling a Multi Panel Interface (MPI). The code is rough around the edges, very rough. This is probably the least polished code I've posted in a long time but this code has been sitting in a half working state for a while, and if I took the time to clean it up, it might never be ready. So please be gentle, there's room for improvement but I think the basics are there. Now with that out of the way here's what I got. I wanted to make an interface similar to Veristand. I don't want to re-create the wheel when it isn't necessary but anyone who has worked with Veristand knows that there are quite a few limitations, and as a result I started developing a UI that is dynamic. So that controls and indicators can be added and setup in way that could be saved and loaded for different operator types. This would be setting and getting event based information from Actors running asynchronously. Implementation It is a publisher subscriber architecture. Here there are actors for each set of hardware we care to read from. Later we could talk about controlling Actors but for now lets just talk reading. So for example there maybe an Actor for CAN, Power Supply, AIO, DIO, FPGA, Real-Time (talking to another PC), UPS, etc. Each Actor has a functional global that describes what data it has for other panels to display. For the time lets call any data an Actor is publishing a "channel". An Actor will publish the channel data to user events, and in a global it will have the list of user events and their names so they can be subscribed to. The actual messaging system between the Actors and the Panels can be anything and in my demo I actually just have random numbers because the demo isn't meant to showcase the messaging it is meant to showcase the UI. UI The purpose of the demo posted is to show that a tabbed interface can be made, and be made semi-dynamically. There are 3 things to be defined to understand what is going on. The Parent VI, the Panel VI, and the Child VI. In the demo the Parent is the top level "Main.vi". Clicking the "Add" button will add a Panel VI which is a shell of a VI that has controls to minimize, pop out, and control menus to the Child. The Panel has a subpanel that contains the Child VI. The Child VI in this demo is only a graph showing random data. The Child VI is tied to the Panel VI using a subpanel. The Panel VI is tied to the Parent VI using Windows user32.dll function calls. The user can interact with the Child anyway the child defines. There is no right click override (like in Veristand) where you can no longer right click on a graph and get a menu. The Parent VI also has little restrictions. It is a normal VI with a menu bar which can be used for things like managing Panels. In the demo there is also tabs in the Parent. They are fake tabs in that there are 20 but the ones not being used are hidden. There are neat UI elements that are hard to describe in text. Things like docking/undocking Panels, minimizing Panels while docked or not, resizing Panels while docked or not, moving panels quickly and easily, renaming panels, intuitively adding tabs while moving panels. These are the basics that I didn't know if I could do so I did first. The messaging I described before is not difficult it just takes some time to define how Actors talk and how Panels subscribe to the data. I know there are some UI bugs. The biggest one that you'll notice is trying to move a Panel when docked will have some z-order issues with other Panels that are docked, but there are others. Code The actual code in the demo uses several pieces of code I've found. The parent child idea I originally saw in the Dynapanels demo. Then there are several user32 functions from the Windows API. Panel controls were from UI Panels. OpenG Array, Error, and Application Control is needed, I'm not sure if there are others. http://screencast.com/t/P9SJ1anR Please feel free to comment and use as you see fit. Just know I won't be supporting this as a real project. Multi Panel Interface.zip

Name: Circular Buffer Submitter: hooovahh Submitted: 24 Sep 2014 Category: XNodes LabVIEW Version: 2011License Type: BSD (Most common) Description This package contains functions for maintaining a circular buffer. Create the Circular Buffer using the Initialize Circular Buffer function. This makes a DVR, and the data type of the DVR changes based on the data type specified for the circular buffer. The data type can be any type as long as it is not an array. It must be a scalar. The size of the buffer is specified on initialization but can be changed using the Change Circular Buffer Size function. Add data to the circular buffer using the Write Circular Buffer function. Scalar values can be added, or a 1D array of data can be added. The data type of the values to be written is the data type defined in the initialize function. Read the data back out of the circular buffer using the Read Circular Buffer function. The data type of the read values will be the data type defined in the initialize function. Cleanup the program by destroying the DVR on exit. An example VI Circular Buffer Demo shows how a Circular Buffer can be used. XNode Disclaimer The Initialize, Read, Write, Get Status, and Change Size functions are implemented as XNodes. NI does not provide support XNode development. For an introduction to XNodes read Adam Rofer's "XNodes - A Crash Course" presentation (http://lavag.org/files/file/56-xnodes-a-crash-course-powerpoint). Dependencies LAVA Palette-1.0.0.1 How It Works The source is all open and the template VIs for each XNode is what is executed when the XNode is generated. This means you are welcome to try to further optimize these XNodes by editing the templates. A new instance of the XNode will need to be placed which will force the new code to be used. If anyone finds performance improvements for these functions please feel free to post in the support topic. Because the size of the buffer is practically unbounded, I wanted to avoid unnecessary data copies, which is why it is designed around DVRs. There exists 3 things in the DVR, the buffer size, a pointer to the current write location in that buffer, and the array of scalar values, whos data type is defined during the initialization. Click here to download this file

I have written a paper on the Strategy Pattern (with appendices on Interfaces and the Factory Method Pattern) in the hope that this will be a useful guide to others. We have published a PDF version of the paper: StrategyPatternWithLabVIEW and a zip file that also includes the source and model: StrategyPatternWithLabVIEW--WithModelAndSource. You can comment on the paper here, if you like. Paul