Using shared variables instead of global variables
 

This year we have a big amount of global variables and it becomes hard to find the one I need each time.
Separating the variables to different global variables also isn't ideal because I have to drag the correct one and only then choose the one I'm looking for.

I've noticed that shared variables can be chosen very easily by library and I wish to use them instead.

What are the differences between those two types?
Is one of them more efficient than the other?

Thanks!

Re: Using shared variables instead of global variables
 

The Shared Variable is meant for sharing data over a network while hiding the network implementation. I can't speak much to the performance, but I can recommend other ways to help.

Ideally you should try to reduce the number of global variables that you use in the first place. If you are getting lost in the number of global variables that you are using, you are probably using too many. There are a number of ways to reduce the number of globals.

The easiest way would be to send a cluster using the global, instead of using single data types and multiple globals.

If you want to get into the more advanced LabVIEW topics, you can change your architecture to use other message passing schemes (Notifiers, Queues etc). Depending on your implementation, you could possibly get away with not using any global variables at all.

Re: Using shared variables instead of global variables
 

We are working with state machines so that we have a state machine for every sub-system on the robot. for example: Tote grabbing arms
For each state machine we have commands/actions like open or close.

Then, in the Teleop.vi we send different commands to the state machines which run in parallel, based on driver's input.

*We have an enum typeDef for each state machine and for each set of actions.

for example:
the grabber state machine is in close state,
pressing button 1 sends "open" to the grabber state machine,
the grabber state machines then moves to "moving to open" state,
and when it detects it reached the target it moves to "open".

Which architecture do you recommend using?

Re: Using shared variables instead of global variables
 

The big difference is that global variables are scoped to your application, specifically the target context within your application. Shared variables are shared between computers, between processes, and that brings a decent amount of overhead with it. I know teams who successfully use them, but we don't use them for the default framework because global variables are all most teams need.

Greg McKaskle

Re: Using shared variables instead of global variables
 

My previous post was open in my editor for quite awhile, so was largely redundant by the time I pressed the button.

Responding to your newer post, I think it will help if you can put the inputs to a state machine into a cluster. Put the outputs into a cluster as well. This will probably cut down by a factor of eight to ten.

In some code I've done that sounds similar, I also moved most of these globals into what we call a functional global. This is sometimes called a LV2 style global. It is a function with state data that has operations such as read and write, but sometimes read/and/clear, or append and remove. Anyway, these functions are often a good way to clean up scattered sets of globals into a small intelligent object that stores the data and makes access safe for a parallel language.

Greg McKaskle

Re: Using shared variables instead of global variables
 

I don't see the connection between state machines and global variables. A state machine keeps its own state, and shouldn't need to share it with anything else, right?

If it's just persistent storage you're looking for, I suggest putting the state machine inside a single-run While with a shift register. There are at least three other ways I can think of to do what I assume you want, including local variables.

Some state machines do different things depending on the state of other state machines, so I use global variables in order to read other state machines' current state.

Re: Using shared variables instead of global variables
 

That sounds like it could get confusing. No wonder you're having difficulty finding things. I can understand how it can be helpful to encapsulate groups of states into their own machine, but you probably see now that it's often a false optimization to do it from the bottom up (or the inside out, depending on your perspective).

I know there's not a lot of time left, and you've probably put a lot of effort into what you already have, so I won't seriously suggest refactoring your code so there aren't so many intersystem connections. But next time you do something similar, I hope you'll be able to come up with a less tangled architecture.