LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Tag channel solution

Solved!
Go to solution
Highlighted

I'm attempting to implement a solution that was put forward at this link.  I installed the DSC module to be able to access the Tag Channel functionality.  When i test the top loop with a random number the error output on the Write Tag is '1026 bad reference'.  Am I using the correct tag functionality that was proposed in the linked solution?  Have more tag parameters been implemented in 2019 that didn't exist when @Bob_Schor posted the orig solution?

 

Thanks!

Ben

 

tag-channel.png

0 Kudos
Message 1 of 5
(158 Views)
Solution
Accepted by topic author beneeto

I'd be vary wary of this @Bob_Schor guy -- he has a reputation as a Channel Wire Enthusiast, which may blind him to some of their idiosynchracies (and there are a few ...).

 

Some comments:

  • Channel Wires, introduced in LabVIEW 2016, have nothing to do with the DSC Module, but are part of basic LabVIEW (like Queues, User Events, Arrays, etc.).
  • The point of a Channel Wire is that they provide Asynchronous Data Transfers, but use a "Pipe" metaphor that follows the "path of the data" (i.e. the data flow out from the Writer to the right in a "Pipe" that starts out pointing to the right and "jumps over the edge" of Structures), in contrast to a Queue (Reference) that comes in from the left, with the enqueued data going "backwards" to the Queue's branch point and on to the Dequeue function.
  • The different types of Channel Wire correspond to different "needs" for Asynchronous Communication.
    • Stream -- lossless point-to-point non-branching communication, think Producer/Consumer.
    • Tag -- many-to-many "most recent element" communication, not unlike Notifiers.
    • Messenger -- many-to-many lossless communication, though more commonly many-to-one, like a Message Queue in the Queued Message Handler.
    • LabVIEW 2017 added the Event Messenger, a Message Channel that can generate a User Event, handy for passing data into an Event Loop.
  • Channel Wires have only a Writer (which creates the Channel and sends the data) and a Reader (which receives the data), so easier to create than Queues, Notifiers, User Events, etc.
  • Channel Endpoints often have additional inputs that simplifies synchronization and "termination" (such as the "Last Element?" inputs of Stream Channels -- set it True in the Producer when you stop the Producer Loop, and use the Last Element? output of the Reader to stop the Consumer Loop safely).
  • A Channel Wire cannot cross a Structure

So the question is, what are your Parallel Loops, what data need to flow between them, and how are the loops synchronized?  This will determine which Channel Wire is appropriate for which task, and will suggest how to use them.

 

     I have it on Good Authority that most non-trivial applications that Bob Schor has developed over the last 4 years have used a lot of Channel Wires (probably a dozen per applications).  They have all been the "Vanilla" flavor, i.e. no "with Abort", "Ack" or (isn't there another option on some of them?).  Most of them have been Messenger Channels, as he (I presume it's a "he") has grown fond of a Channel-version of the Queued Message Handler he calls the CMH (guess what "C" stands for).  Some Producer/Consumer Loop pairs also use a Messenger Channel, particularly if the Consumer needs Initialization (which means that it gets an "Initialize" message, then a whole series of "Save" or "Plot" or "Average" Messages from the Main CMH containing in the Data part of the Message the Data to Save, Plot, or Average, i.e. the Data to "consume").

 

     Some Producer/Consumer structures are much simpler -- a simple "Save All to Disk" is commonly done with a Stream, with the Consumer having a "On First Call" Case Statement inside its Consumer Loop that opens the Data File for writing when first called.  Note that since the Producer will eventually send the Consumer the "Last Element?" flag set to True (if nowhere else, then when the Producer exits), the code to close the Data File can be placed after the Consumer exits (as it has its Last Element? flag wired to the While Loop's Stop indicator).

 

     If you still have questions or need more help, Bob_Schor will probably be willing to look at your code (warning -- he won't look at a picture of a Block Diagram, some strange phobia, I guess, so attach the actual VI or VIs).

 

An Anonymous Channel Enthusiast

 

Message 2 of 5
(123 Views)

Thanks for the very detailed description, I'm still trying to absorb alot of it. 

 

The parallel loops are reading cDAQ modules, one RS485 device, and a GPIB device (GPIB not implemented yet).  I may try to combine the RS485 and GPIB loops and pipe the resulting data into the cDAQ loop using the channel writer.  I haven't thought much about how the loops are synchronized, i don't have any wait timers on either of the data input loops.  This kinda begs the question why have separate loops at all.

 

That didn't stop me from implementing something for the sake of understanding.  To test i just wired in the random number generator to a tag Channel writer/reader.  All I'm trying to do is pass in some status of the RS485 device, manipulate the data in the Analysis loop, and then write it to the same TDMS where the CDAQ data is getting logged.  It seems like everything is working properly the way that I have thing setup, though i'm not sure about how the data is synched.  I've attached a log file from a test that shows 322 pts collected.  When i plot data from the Channel Writer (RS485 group, Untitled channel) against any of the other cDAQ channels they don't look synched.  The same number of data points are listed for both groups of data but when i drag the cursor over any of the cDAQ data, but something seems up with synch between data points. 

 

I've attached a vi and the tdms file for ACE (Anon Channel Enthusiast) to look at.   

0 Kudos
Message 3 of 5
(66 Views)

Actually went back and added a sequence around the tag Channel reader and the bundle just to follow-thru with the original solution.  It didn't change anything with the way the data looks.  

0 Kudos
Message 4 of 5
(59 Views)

I have a feeling that the way I'm writing the data to the tdms file is the reason why i'm not data points synched up properly.  Pretty sure that's outside the scope of this conversation.

0 Kudos
Message 5 of 5
(58 Views)