LabVIEW
Using change properties of a control dial, why can I not feed the output into the Sial input (via a loop ) and the dial continually updates?
Interesting situation you have here.
The problem is that you are writing to the control via the property node before it is being read, and the shift register that is connected to the property node is writing a zero on the first run, and that is where it gets stuck. Try running it with execution highlighting on (the little lightbulb on teh blick diagram toolbar) and you'll see what is happening.
On the first run, the uninitialized shift register contains a zero (default value for the data type). Since you have the property node and control in a sequence structure, the control cannot be read until the property node runs. So this zero gets written to the node, which in turn updates the value of the control to zero. The control is then read as zero and this value is then written to the shift register and the whole thing start over.
It would actually be possible to get the value to change, if you would happen to be able to change the value of the dial in the microsecond between the time is is updated from the property node to the time it is read, but this isn't likely.
What exactly are you trying to do? This little application makes no sense. You're writting the value from the control to the control. If you explain what your end goal is, we can probably help.
Ed
The problem is that you are writing to the control via the property node before it is being read, and the shift register that is connected to the property node is writing a zero on the first run, and that is where it gets stuck. Try running it with execution highlighting on (the little lightbulb on teh blick diagram toolbar) and you'll see what is happening.
On the first run, the uninitialized shift register contains a zero (default value for the data type). Since you have the property node and control in a sequence structure, the control cannot be read until the property node runs. So this zero gets written to the node, which in turn updates the value of the control to zero. The control is then read as zero and this value is then written to the shift register and the whole thing start over.
It would actually be possible to get the value to change, if you would happen to be able to change the value of the dial in the microsecond between the time is is updated from the property node to the time it is read, but this isn't likely.
What exactly are you trying to do? This little application makes no sense. You're writting the value from the control to the control. If you explain what your end goal is, we can probably help.
Ed
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
Forgot to include this.
To make your current VI work close to the way I think you want it to, add a frame to the sequence between the node and the control and put the Wait function in this middle frame. This gives you one second from the time it is updated to the time it is read. Although this still won't be perfect, there's till the possibility of a race condition if you change the dial after it is read, but this would be as likely as getting it changed at the correct time with your first version.
Ed
To make your current VI work close to the way I think you want it to, add a frame to the sequence between the node and the control and put the Wait function in this middle frame. This gives you one second from the time it is updated to the time it is read. Although this still won't be perfect, there's till the possibility of a race condition if you change the dial after it is read, but this would be as likely as getting it changed at the correct time with your first version.
Ed
Here's a much better sollution to your problem. It introduces the Event
Structure which works great for working with user interfaces. It
watches for the user to "unclick" the mouse button so the final value
will be written to the array in the correct location. Have a look at
this and see if you understand what's going on.
Not sure if I understand what you mean by, "I did not realise that by putting a timer within the loop then the program exited, loaded default values again before enterring the loop again!", but I'll try and explain.
The timer does not have anything to do with the default values being loaded. Default values are loaded into shift registers, controls, indicator, ect.. when you first open the application. The values are then updated by what is happening in the application. In your case, the shift register always has a zero being written to it on the right register. That's whay it never updates.
It sounds like you really should at least read through the LabVIEW tutorials that ship with LabVIEW. Look in the Help menu and select "Search the LabVIEW Bookshelf".This will opena PDF file and you should see some bule links. One of them will be "Getting started with LabVIEW". You should work through this to learn the LabVIEW basics. One important concept is Dataflow. This is what determines how and in in what order your application executes. You really need to understand this concept to effectivly program with LabVIEW.
Another excellent place to learn is a website from Rice University. They have an Introduction to LabVIEW that is basically the same as going to NIs LabVIEW Basics course.
Let us know if you need any more help.
Ed
Not sure if I understand what you mean by, "I did not realise that by putting a timer within the loop then the program exited, loaded default values again before enterring the loop again!", but I'll try and explain.
The timer does not have anything to do with the default values being loaded. Default values are loaded into shift registers, controls, indicator, ect.. when you first open the application. The values are then updated by what is happening in the application. In your case, the shift register always has a zero being written to it on the right register. That's whay it never updates.
It sounds like you really should at least read through the LabVIEW tutorials that ship with LabVIEW. Look in the Help menu and select "Search the LabVIEW Bookshelf".This will opena PDF file and you should see some bule links. One of them will be "Getting started with LabVIEW". You should work through this to learn the LabVIEW basics. One important concept is Dataflow. This is what determines how and in in what order your application executes. You really need to understand this concept to effectivly program with LabVIEW.
Another excellent place to learn is a website from Rice University. They have an Introduction to LabVIEW that is basically the same as going to NIs LabVIEW Basics course.
Let us know if you need any more help.
Ed
@Fossetics wrote:
My simple mind says that if I write to the dial (0 or what ever) and then I twidle the control this would change the output and be written back into the 'load' of the dial. This is clearly not what happens.
...
Any clarification would be very welcome.
I think Ed already explained it accurately, let me just repeat it in slightly different words.
LabVIEW is a dataflow language. Nodes execute once all inputs contain data. Outputs only contain data once the node finishes. Let' s see what happens in your program:
- At the first execution, the shift register contains either zero (first run) or whatever the value was in the previous run.
- The value from the shift register gets written to the property node.
- The terminal of the control is read and it's current value placed in the shift register on the right.
- Now the loop must wait, because the wait statement is not finished yet (everything else is done!).
- Since all other nodes in the loop are nearly infinitely fast, the VI spends most of the time in this state. Notice that the control terminal has already been read and it's value placed in the shift register. Any changes to the control would be read the next time step (3) is encountered in the next iteration of the loop.
- Finally the wait finishes and the loop is allowed to go to the next iteration.
- Now the value from the shift register (written in step 3) is dumped into the control via a property node, overwriting all changes you did to it in step (5).
- In a blink later, that same value is again read from the control and we continue again with step 5.
- ad infinitum...
First of all, circular code is bad. You seem to have the (wrong) impression that there is some need to write to a property node. This is incorrect. Front panel objects have their own copy of the data and retain it until you change it. It's value can be read at any later time. In this particular case you can delete the shift register and property node and everything will work just fine.
@Fossetics wrote:
In my application I have set ups for 24 channels that I keep in an array. I then select a channel, load the value into a dial control, there by allowing the control to be changed and written back into the array.I obviously am not understanding the fundamentals of labview. I do not understand why I cannot load, adjust and write back. using a Dial control.
Of course you can. 😄 Maybe I have time to make a quick example over breakfast....
EDIT: Ahh, busy thread! I see that in the meantime, Ed already made a nice example. I think you're all set! 😄
Message Edited by altenbach on 11-20-2005 08:43 AM
Made one slight change to my example.
I realized that if the user changed the value from the digital control of the dial, it would get updated to the array after the value was changed.
So I simply added an Update Value button the user can click after he gets the value set. This will work with changes to either the dial or digital display.
And thanks to Altenbach for the more detailed explaination. I kept forgetting to say there's no reason to write to the control you're reading from. It just doesn't make sense and causes problems.
One thing you need to keep in mind is that everything in the loop will execute once, and only once per loop iteration. So the dial will be read within microseconds after you hit the run button, but after it has been updated from the node. Then it will not be read again until the next loop iteration, and as Altenbach explained, the value is always going to be zero due to way you have it setup.
Ed
I realized that if the user changed the value from the digital control of the dial, it would get updated to the array after the value was changed.
So I simply added an Update Value button the user can click after he gets the value set. This will work with changes to either the dial or digital display.
And thanks to Altenbach for the more detailed explaination. I kept forgetting to say there's no reason to write to the control you're reading from. It just doesn't make sense and causes problems.
One thing you need to keep in mind is that everything in the loop will execute once, and only once per loop iteration. So the dial will be read within microseconds after you hit the run button, but after it has been updated from the node. Then it will not be read again until the next loop iteration, and as Altenbach explained, the value is always going to be zero due to way you have it setup.
Ed
Message Edited by Ed Dickens on 11-20-2005 11:02 AM
@Fossetics wrote:
Is this normally done by polling (circular code?) or by events, or is it normal to have separate controls for each channel?
Just create an event for the selector change where you read the desired element and write it to a local variabel of the control.
See attached modification.
