Blog Of The Month !

A little late in announcing this but back in November we were declared NI’s Community Blog Of The Month ! !

Towards more reliable code – FGV’s

During a recent LabVIEW user group meeting in the UK I was reminded of one of the best tips that can help prevent bugs from creeping in to your code. This was a tip of the un-documented , seldom quoted , often overlooked but oh so valuable kind.

Given that the person reminding me was a published CLA of long standing and one of the UK’s strongest advocates (and producers) of structured , well designed code I shouldn’t have been surprised.

So what was this nugget of information, something related to LVOOP or queues or some other advanced architecture ? Hardly.

This tip centred around the use of FGVs (Functional Global Variables).

So to quickly recap, FGVs utilise the behaviour of uninitialized shift registers to provide a globally scoped, persistent storage mechanism (this can be replaced with the Feedback node in more recent versions of LabVIEW and I’ve shown this method in my images)

I have witnessed all kinds of weird and wonderfully convoluted techniques for providing protection to critical sections of code but I can’t think of a more straightforward technique than using FGVs especially for new and intermediate level users.

FGVs are not immune to errors however (and can often introduce their own in addition to compromising a design if not used carefully but more of that in another post)

They must be set for non-reentrant execution to ensure that they can only be called (ie. read from or written to) from one location in the hierarchy at a time.

The tip that I was reminded of was regarding the wiring of the Function Control Input of the FGV (usually an Enum).

Usually the allowable states of the functional Global are contained in the Enum, typically with names such as Get, Set, Increment, initialize, the list goes on.

FGV Function Selector (Enum)

This enum the provides the states for the case structure inside the FGV.

Case structure states come from Enum control

Now, because the case is selected by an enum there is a right-click option to “Add Case For Every Value”, if this is selected then case structure does not need a default case defined as all possible input values are catered for. So what happens if you forget to provide an input wire for your FGV ?

In the above case the calling vi will execute (it’s not broken) however the FGV will execute the case that matches up to the first item in the enum (item index 0, unless one of the other items is set as the default value for that particular control).  In the example above the input value of 5.8 will essentially be ignored and the “Get” case will be executed. This could lead to problems later in the program where the value of 5.8 has not actually be written to the FGV.

To me, this is not obvious and may cause unexpected behaviour, also it’s less readable and may be confusing to somebody not familiar with the code. Therefore part 1 of the tip I received is to ALWAYS set the connector pane terminal for this input to REQUIRED. This effectively breaks any vi that calls the FGV but does not provide this input.

Unwired "required" input causes error

The next part of this tip is really a belt and braces approach. Try adding an extra state to the enum control titled “Error” and make this state the default. The code contained within this state just raises an error and passes it forward. This guards against the user simply dropping the FGV on a block diagram and using the Create > Create Constant option without specifying a valid state.

Create a default error state

Gives this a try the next time you find yourself creating a functional global variable and hopefully remove another potential for unwanted behaviour.

STOP PRESS – European CLA Summit Date Change

Please be aware that the dates for the 2012 European CLA Summit have changed.

The event will be held at the new (and really lovely) NI UK Office in Newbury on Weds 28th and Thurs 29th of March 2012 and is not to be missed.

Make sure you’re there (if you’re a CLA that is)

 

 

Getting (and remaining) certified part 1

So, anybody who has spoken to me for any length of time about LabVIEW knows how strongly I feel about getting Certified. Now before I get flamed let me point out that I do not believe that not being certified means you are a bad developer, on the contrary I know several great developers with many years of LabVIEW development under their belts whom are not certified. I didn’t take the plunge myself until 2006 having used LabVIEW since version 3.1

What I will say is that I think the process of preparing to take the various levels of certification will expose a developer to topics, styles and architectures that they may not be aware of but which are key if they are to take their development to the next level and truly leverage the power of LabVIEW (disclaimer: I do not work for National Instruments and neither am I being paid for the contents of this article !)

Let me explain my viewpoint through a few examples;

Back in 2006 whilst preparing for the Certified LabVIEW Associate Developer (or CLAD) exam I took it upon myself to read several of the more well know LabVIEW text books to refresh my knowledge of LabVIEWs lesser known features (that I fully expected NI to ask me about in an exam situation)

One such feature was Scan From String. Now like many developers I am sure, I use this function regularly (and it’s partner; Format Into String) when parsing or formatting Strings that are to be sent (or have been received) from instrumentation.

Well, did you know that these functions can handle boolean values as well as numeric data and enumerations ? Well at the time I didn’t. Often I would place the strings “TRUE’ or “FALSE’ in a case structure and allow a boolean to decide which case executed in order to get the desired string.

Turns out there’s a much cleaner way to do this. %s when used as the format specifier will create a TRUE or FALSE string, %d will create a 1 or 0 (as a string).

Format Into String Works With Boolean Type

Another one is the “Switcheroo” tool. If you want to swap the (already wired) inputs of a dual input primitive, say the Subtract numeric function there’s no need to delete the wired inputs and re-create. Simply holding down the ALT key when hovering over one of the terminals with the wiring tool will switch to the “Switcheroo” tool and subsequently clicking on a terminal will swap the inputs.

OK, so neither of these little tips is going to change your world but with regular use they become second nature and might save you a little time.

So there we have it, two previously unknown tips that I discovered and still use to this day. In addition to these I refreshed my knowledge on the correct way to build arrays and complex data times in order to minimise system resources, the various ways to assemble data prior to passing to LabVIEWs many and varied graph / chart types and although neither the ‘Switcheroo’ or Scan From String features came up in the exam itself I was able to impress my friends !

So being a CLAD did make ‘ME’ a better programmer.

In a future article I’m going to take a look at the CLD and CLA Certifications.

NI Days = Happy Days

So it’s that time of the year again and NI Days UK will be taking place on Wednesday 9th of November at the Queen Elizabeth II Conference Centre.

Whilst not quite as large as NI Week, NI Days still offers a great opportunity for previewing new devices and software, watching some great presentations, meeting with 3rd party solutions providers and generally getting to talk to like-minded scientists, engineers and other community members about all things NI.

Personally I am excited to be able to catch up with people I haven’t seem for a little while and find out what they’re up to.

The weather however will not be the same as that experienced during NI Week !

Hope to see you there.

Calling all CLAs to Europe’s first CLA Summit

If you’re a Certified LabVIEW Architect and you can get yourself to Newbury, England on the 19th and 20th of March 2012 then I strongly recommend that you attend the Certified LabVIEW Architects (CLA) Summit event being held at National Instruments UK headquarters.

Of course, you should make every effort to get to the US event in Austin held at NI headquarters on the 6th thru 8th of March but for some European CLAs that’s a little too far out-of-the-way.

Read more about these events here;

https://decibel.ni.com/content/groups/certified-labview-architects

Having attended previous Summits in Austin I can tell you that they are an invaluable learning and networking experience for all CLAs and as in previous year both of the events are being chaired by enthusiastic and knowledgable people.

Read Justin Goeres’ 5 reasons why you should attend the CLA Summit article here;

Not only would I agreed whole heartedly agree with Justin’s comments but would also add that throughout the event there will be opportunities to meet and discuss with the development team who actually create LabVIEW, just being able to meet with the person who created favourite features such as Quick Drop and the LabVIEW GSW is a privilege and can provide real insight into features that you’ve maybe not fully understood or thought were a little “quirky”

LabVIEW is a feature rich development environment, I’m constantly learning new tips for debugging or techniques for developing more quickly, this event is like super concentrated tips & tricks.

After attending last years event I came back energized and armed with a ton of new ideas for inter-process communication (the theme for the event) that probably contributed to me learning more about large-scale application architecture than at any other time in my LabVIEW career.

I am excited about the 2012 events. I hope you are able to attend at least one of them.

Going LOOPy

So after many years using LabVIEW and a few months of dabbling with LVOOP, I decided to take the plunge and buy the “Object Oriented Design And Programming In LabVIEW” training course from NI. Unfortunately this course is not available as a classroom taught course in the UK so I had to take part in an online course. This seemed like a good idea until I found out that the course started at 13:00 hours CST, that 19:00 GMT giving a closing time of around 23:00. Suffice to say it’s late to be learning new stuff !

First impressions were that the course material was very well presented and thought out. Certainly the worked examples were very relevant and got me up to speed quickly.

OK so I had figured most of it out during my exploration prior to the course but there were still a few gems shared during the course that I am sure will prove useful.

If you continue to follow this blog, over the coming weeks I am going to be putting my new found skills into practice with the development of a few resue libraries that I’ve wanted to refactor using LVOOP before making them available to the wider community. Stay tuned.