Need your help - what is the best concept for my project?

[johanneshoer]

Matt and Ray,

thank you for your help!

• The inicator dummy & the initialisation of booleans on the left:

In my opinion, the booleans should be initialised. It could happen that you accidentally klick on

"make current values default" and the default values are changed. You don't want that, so if you

initialise all values at start, then you don't need to worry about default values. It's just a

precaution.
And the wire to the dummy indicator takes care, that the initalisation happens in the begining.
How do you know, that the initialisation happens in the beginning in the matt's picture?

• End button:

You are right, but I want to keep that button. The program is meant for unexperienced users and

for them it is better to have something evident to klick on 🙂

• Producer as listening loop:

Sorry, I didn't get it. Do you mean the producer loop should be something like a "data available" event?
(analgue In = DAQmx, digital In is not DAQmx but much faster)

• Waiting for period time

I put my attention on the period time, and I realized that my way of waiting for the next period

was really bad: Waiting was a state, which was active until period time. CPU load became 100% 

Now I put "Wait until multiple ms" in the waiting state and now it works good.  

• Queue problem

In this version you'll see that the program is stil far from perfect. I have a queue problem now. Input data comes after 35ms, but data is processed and put out with 50ms. So the queue gets flooded and the input data is delayed more and more.

I should either process the data in the same frequency as input data is coming or execute the producer loop in period time intervals. Will try it right now.

Latest modifications of the VI: better block diagram arrangement, more events for some buttons and better timing.

Message Edited by johanneshoer on 10-05-2009 04:34 AM

[johanneshoer]

I think I am on the wrong track.

Before I attended the LabVIEW Basics II course, I had my test bench control program sequencial. Data Input - Process data - data output and lots of other stuff like displaying and saving data etc. in a sequence with 40 (!) stacked frames, very simple.

Then I thought I should make use of LabVIEWs parallel data processing, to make my program better performing.

Queues don't loose data, that's good, but not in my case. I need the data to be up to date and the input data rate should be the same or higher than the processing of the data. I don't mind if input data gets lost. So if I slow down the producer loop and use queues to just overgive the data to the other loop, I could have simply used one loop and a wire instead.
Right?

I don't see the advantage of the producer consumer architecture. Maybe I am just blind.
You guys know my problem quite good now. Would you have implemented the test bench control like I did above or would you have chosen a completely different way?

Message Edited by johanneshoer on 10-05-2009 04:54 AM

[Ray.R]

---

johanneshoer wrote:

Would you have implemented the test bench control like I did above or would you have chosen a completely different way?

---

Well, since you asked..  Yes.  I would start from scratch.  There are many things not needed, such as the initialization, dummy indicator, Local Variables, structures (way producer/consumer is implemented).  It is beneficial to implement a producer/ consumer loops with a queue.  You may not care about some data loss, but why would you want or accept that if you can implement a solution that does not loose any data?

[johanneshoer]

Ray,

ok, so you would stil use the producer/consumer architecture with queues, which means I am not really on a wrong track?

I wonder why I don't need the initialisation?
I use a lot of controls and indicators, some of them function as flags or temporary storage. If I run and then stop the program, some controls might not have their default value if I run the program again.
Default values could also be accidentaly changed if someone klicks on "Make current values default" instead of "Reinitialize all to default". That happened to me more than once.
Using initialisation, I don't have to take care about default values and when I learned the programming language "C", I was tought to initialize all values at the beginning, which is good programming. Is that no longer valid in LabVIEW?

[Ray.R]

---

johanneshoer wrote:

ok, so you would stil use the producer/consumer architecture with queues, which means I am not really on a wrong track?

---

You're correct.  You're not really on the wrong track, you simply have to clean up a few things and simplify the solution.  This is an excellent way to learn LabVIEW.  It's a good exercise.  Now, don't be too hard on yourself, you're probably closer to the solution than you think.

---

johanneshoer wrote:

Using initialisation, I don't have to take care about default values and when I learned the programming language "C", I was tought to initialize all values at the beginning, which is good programming. Is that no longer valid in LabVIEW?

---

Your statement is correct.  In text-based languages, it is a good practice to initialize values at the beginning.  This is not the case with LabVIEW.  Especially with Booleans.  For other value types, you can either use constants or controls.  With constants, you would not have the issue of re-initializing default values; however, the operator would not be able to change the values.  The variables in LabVIEW are the wires.  So values are retained in the actual wires themselves.

---

johanneshoer wrote:

I wonder why I don't need the initialisation?
I use a lot of controls and indicators, some of them function as flags or temporary storage. If I run and then stop the program, some controls might not have their default value if I run the program again.
Default values could also be accidentaly changed if someone klicks on "Make current values default" instead of "Reinitialize all to default". That happened to me more than once.

---

Well.... you do.  Butit is not the same way as you are used to in text-based languages.  For temporary storage, you can use a shift register within loops.  Or you could even use a Functional Global Variable.  If you do use controls, yes, you have to be careful about the "reinitialize all to defauls" selection.  Once you deploy your application, then it should not be a concern.

R

[johanneshoer]

Ray, thank you again for your big help!

Now I removed the initialisation, removed the local variables and I have inserted shift registers. For less wiring I even placed a cluster. 

So by using shift registers I could remove the events for the start and pause button and moved the terminals into the states. Is that correct?

Period timing is now controlled in the producer loop, to avoid data overflow. If there should stil be old elements in the queue, it gets flushed, so that the data is allways up to date.

As you can see,"Wait for next multiple ms" waits for the period time. Is there a better way?

[johanneshoer]

---

 

"Wait for next multiple ms" waits for the period time. Is there a better way?

---

 The answer is: Timed loop

[Ray.R]

It's starting to look better 🙂

You can get rid of the Event Structure and wire the End directly to the stop of the producer loop.  You can then close the queue reference at the exit of the producer loop, which will kill the consumer loop.

Why do you flush the queue when there is residual data?  

You can also use the cluster "unbundle by name" and select "Status" to get the error status in your consumer loop.

I have not looked at the logic of your code yet (I sneak into the forum, answer quickly and rush out between builds).  😉

R

[Ray.R]

Here's an image of what I mentioned above.  << untested >>

 

As a matter of fact, you could simply wire the "stop if true" directly to the error cluster (in the consumer loop). 

Message Edited by Ray.R on 10-05-2009 01:23 PM

[cirrusio]

Nice job!  Ray's right on the mark (although, going back a lot of messages, if necessary you can have a state machine in an event structure - just have the state machine run in the timeout).  You can also have an init feature in your state machine if you do need to initialize controls (I often do include this feature as I want to make sure that the controls are explicitly initialized and a previous user did not muck up the initial state somehow on the FP.

Hey Ray - do we need to get you a new license for LV?  I noticed that you are running an eval version; maybe we should pass around the hat in one of the forums?