View Single Post
  #1   Spotlight this post!  
Unread 29-06-2012, 23:56
JohnGilb JohnGilb is offline
Programming Mentor, Drive Mentor
FRC #0488
 
Join Date: Mar 2011
Rookie Year: 2003
Location: Redmond, WA
Posts: 116
JohnGilb has a spectacular aura aboutJohnGilb has a spectacular aura aboutJohnGilb has a spectacular aura about
Cross-VI Communication - best practices?

I'm looking to do some experimentation in the off-season - our team is trying to build an infrastructure that lets us use some sort of interface between VIs, allowing us to quickly "drop in" test code instead of product code.

A simple example would be something like:
Gyro sensor (data source) -> Gyro Data Interface (stores data until needed) -> Drive code which consumes it (data sink)

The idea being we can implement both the data source and data sink independently, as well as letting us switch out the source/sink with test code so we can effectively unit test.

However, we're not sure what is the best way to actually implement this, and we don't know the effective pros & cons of them either.

1) Global variables
Pros: easy to use
Cons: easy to cause race conditions without some sort of protection

2) Functional Global VIs
Pros: All the goodness of functional globals (easy to extend, allows us to change the method of data storage/retrieval without callers knowing)
Cons: Need to spend more time creating a number of VIs for each chunk of data being shared. Also, if there is one data source with multiple data sinks, won't all the callers queue up? I'm worried this could cause delays.

3) Queues/Notifiers
Pros: Don't need to write a lot of infrastructure
Cons: The source and sink need to share a piece of data (the name of the queue/notifier), meaning there is potential for a runtime error that might not be caught at compile time unless we keep a list of that data in a global somewhere. Also, the data source needs to manage what's on top of the queue, since there could be an arbitrary number of callers - this may not be efficient?

4) Events
Pros: Very easy to have one data source and several data sinks
Cons: (This may just be my experience) Writing event infrastructure seems fairly complicated, and involves a lot of objects on the diagram

Are there other types?

Any recommendations for implementation?
Reply With Quote