Event Programming - Really Basic question

[Thomas L.]

Hi

I am currently trying to get some really small program, which uses events working. I have prepared a small example:
http://666kb.com/i/afwqjnq2g2u6ntfum.jpg (I didn't include the image directly, I hope that is ok with you)
This program is supposed to write the value from string into string2 when the button is pressed - fairly simple 🙂

Until now, I've always used Property Nodes to reflect changes in the UI.
http://666kb.com/i/afwql50oo2a2r8sce.jpg

I was told, this is not really a good style, since it breaks the dataflow LabVIEW was designed for.

Now what I was trying to do was, to get the same functionality but while maintaining good coding style. How would I do that in LV?

I was trying:
http://666kb.com/i/afwqmfdp32tjljlha.jpg
As expected, it doesn't update properly. I guess the value is read during the start of the program and then left alone.

I was also trying:
http://666kb.com/i/afwqn3zntaa97d4se.jpg
Doesn't work, too.

So I am asking you, how do I do that correctly and how do I do that, if I have a load of elements on one single front panel (say, 20 oder 30 controls).

Thanks for your advice

Thomas

[becktho]

Hi Thomas

Yes, you've been told right. Try to stick to the dataflow.

Now to your last two pictures. In both of them, you have the string control placed outside the loop. As you mentioned correctly, the value is read at the start of the vi. It doesn't matter if you wire it to a shift register or not. It is just read once when the program is started. To read it when the button is pressed, place it in the corresponding eventcase and wire it directly to the indicator.

Thomas

[Thomas L.]

Hi Thomas

Ok, I see. If I place it into the event, it will be read when the event executes.

But now another problem arises: What if I have to events which require data from the same control? As I think, it's not possible. How would I solve that?

[becktho]

You do not have to place it in the event, but in the loop that executes. In your example, you don't have specified timeout which is why I said to place the control in the event case. If the event occurs, it is read.

If you have several events that read the control, there are several solutions. Which range from multiple controls handled in the same event case to state machines using queues to exchange data.

Basically it really depends on what you want to do. There is no general answer. Additionally, every member of the forum would give you another answer ;).

[Thomas L.]

Hmm .. Now I am confused. What does timeout have to do with this?

I am used to programming languages such as Java / C++ / C#. Using events is quite simple there (especially Java & C#). The whole GUI programming is nothing more than subscribing to an event. When I want to read something, I access that field/object. This is why I was using Property Nodes, since it gives me the same, quite simple functionality.
Back to the timeout: In C# and Java, the whole application simply waits for an event. During that time, it is in some sort of sleep state, where it doesn't consume CPU time - very nice.

Since LV offers events, I thought I could use them just as easily. But now, you're telling me timeout is an important factor in this case? To me, that doesn't make sense. Why would I place something except the event structure inside a loop if I want to use events. That would mean, it is read all the time if I don't specify some sort of delay (which would bring me back to using State Machines for a GUI, which is a No-Go (as I heard in some LabView Meeting, and which makes sense to me)).

And to be honest: If it is really that complicated to access a single control from multiple event cases, I'll stick with my property nodes. I cannot believe nobody has ever created a simple way to do this?

[becktho]

I did not say the timeout is important. What I meant is this: if you placed the string control inside the loop, but outside the eventstructure and wire it into the eventcase, it would have been read and afterwards the eventstructure would have waited. If you then clicked the button, it would not have read the correct value.

I know Java as well and I just use the timeout to control a clock on the LV gui (I don't have to creat a timer task ;)).

If you access a field or object in Java, you have different scopes but you don't have this in LV (ok you could recreate it on your own, but basically a variable is just visible in the vi). In addition to that, LV works with an other paradigm - dataflow. Basically one should stick to it (as I mentioned) but you definitely do not have to. The easy way you're looking for are local variables. Using them you can read the value several times, but you somehow loose the readability of a vi which uses the dataflow. The control itself can just be read at one place using the terminal of the control.

[Thomas L.]

Ok, I just tried that. I placed both string controls into the while loop but outside the event structure. The value in string2 is updated on the second click (as I expected it). Of course, not a wanted behaviour. Could you please post an example, how you would do it. Say - a simple application. You can enter values for a DAQ such as time and frequency. If the DAQ acquisition is started (it's only run a single time), those values are required. Furthermore, there should be an option to save those values to a file.
In this example I have two completely different tasks. I'd use 2 event cases - one for acquiring the data and another one for saving the settings. I'd need the values in both cases.

Controlling some sort of clock sounds reasonable - to me - that makes really sense. I'd use it to update values which are constantly read or something from e.g. a DAQ Device. That sounds like a useful approach to me.

I am quite familiar with the dataflow paradigm and I really like it, as long as I don't have to use it for typical GUI tasks. Events are my favorite choice here. Of course, I could use state machines, but I do not see why I need polling if my OS offers all this functionality I'd have to implement by itself. I am glad, that there are event structures for these cases.

I have used Local Variables as well, but have some issues with those. Maybe you can answer that question in a short way: When I read from a variable, which value do I really read? The one from the control or some temporary value? When I write to a local variable, where do I write to. The control, or some internal values. I know, that the values of local variables are not reflected in the control itself. This is why I was using Property Nodes.

Concerning readability: Currently, I'm not sure which solution has the better/worse readibility. Using a property node, where I can always see the name and the property or using some kind of complicated structure (be this one event case for multiple controls or exchange queues) just to maintain the paradigm "dataflow".

And finally: What is the difference between a value property node and the terminal output? I couldn't find any.


Hmm .. sorry, this thread is getting quite long, I thought this was a much easier question.

[becktho]

Yes it's getting long - but there's nothing against good discussions.. 😉

1. I can't give you a simple example. Basically, if I have settings as you mention it, I make a separate gui to edit them. This results in a library to load and save the values, this makes it kind of flexible and I can access them whenever I want. It really depends and this is also where the "handwriting" of the developer plays a role.

2. Obviously, you misunderstood what I wanted to say with the state machines. I also use the event structure for guis, but instead of placing the program logic into the event cases, I just enqueue a state which is dequeued in a second loop and fed into a case structure. Of course I also don't pool for the gui elements any more (wow those times before LV7.X were quite hard.. ).

3. I can't tell you exactly where a value is written to or read from. I assume there is a place in the memory, where the data is placed. The value displayed in the control may be read from there. (Some kind of view and the model is in the memory). But as I said, I'm not sure. What kind of issues did you encounter? Additionally there are some threads on that topic for sure - just search the forums.

4. Basically, there is no difference between the terminal output and a property node. I remember to have read that the property node uses more memory. I always use the terminal - imagine a vi where all terminals are just place in the bottom area of the block diagram. This gets quite hard to read.

Thomas

[Thomas L.]

ad 1) Basically I use this approach, too. I just couldn't think of a better example

ad 2) Now this is ... ahem .. too difficult for me. I think I'll have to sleep over that 😉

ad 3) Jup, I've already read a lot about local variables during the last few days. Basically my problem always was, that if I changed the value of a local variable, it was not reflected in the GUI. I'm sure I will learn more about that the next few days.

ad 4) I once visited some sort of "Users meeting" (don't know the correct translation). Some guy from NI pointed out, that Property Nodes cause a slowdown, since there is a thread swap to the UI thread, which causes some overhead.

Converning that VI you mention .. with all the controls at the bottom: They were to the left - this is why I asked this question 🙂

Thank you for our answers till now. I think I'll further investigate part 2 and 3.

[becktho]

If you use LV8.0 (I think it should also work with LV7.X), select File > New from the menu, so that the dialog comes up. Now you should be able to select design patterns. Search for "Producer/Consumer Design Pattern (Events)" and have a look at it. This shows you what I meant under point 2.