I was looking for something like this to save me some work, but it doesn't seem to do exactly what I want. I was wondering if you could recommend something that might fit the bill for me, or a way of utilizing this that will get me where I want to be.
I need to collect data from multiple sources, and be able to read it from multiple sinks. BVT seems to solve the first problem, but not the second. There are a number of data acquisition sources in the program I am working on, and data must be delivered to logging engines, display components, and potentially a few other places. I'd like to be able to send the data to every sink knowing that no samples will be lost. I can create a separate queue for each sink, but that seems inefficient from a memory standpoint.
I believe I understand what you want, but it is not clear to me how the different processes/sinks access the data.
Are the sinks asynchronous from each other?
If the sinks are asynchronous, meaning that they access the data at different rates, the easiest way to implement what you want is with a queue per sink. Any other implementation would require some type of synchronization to know when it is OK to remove elements from the queue.
If the sinks are synchronous and you just need to be able to read the entire queue on each sink, then you can use the Queue Status function located in the queues palette. This function allows you to preview the entire queue without removing its elements. This way all sinks can have access to all the data and by being synchronous, it would be easier to know when it is ok to remove the elements from the queue. This function is not part of the BVT but I can help you add it.
If these two scenarios do not represent what you need, please describe a bit more what the sinks are (data logger, FFTs, etc) and how they access the data so that I can give you a better suggestion.
Thanks Ricardo. I ended up doing exactly what you suggested; I just used a separate queue for each sink. The access is asynchronous. It doesn't seem elegant or scalable, but it works.
I think I see what you mean about using BVT for synchronous reads from multiple sinks. I could essentially preview the entire buffer in all syncs, and then use a separate message (rendevous?) to control when to purge the buffer. I'll keep that in mind for the future.
I make a request about a downgrade for BVT library from LV 2009 to LV 8.6.1.
I am waiting for your answer about this request.
Here is the 8.6 version. Let me know if you run into any problem
Thanks for your quick reply, today I try the BVT for a first test.
I don't find all vis in the BVT for LV 8.6.1 and I attach a pdf file to explain this in details.
I was looking at implementing some cRIO code using the BVT.
I started to grind my teeth on the CVT first, and understanding how it is being meshed with the CIE. Notably the "CIE get CVT Indexes.vi" and "CIE Scan.vi" are doing the job of respectively correlating the tags between CIE and CVT, and updating the CVT with the latest tag update in the cRIO scan (when synchronized with the scan engine).
Now I just realized that there is no VI meshing the CIE and BVT. Are there a library I missed somewhere? Or do I have to build the BVT on top of CVT, which would not be too too handy. Furthermore, even though the BVT and CVT Cluster are made of the same type of elements, their name is not the same, and is not compatible with the Tag Configuration Editor.
anyone with some pointers on this? Thx.
I found out what happened. I had saved an 8.6 version a while back but I didn't notice that this version didn't have the new functions created in LV 2009.
The only difference with the version you have and the LV 2009 is that in the 8.6 version whenever you write to the BVT you are actually committing the value to the table (the VI name says write when in reality it does the write and commit). With the 2009 version you have two options when writing. The first option is the same write and commit as in 8.6 although this time the VI’s name actually is “write and commit”. The second option is when you only write to the BVT but it isn't committed until you call the “commit all” VI.
The reason why you might want to have the write and then commit is if you want all your variables time stamped at one same time.
I'll try to have by today or tomorrow the LV 2009 version saved for 8.6. Sorry about any confusion.
The components you mention (CIE, CVT, and even the tag configuration editor) are components meant to work with the CVT. There are some components equivalent for the BVT although not all of them were ported.
Go to the Reference Design for Real-Time Test and download the RTT ref design for the BVT to get these components. The name of that file is: rtt_lv2009_av1.zip
This ZIP file contains a word document explaining the RTT reference design based on BVT, and it also has components such as the BCC (BVT Client Communication), the Variable Configuration Editor for the BVT and an example of what would be the IO engine.
Unfortunatelly the BVT was built before the latest release of the CVT and the Machine Control Reference Design so some of the features and components are different.
The new version(bv1) of the RTT ref design is based on the latest version of the CVT.
Let me know if this helps you.