Using Time-Delayed Send to implement a basic state machine in Actor Framework


I’ve had an interesting problem to solve at work this week involving creating, buffering, and then transmitting GPS signals using an NI RFSG but being able to alter those signals on the fly.

For the project as a whole we committed to using the Actor Framework early on as it is quite a complex asynchronous process application with significant inter-process communication with a strong requirement to be able to chop and change modules as well as adding new ones in at run time.

This admittedly could also be done using daemons, but the benefits of Actor such as the robust inter-communication, ease and speed of putting an infrastructure in place and the ability to very easily make an Actor Framework remote controllable and run headless via TCP/IP (which is a very common request from clients) made it a perfect fit for this job.

However, this particular problem also had state machine written all over it, and having tried to use Actor before to do state machines where you have a different VI for each state I have found that they very quickly become very difficult to debug and follow so I thought I’d have a crack at putting together something that would provide all the benefits of Actor and a single VI with a state machine and this is a demo I came up with to prove the design.

It is certainly not the most inspired demo you will ever see, it is simply an overridden Actor Core GUI with a FSM running behind it that simply cycles through states to set 4 colour boxes on the GUI and allow you to start/stop the cycling, and change the interval between each box being set.



On the GUI We have a State indicator which is set from the state machine itself and a Play, Stop, Reset Button, and FSM Interval(ms) control that trigger events in the Actor Core override and enqueue message handlers to be executed on the core.


Actor Core Override






Actor Private Data


The FSM itself is a single VI that holds its state information in the Actor private data and simply iterates from an idle state to 4 states which set the colour of each color box with a one iteration delay between each.


Actor FSM

Now the cool bit, and one of the reasons I really like Actor. To run this as a state machine you use the Time-Delayed Send to instruct the Actor Core to enqueue the state machine at certain intervals.

There are actually two ways you can do this, you can use the Time-Delayed Send with the iterations option set to to 0 – this will enqueue the state machine at a set frequency ad-infinitum which is great, but I personally prefer the option to use Time-Delayed Send with the iterations option set to 1 which means it will do a single enqueue of the specified message with a time delay which I do once in the overriden Actor Core to get the process started, and then at the end of every iteration of the FSM.

My main reason for this preference are primarly debug; If you use the infinite enqueue option (0) and you run the vi that is being enqueued with execution highlighting switched on, messages do not stop getting en-queued in the background so as soon as you turn off highlighting all those messages that have been en-queued will get executed one after another without any delay.

Another reason for my preference is that by en-queuing on each iteration it also means that you can alter you interval rate, so for instance when the state machine is in IDLE I enqueue an element with a delay of 1 second, then when the play button is pressed the interval is set from the from panel FSM Interval control – it is a neat little feature that I can think of many uses for i.e. the classic CLD car wash exam where you have to time each state using an elapsed time vi – well here you could simply use constants for going between states. I have also used Time-Delayed Send quite extensively for data logging use cases where i have found it’s time to be remarkably accurate.

FSM State Enqueuer

FSM State Enqueuer

In terms of the event handlers, well they simply set the next state of the FSM (but could obviously do a lot more) – another really nice feature of Actor in this context is that because all messages are executed in-line with the FSM it makes it very easy to debug and integrate user events with the state machine – although one thing to watch out for here is that if you are putting very small or possibly no delays between your FSM being en-queued for execution, it is worth giving you Event Handler messages high priority to ensure they always get executed as soon as an iteration of the FSM has finished or before if it is in a delayed state.

Play event handler

Play event handler.

Link below for project – possibly obvious, but run to get started – LabVIEW 2013.

Actor Framework Basic FSM Example Project

Hopefully it’s been of use to someone somewhere, and thanks for reading.




Are Professional Certifications Really Worth The Hassle?

A brief blog post….

I am currently sitting on my sofa with way too many windows open on my laptop attempting to cram in as much information as possible for a multiple choice exam tomorrow that if I pass I will be 1/5 of the way toward becoming a National Instruments Certified LabVIEW Embedded Developer (CLED) – the other 4/5ths involve doing a 4 hour practical exam.

I need a bit of respite from the revision, so writing this is it!

This is a new exam being offered by National Instruments and has been born out of the fact that due to the distinct nature of embedded development in the LabVIEW environment having a CLD (Certified LabVIEW Developer) or CLA (Certified LabVIEW Architect) qualification doesn’t really cut it, and supposedly there have been a few issues with CLD’s and CLA’s rolling into companies proclaiming to be LabVIEW experts, working on embedded projects, and royally screwing up which isn’t only bad for the person who has screwed up, but is also not a very positive advert for the CLD and CLA community in general if someone who has jumped all the hurdles, and gone through all the pain in getting the qualifications then cannot actually do the job.

This isn’t all that surprising though. Developing for an embedded target be it a real time controller or an FPGA using LabVIEW involves first throwing out a huge swathe of best practices and habits learned over many years, and returning to basic principles such as working in bits and bytes, configuring registers, managing or at least considering memory yourself, and understanding timing constraints that are more akin to developing in say embedded C – so I think it’s a very positive thing that NI have devised this exam to test people in an embedded environment.

As part of this, NI have invited people from their alliance program to take part in a training course to prep people for the exam taught by the ever brilliant and knowledgeable Mike Bailey, and this is what I have been doing over the past couple of days with 11 other people from around the UK and Europe with all of us desperate to add to the current 7 CLED’s worldwide of which I believe only one is within Europe.

How do I rate my chances? Well it’s not looking too good right now. I’ve just finished doing the sample multiple choice paper and got a respectable 65%, but 5 short of the 70% needed to get through to the practical exam. My weaknesses are fairly clear to see; the exam is based on the real time and FPGA courses – of which I did the prior about 11 years ago, and the latter I did last summer – so no surprise that I only dropped a couple of questions in the FPGA section, and the rest of the marks in the real time section – I have a lot to learn tonight!

As ever when doing these things the question also pops up in my mind of whether all the hassle of doing certifications is really worth it i.e. the late nights revising, the stress, the time away from work taking courses, and the overall effort it takes to maintain a certification once it has been initially achieved –  I mean, I know many software engineers far more successful than I think I’ll ever be and they wouldn’t touch certifications with a barge pole!

I initially decided to go the certification route about 10 years ago. The company I was working for at the time was keen on getting their employees certified and as a young graduate looking to learn and gain expertise as well as to gain the respect of his peers and improve his employment prospects it seemed like a good way to go, and I think gaining the CLD in 2004 and then the CLA for the most part achieved all of this, but 10 years on with almost 13 years of commercial development under my belt is it still really worth me maintaining existing certifications and acquiring new ones when have so much experience I can turn to?

My answer to all these questions (and this is on a personal level and not a rule I feel should be applied to everyone)  is yes – for a number of reasons as follows:-

  • The certifications move with the products, and I believe that to survive as a software developer in most cases you have to keep up to date with the latest and greatest to keep a competitive edge renewing certifications and having to learn or refresh yourself on certain techniques is a great way to do this.
  • No job is forever, and I certainly don’t take my job for granted – we may be busy now where I work and I love the job, but things change rapidly; a few barren months or an undesirable change within the company that causes me to no longer enjoy working there and I could find myself back out on the job market where if things are still recessionary then every way I can differentiate myself from other candidates is welcome, and certification is definitely one way of doing this.
  • Customers like certifications, and it is a good marketing tool to be able to proclaim a number of certified people when bidding for work to give potential clients a certain amount of confidence that if they award you a contract then you have the skills to fulfill it – you’re low risk.
  • I like to have a sense that I am doing a job properly, and by following a certification track and learning best practices and understanding the various pitfalls of doing things a certain way this give me extra confidence that I am doing this. Even if I don’t necessarily always agree with every best practice or guideline, it is a good reference point and if anything, at least makes you think about things a bit more.
  • A major driver for me is simply the fact that I enjoy learning, but find it very difficult to do this without having a target to aim towards or a structure within which to do it, and certifications give me both of these.
  • Dare I say it, but like everyone I have an ego and it’s a nice feeling to be able to say you’ve achieved a qualification and to be able to add a few acronyms to the end of your name or on your LinkedIn profile and I like to think that it gives me a certain amount of authority when being consulted on LabVIEW or TestStand issues – it’s a nice way to re-assure people from the start that you know what you’re talking about.

Are there any drawbacks of certification (apart from the stress, late nights of revision etc!)? Again I’d say the answer to this is yes:

  • For one, there is a danger of Pigeon Holing yourself. I’ve done an awful lot of C, C++, C# Java, embedded etc over my career, but I am known as a LabVIEW and TestStand Architect, and certainly when I have interviewed for non LabVIEW or TestStand jobs this has come up as a problem because people view me as so closely aligned to these development tools that they question my other skills or assume that I am probably at best average when I can provide a decent amount of evidence that I am and would be more than competent in these other languages.
  • Being perceived as an expert can also sometimes be a problem with managing peoples expectations. Some people (mainly non tech savvy) wrongly assume that because you have a certification then you must have super powers and are able to tackle all problems in super fast time and produce consistently top quality output. I obviously strive for all of these qualities, but the truth is that just having a certification doesn’t instantly mean I always achieve all of this or will always be more efficient or deduce a better solution than someone who isn’t certified or won’t make mistakes – if a problem is hard it will be hard for most people, then having a certification is not going to magically diminish that problem – but I have come across this attitude usually accompanied a comment along the lines of  “but you’re a CLA, this should be easy for you”! Arguably a nice position to be in in a funny sort of way though.
  • LabVIEW certification in itself can be a divisive – there are many people in the world who do not consider LabVIEW to be proper programming and almost think it’s like some sort of toy language and so can be very dismissive of the LabVIEW certifications themselves and by extension, your skills. I personally couldn’t disagree with this position more. Certainly LabVIEW is a far more abstracted language than say C++, and definitely has a far lower threshold at which you can become productive with it. In all other aspects though there really isn’t that much difference between developing in C, C++, Java etc and LabVIEW in my experience – they all have their quirks, nuances and pitfalls, but all require that you apply good development techniques to extract the best from them, and all will bite you if you don’t – LabVIEW in some ways more than most as it is very easy to write bad LabVIEW code that works and there are good and bad developers so I think it is wrong to consider it to be a lesser language.

Anyway – enough of my ramblings. back to the revision. Wish me luck.