04-06-2011 01:06 PM - edited 04-06-2011 01:09 PM
@egraham wrote:
They are the same thing. Go to Google and type in "labview functional global" and the first hit should provide an explanation.
I think there is a subtle difference between a Functional Global and an Action Engine.
A FG does not do anything but store a value. It simply has a case to set a data value and another case to get the value. It could be implemented with a boolean for the case selector (but should use an enum) An AE is a FG that performs some kind of action on the data. The case selector is an enum with values like "eat", "sleep", "wake", "speak", "read forum", "count kudos" and "get beer from fridge".
But they are synonymous to most people so you will hear the terms used interchangeably. Unless you are talking to me. But I am probably the exception. [Edit: I just looked at the nugget again and this is explained in the very first sentence]
04-06-2011 01:27 PM
Thanks for the correction. I should be careful about saying they are the same thing since an action engine encompasses a broader range of VIs.
04-06-2011 01:37 PM - edited 04-06-2011 01:41 PM
References are a great idea (queue references )
I prefer queues to functional globals for incoming data because if I am getting data in, I don't want to slow down the write of the data into the FG to be passed to another loop just because that parallel loop has locked up the FG. And remember, if you don't do all your operations within the FG it is still possible to have race conditions. I'd prefer to just stick it in a queue and be done with it so that loop can look for the next chunk of data. Although action engines have many uses, the one I find myself using the most is for managing configuration files. I can have states to read a file, write a file, set new config data, get the config data etc from all over my code and all I have to do is plop down the VI and wire up the corresponding case selector. For instance, in a recent project, I load 9 different config files, but with my Action Engine I can operate on every one of them within the same VI, from anywhere in the code thanks to the beauty of unitialized shift registers.
The way I have discribed it before which I think is beneficial for people coming from a text based background is, think of an action engine as a class, where each case inside is a different method (has the ability to operate on class data), and each unitialized shift register, albeit not private, are class members.
Remember though, different options for passing data between parallel loops often depends on your application. There is not a one-size-fits-all answer.
04-06-2011 02:17 PM
@egraham wrote:
Thanks for the correction. I should be careful about saying they are the same thing since an action engine encompasses a broader range of VIs.
It is not so much of a correction but more of a clarification. You are right that an AE is a FG depending on how you look at it. They are both FGs but one of them does more. It is like saying that mothers and women are the same thing. They are both women but one of them does more.