Random Ramblings on LabVIEW Design

Self-Managing Designs Make Your Life Easier

Hello Lazy LabVIEW Designers...

Some very common design mistakes occur when your end user wants to set up a complex combination of settings or you are given conflicting requirements. They can be observed in complex UIs with lots of radio and dialog buttons. Complex login schemas are also another sure sign that you are trying to manage complex UI requirements.

Configurable Software

Nearly 20 years ago we stated in our book that constants should be kept in configuration files, at the time we used ini files. Nowadays we use databases but the theory remains the same.

The conversation with the user will often go like this.....

We want this.....but sometimes we want this....every now and again we want this. Programming to these requirements is difficult, unless you put it in configuration and let the user decide.

All of our projects have an SQLite configuration database with a user interface thrown in. It's proven rock solid. You can even version the configurations.

Oh and only use one file for config, use another file for results and maybe another for project settings. But that's about all you need.

Self Describing Databases (DESCRIBE)

One useful facility MYSQL gives you is the DESCRIBE command, it allows you to get table information. This is damn useful for generating generic browsers.

So useful I made an SQLite version, SQLite doesn't have DESCRIBE but it does have "PRAGMA table_info([tablename]);".

Example LabVIEW 2015 Code Attached.....Thank me in beer sometime. And while you're at it buy Dr James Powell a beer to as it is his SQLite toolkit that makes it possible.

Login related databases

One project I'm working on is a Tow Tank in a university. This is like a wind tunnel for ships and has login requirements for a system manager, students and professional studies.

It was getting quite messy with regards what parts of the software should be available for students and which should be available to the professors and engineers for paid studies. All the project info was shared in one database. The solution was to create a new database for each user that would be active when the user logged in. While doing this I needed to make a template database and it needed to be nice compact. Sadly the one I had been testing had grown to 35Mb big and didn't get any smaller when I removed all my test data. Apparently this is a feature in SQLite. The remedy is the rather wonderful VACUUM; command. I love this command so much!! Template database now 196kb.

Now all I need to do is restrict the Admin file menu that creates new users.

That's enough about databases now lets talk about self-describing hardware.

Server side queries

I do a lot of Client/Server applications and one thing I have learnt is when a Client connects to a Server get the server to tell the client all about itself.

One system I have designed keeps all the calibration data on the server (cRIO), again when the client connects it brings all that data back and sets up the client displays accordingly.

Another example is my oscilloscope system. Each Server is a rack full of Digitizers, or even a Laptop full of USB digitizers, when connected they tell the client what version of firmware they are running and what hardware they are running. As part of this they tell the client how it should configure its setting displays.

I really wish NI would do this as part of it's hardware commands, I think they should have all the settings required to write software to them on the card and this data should be queried through Daqmx.

Here's what I want...

I have to talk to a PXIe-5160 Digitizer and when I do a set-up dialog for it I need to know what Vertical Settings are allowed, what time-bases, what triggers and the maximum number of readings per channel. Originally I kept these in the configuration database of the Client. This sucked because a new server with new hardware would need a configuration update. The best I could do was move it to my oscilloscope component in my server. This sucked less but wouldn't it be more elegant to have a get display settings function in DAQmx. This could return a JSON packet giving me all the available time-bases, allowable vertical settings, channel limits etc etc.

It would make designing generic dialogs so much easier!.

PS I don't want this as part of the DAQmx Driver, but as part of the hardware. The part where they store calibration data should have space.

And I don't want this just for Oscilloscopes but as part of all the hardware that NI makes.

Giving More to Do Less

Stored data is essentially free and we can use this to our advantage.

In this example the customer has tried to define a test set-up interface that looks something like this..

It's supposed to describe a test procedure to do repeat switch tests. Sadly the design didn't hold up in the design review to the hidden requirement that needed some of the switch shots to have a different setting than others. This is why prototypes are essential in design reviews,

Instead I suggested that each shot could be individually defined and saved and the dialog interface could be used to define blocks of tests. Each shot setting will be shown in the list box and saved to database.