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

[johanneshoer]

Now I modified the VI again a little. Now I have a state machine and only two loops (one consumer and one producer).

 I moved the wait function into the consumer loop, because the output of data in the consumer loop needs to be in 50ms intervals.

On the top there is an simple event case. Is is correct at that place? should I put it in a loop or not? 

I have commented the event case out, because there is stil a problem. if I press stop, the VI hangs up. I wonder why.

Johannes

[Ray.R]

---

johanneshoer wrote:

If you say "Typically, you have an Event Structure with Data  or a Producer/Consumer Loop", dou you mean you have EITHER an Event OR an Producer/Consumer Loop or could you have both?

---

Hi Johannes,

I read your other posts.  It appears that you figured it out.  🙂  Yes, I meant having two loops, either an Event Structure with a State Machine or a Producer/Consumer loops, where the consumer loop can be a State Machine.

---

johanneshoer wrote:

Sorry Ray, I cannot open your VI. It is made with Version 9.0. I am using 7.1.

---

Oops..  I did not realize that.  I can try to do a screen capture (or a couple of them) to show you  the changes.  I do have access to LV7.1 and will use it.  Sorry.

---

johanneshoer wrote:

"You still need to get rid of the sequence structure."
No problem, I could place all the INIT oin the left sinde, but then the block diagram becomes large.
If I place the INIT in a sub vI,then I need lots of global variables, right? In the INIT I reset all values of buttons and LEDs etc.

---

I had already done that and it did not increase the size on the screen.  Let's see what the captures will do..  😉

[Ray.R]

Message Edited by Ray.R on 10-02-2009 08:35 AM

[Ray.R]

I will look at your latest code later (probably tomorrow with LV7.1)

[johanneshoer]

hey,

now I have a nicely working program.

Stop and End Buttons are functioning. See the attached vi.

Now another problem occurs: Timing problem! As I have mentioned, the output interval has to be 50ms. +/- 5 ms is OK. Please try my VI and play a little with the period time control and see what happens. The output time varies between 50 and 100ms wildly.

Input data comes after 35 ms, so there should be no problem.

Johannes

LabVIEW 7.1

[johanneshoer]

I fixed the timing:

I do not longer wait for next ms multiple. Instead I created a new state, which waits until the period time is elapsed, then the output is applied.

Next Problem: Now the program does not run faster than 70ms/period! I guess it is because the data input VIs (AI and DI) need 35ms each to provide data.

35 ms + 35 ms = 70 ms. Huh? I thought LabVIEW would run subVIs in parallel??

[johanneshoer]

SOOORYY.

My mistake. I have placed twice the same subVI.

Now it is allcorrect and it does what I want! 🙂

[F._Schubert]

I see one problem with the code in Ray's picture. If the user enters a very large number in the Period time, the app will become unresponsive for that time.

Felix

[cirrusio]

Sorry that I am now jumping in, but I thought that I would add a couple of comments.  First off, nice job!  Now for a couple of comments:

• Just an aesthetic thing - you have a sequence in "Output Data that appears to do nothing except take up space.
• Is there any purpose to the indicator "Dummy"
•  You can get rid of your "End" button as well as your "End All" indicator (and the corresponding local variables) by shutting down the listening loop (topmost) with the VI filter event "Close Panel" and setting Discard? to True (this will force the event to be thrown out and you can shut your program down gracefully).  To close the other loops, have them stop when the queue throws an error.  This will occur when the reference is destroyed in the topmost loop.  You will have to add a "Get Queue Status" in the False case in the bottom-most loop.  I have attached a snapshot so you see what I mean.  We all tend to get stuck in the mindset that we need a button to explicitly stop our programs - and we do!  But, this is provided on the panel and we simply have to utilize this functionality.
• I think that you can consolidate your loops (maybe you did this before, but I haven't looked at your previous diagrams) such that either the producer is also the listening loop.  When acquiring with DAQmx, you will generally have to wait the period required to acquire all samples requested in the buffer anyway, so the minimal amount of time it takes to respond to events should be no big deal (a wait till next multiple might be more appropriate to simulate this).

Cheers, Matt 

[Ray.R]

---

F. Schubert wrote:

I see one problem with the code in Ray's picture. If the user enters a very large number in the Period time, the app will become unresponsive for that time.

Felix

---

Agreed.

I hadn't look at the logic too much.  I cleaned it up so that the code could be seen in one screen.  😄

Looking at the more recent screen captures, the code has already gone through some evolution, thus making the image I posted rather invalid.  😉

The newer code still needs to get rid of the Local Variables and there is NO need to initialize the booleans on the left.  Have a look at the picture I posted from the original code.   It does not contain locals.

Message Edited by Ray.R on 10-02-2009 12:48 PM