LabVIEW
What is best: Multiple queues, Global variable, references?
Solved!
Hi.
I'm taking over an application in which the software has to communicate with a distant platform via Wifi.
This was very not well handled and I'm trying to do a better job out of it in a limited amount of time (and experience, please bear with me for any dumb thoughts) as in not redo the whole program, for now.
So here is my situation:
The platform accepts two types of commands: Controls (moving actuators, activating power lines etc.) which doesn't send back any reply whatsoever, and Requests which send a specific reply.
e.g. "0,B2,M, >Data<" This corresponds to "Error_code,CRC,Identifier, Data requested".
The identifier is specific to the request: Request a motor position, Id=M ; Request a Health Check, Id=H etc.
So I'm trying to centralise the communication and the data management into two loops, and then send the appropriate data to the appropriate function. (Originally the guy was handling the comms in every subVIs, IT was terrible to get the appropriate answer)
It looks like this for now and it works fine:
The Communication Loop receives any commands from other loops, send it over the platform, and send the repply (if any) to the Data management loop.
The latter will analyse this reply and convert it, eventually build an array with the data (for graphs for instance) and .... For now send it over a specific cluster. (The "platform general state" cluster isn't used for now I've created it as I wasn't sure if I would need it or not)
My concern now is on how to properly send my data to the proper VIs running in parallel loops: Send automatically the Battery State to the Battery_management.vi etc. The easiest would, I believe, definitely be Global Variables, but I know that with growing arrays this would be terrible.
Should I then just create one queue per "application" (as in Health check, Battery State, Motor status etc.)? This sounds like a lot of queues to me, but probably the best solution? Even maybe using the the unique queue name to be used in different VIs.
I also thought of using references of the appropriate data clusters, not sure that would work though.
Thanks a lot in advance for your suggestions.
Vinny.
@VinnyAstro wrote:
My concern now is on how to properly send my data to the proper VIs running in parallel loops: Send automatically the Battery State to the Battery_management.vi etc. The easiest would, I believe, definitely be Global Variables, but I know that with growing arrays this would be terrible.
Should I then just create one queue per "application" (as in Health check, Battery State, Motor status etc.)? This sounds like a lot of queues to me, but probably the best solution? Even maybe using the the unique queue name to be used in different VIs.
I also thought of using references of the appropriate data clusters, not sure that would work though.
Thanks a lot in advance for your suggestions.
Vinny.
Either use one queue per module so you know where it'll land, or send User Events which has a Module-keyword of sorts, then it's easy for the others to ignore.
The 1st one is probably a Little cleaner but makes you handle multiple queues. The other only uses one User event but requires some simple filtering at consumer side. Take your pick. 🙂
@VinnyAstro wrote:
As I'm not really familiar with User Events (I'm just using the preset one from the NI QMH template to stop the application) I think I'll go for the multiple queues.
What do you think about referencing the queues as they do in this example with a unique name that they use in different VIs?
Would be cleaner in term a threads, but unsure if this is very recommended 🤔
Yeah, that works. Many would create them all in the Main VI and bundle them (which is also a way to have less wires floating about), but both is fine. Just make sure you create a Type def of the data format so if you change it for some reason it's automatically updated in both Main and sub-vis. As to what data to queue, i like a cluster of an Enum of commands and a Variant for general data. I'd have one for each queue as the Enum is unique. If you want it even more general many go for String+Variant, that way you can have the same format for all.
@Yamaeda wrote:Yeah, that works. Many would create them all in the Main VI and bundle them (which is also a way to have less wires floating about), but both is fine. Just make sure you create a Type def of the data format so if you change it for some reason it's automatically updated in both Main and sub-vis. As to what data to queue, i like a cluster of an Enum of commands and a Variant for general data. I'd have one for each queue as the Enum is unique. If you want it even more general many go for String+Variant, that way you can have the same format for all.
Yep so I've started already creating them in the main VI (Data management Loop under the Init case) and bundle them in a cluster I'll pass along the different cases (modules for Health check, battery etc.)
For the Data type, I'm used to a cluster of String+variant, but I guess an enum is more fault-proof.
What do you mean by Data format though? The data type in each queues?
Here's what I started with so far, I'm thinking of including the queues names in the cluster type def in case I change them (Is that what you meant with Data type?)
I'll get rid of the platform general state which is useless in the end. Also, I've figured I don't need that much queues as a lot of data can be (and are) gathered in the same VIs. For example the platform attitude takes in 3 different answers (Gyro, inclinometer and Motor position) but only one queue is necessary.)
Vinny.
@VinnyAstro wrote:What do you think about referencing the queues as they do in this example with a unique name that they use in different VIs?
Would be cleaner in term a threads, but unsure if this is very recommended 🤔
Naming those queues is not needed, and has disadvantages.
The queue references can (should) simply be passed. So the main creates them (unnamed) and passes them to the users. Or the modules create them, and pass them to the main (using a (unnamed) queue, DVR, control ref, whatever).
I've seen it go bad, where the names of the VIs where used for queues, and a library also used 'Main" as a queue name. There wasn't an error, as the types matched. Just funky behavior.
I wouldn't worry about it too much, since you are in a hurry, but be warned... This might come back to hunt you.
Search LabVIEW like a graph!
@VinnyAstro wrote:
wiebe@CARYA wrote:Naming those queues is not needed, and has disadvantages.
The queue references can (should) simply be passed. So the main creates them (unnamed) and passes them to the users. Or the modules create them, and pass them to the main (using a (unnamed) queue, DVR, control ref, whatever).
I've seen it go bad, where the names of the VIs where used for queues, and a library also used 'Main" as a queue name. There wasn't an error, as the types matched. Just funky behavior.
I wouldn't worry about it too much, since you are in a hurry, but be warned... This might come back to hunt you.
Good to know thanks.
But yep, given the rest of the main vi, if I can avoid more mess in it, my eyes and brain would be glad. (You can have just an overview of how horrific this code is right now here) I'm sure you'll understand my choice 😋
But as soon as this is over, I'll wipe it and start fresh 🙂
That was pretty much the standard before LabVIEW 7.1.
The event structures, classes and control references where not always there...
Of course a more logical explanation is the programmer simply didn't know what (s)he was doing.
@VinnyAstro wrote:
wiebe@CARYA wrote:
Of course a more logical explanation is the programmer simply didn't know what (s)he was doing.
Yep, I'm not blaming him, he basically learned LV developing this application in a limited amount of time a while ago. But I still have to deal with his code now 😑
The irony is that he probably wasn't lazy enough.
It takes great determination to make a program that way, knowingly copy-pasting everything over and over, and repeatedly applying changes to all the copies. A programmer* would have stopped, to reflect, learn or cheat.
* A programmer being not just someone that programs, but someone with a programmer's spirit.
If it helps, I've seen worse 🙄.
