LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Not Understanding Data Value References

Solved!
Go to solution

@govindsankar wrote:

   KNIGHT OF NI wrote : Have you considered using an Action Engine?

 

Thank You for that info. DVR was a new concept to me. So I learnt DVR to do this. Then problem started and I started this thread and kept asking doubts. Now I will learn action engine and try to do this. But I will have to warn you, if i couldnt get it right again I will start asking more doubts like this. I will be learning from youtube and google. I will try to gather as much data to learn it. If you know any good material that will help me learn this, kindly do tell me. 


You don't "ask doubts".  You ask questions.

 

A question is what you have when you don't know how to do something and need to ask.

A doubt is what you have when you don't believe something can be done.

0 Kudos
Message 41 of 47
(885 Views)

@ Ben Knight NI wrote : The group here are volunteers

 

And I have only the atmost respect and appreciation for you guys. Its because of you guys I was able to reach this far. Once I am done with my masters, I will find a job and then I will pay for a proper NI LabVIEW course and try to get certification myself and once I get it I hope to answer questions rather than posting. But until then you guys and the online free courses are all I have and I am sorry I couldnt do any better. As far as the mistakes are concerned its because of DVR. I know how normal data flow works, but I thought with DVR something special can be obtained and that is how I created those errors. 

0 Kudos
Message 42 of 47
(880 Views)
Solution
Accepted by topic author govindsankar

If you understand dataflow for normal variables, then you understand dataflow for DVR's.

 

DVR stands for "Data Value Reference". It is a variable that is simply a reference to a piece of data.

 

When you give a VI this reference, it can look up and see what that reference is pointing to. You still have to pass around the reference, but the difference is that the reference can be supplied just one time, whereas normal variables it is the *value* that is supplied each time.

 

 

I'll use an internet example. Let's say you want to send a picture to some friends. You open an email, and attach the picture, and send it to them. Once the picture has been sent, you can never change it or modify it- it's gone. This is "by-value" data, like when you branch a wire.

 

Let's contrast that with sending them a link TO a picture. Instead of attaching the image to your email, you send them www.example.com/FunnyCatPicture.jpg. Now, when they click the link, they see the picture. You didn't send them the picture, you sent them a reference to a picture. What's the difference? Well, for one, you don't make copies of the picture when you send it this way- there's just the one copy. Two, whoever owns example.com can now change what that picture is, and the same link now points to a NEW picture- without having to send a new email!

 

With this use-case, let's say you want to host a new picture of your cat every day- the website owner can send out a link to www.example.com/CatPictureOfTheDay.jpg *one time*, and every day he can change what picture is hosted at that address. The reference never changes, but the data does. That's what a DVR does for you. It's an advanced topic, to be sure!

 

My point here is this. With your setup, you will need to first create the DVR somewhere, then share THAT SPECIFIC reference to all of your subVI's that need to access that data somewhere else. You cannot just open a brand new VI and say "Get my DVR and look up the data to which it points" any more than you can click on a link if no one sends you a link. You will need to share THAT link.

 

This is why a branching object will work if you assign the DVR *before* the branch but not *after* the branch.

 

Last, in your situation I don't think a DVR is the right way to go. An Action Engine is likely the better choice for you for now, as it's much simpler to get your head around, but I wanted to try to give you some more understanding about why some of your examples work, but some don't. Hope that helps, and good luck with your project.

 

(PS- your method of reducing the problem to simple test VI's is good. Keep doing that! Keep each test simple until you understand it, and build from small blocks. Trying to go for the whole program all at once is a bad way to do things.)

Message 43 of 47
(874 Views)

BertMcMahan.

 

Yes I know about by value and by reference. I have a whole course on that on my masters. But my mistake here was I thought I could just use the reference anywhere, but I found even with DVR I need wires. I cannot create a dvr at one point and it magically appears in another point. That was what I thought, like sending a queue. DVR also needs wires, but the difference is the wire transmits the reference to the data where as in normal dataflow you are passing the value itself. So when I branch a normal wire it makes a copy to the data, but when I branch a dvr it will branching the same ref to the same data. So I found out DVRs are useful only while branching and we dont need to make a copy. We need parallel function on the same data then we can use DVR. And the In Place Element structure makes sure no race conditions will occur. So that is what I have learnt about DVRs. Now I start with action engine. Hoping I will able to learn action engine in one go and not the same way like DVR.

0 Kudos
Message 44 of 47
(864 Views)

Action engine worked. Thank you so much. I initialised can in the can class and read it in board 1. I only have one board 1. So I will run the main program, then initialised the can bus. Then since I have only 1 board. I would run and stop it again and again, but I dont have to initialise can bus again and again. I just initialise the can bus, then run the board, stop the board, run again, stop again and so on. Finally when I stop the main program, the Can bus is un-initialised, so that when I start the main program again next I can initialise again and do this. Now I can program the other boards, with this. Thank You very very much. 

Message 45 of 47
(846 Views)

Skip the class for now, just make an Action Engine with Init, Write, Read and Close.
Init creates the DVR and stores it in a shift register.

Write uses the internal DVR to write.

Read uses the internal DVR to read.

Close Closes the DVR.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 46 of 47
(810 Views)

Can you be more specific.. If you specify just DVR , i think for Reading and Writing i will  be using  in place element structure - right? i think using that only i can modify the data that is reference to !

0 Kudos
Message 47 of 47
(644 Views)