Go to Post All the powerhouse teams will be having powerhouses dinners with each other in the powerhouse restaurants, probably. - T^2 [more]
Home
Go Back   Chief Delphi > Technical > Programming > NI LabVIEW
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
 
 
Thread Tools Rate Thread Display Modes
Prev Previous Post   Next Post Next
  #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
 


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 10:55.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi