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

[Ray.R]

---

mtat76 wrote:

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?  

---

That would be nice 😉

LOL!!

Working on the dark side with CVI these days, so the eval version is the only way I can post example code.  Nothing stops me from trying to help.  LOL! 😄

[johanneshoer]

@Ray:

Now I understand why you have either an event or an Producer/Consumer loop! 🙂
I have implemented it like that now.

Am I right that in some cases it makes sense to keep the event structure, like for user actions that have to apply instantly?

The reason for flushing is the following:
Without the flushing it could happen, that old data is in the queue. If you deactivate the flush-queue and set the period time to the limit (the limit is 35ms, which is the period time of input data) and run the VI and move the window around on your desktop wildly to stress windows, then you'll see how the numbers of queue elements rises. As soon as you stop moving, the consumer loop processes the old data. I don't want that.

Normaly you do not move around windows like that, but there could be some other programs or tasks or virus scanners that occasionaly slow down the execution of VIs.

@mtat76:
If I have a state machine in an event structure, do I still have the producer and consumer loop? Does the event become the consumer? How many loops do I have then?
Concerning the initialisation, you are right. That is why I like initialisation 🙂

What is the best way to post VIs (more than one)? Put them in a zip folder?  

Message Edited by johanneshoer on 10-06-2009 03:14 AM

[johanneshoer]

I have just realized, that I could have done it much easier with a notifier

Attached you find the version with the notifier.

[Ray.R]

Hi Johannes,

The VI is starting to look better.  You're getting closer.

Here are some comments:

1.  You can make your typeDef Enum a constant instead of a control.  It is hidden anyway.  Plus, having it as a constant makes the code easier to read byseeing which state it goes in at the beginning.  You could even have a state to reset everything to your default values and that would be the initial state.

2.  Try to avoid cohersion.  Use proper types for "set period time".  Notice the small red dots.  If you need a double in your consumer loop, then cast to double.  Otherwise, try us use proper type throughout.

3.  Have a look at the image for esthetics.  Noticed that I simplified the code by stopping the consumer loop with the error.  Note that it is not ideal, however, the only boolean you were using was the error status, so this way, it eliminates a few "False" in the other states.  😉

4.  You can also merge errors and use the simple error handler.  Better yet would be to have error in & out (control & indicator ).

Is your program running?

Message Edited by Ray.R on 10-06-2009 08:32 AM

[cirrusio]

---

johanneshoer wrote:

I have just realized, that I could have done it much easier with a notifier.

---

Sounds like you just discovered that a notifier is essentially a queue with a depth of 1.

Regarding the question concerning events and state machines - the structure of your program would remain essentially the same, with the state machine nested in the timeout portion of the event structure (an important note is that the event structure must be allowed to time out otherwise no state will be executed).  One problem is that if you are operating on super tight loops (i.e. the system is expected to respond at greater than 500 Hz), event handling in a producer loop may result in missed acquisition periods (bad).  However, if you are looking for a full determinant system on Windows or Mac, I would suggest that you need to consider other options (such as processing on h/w - FPGA - or moving to real time). 

Ray's on the mark, obviously (although I am not sure what cohersion is - a more insidious form of coercion perhaps? ).

Looking ahead, you may want to consider a basic state machine in the producer loop.  State's might include Config (to put all controls and indicators in the right state and make one time calculations), Acquire (where your actual acquisition, rudimentary processing that will make the data more compact for shipping and enqueueing will be done) and Quit (where everything will be shutdown cleanly - any DAQmx connections, file references, queue references etc - and controls will be returned to their initial state).

As far as packaging VIs - my suggestion would be to make sure that you are working within a project.  From there, you can build zips or llbs that contain all of your VIs pertinent to what you are interested in distributing as well as build exe's and dll's.  zips and llbs will be best for anyone who wants to view the VIs in a forum setting.

Cheers, Matt 

Message Edited by mtat76 on 10-06-2009 11:02 AM

[Ray.R]

Well described mtat76.

---

mtat76 wrote:

although I am not sure what cohersion is - a more insidious form of coercion perhaps?

---

It's a francophone version of a coercion LOL!!  😄  We always pronounce the "h" sound at the wrong place..  😉 

---

mtat76 wrote:

---

the state machine nested in the timeout portion of the event structure (an important note is that the event structure must be allowed to time out otherwise no state will be executed). 

---

I'm not a fan of using the timeout function of an Event Structure to trigger events processing.  I use the Event Structure for actual events not as a timed loop.  In this case, since there is little or no operator interaction other than saving a file and ending the program, a State Machine in a Producer/Consumer configuration does the trick.

🙂

[johanneshoer]

Hi,

thanks again for your improvements. I will take care of it tomorrow - today I was busy fixing my real test bench program. I've implemented lots of your recommendations and it runs much better & faster now. I have still a lot to do, like getting rid of several hundred local variables 

---

Ray.R wrote:

Is your program running?

---

Yes it is. I'll upload the next version as a project as mtat76 suggested.

[Ray.R]

---

johanneshoer wrote:

I have still a lot to do, like getting rid of several hundred local variables

---

Yes.. yes..  That'll make me happy;)

LOL!  😄

[johanneshoer]

Hello,

attached you find the latest version.
 

Enum:
I created the enum as a typedef for a reason: If you add a new element, all depending structures in the vi will notice it.

Is that also the case if it is a constant?

Avoiding coersion:
I don't see these red dots in my VI. I created the set period time control by right mouse click on the connector and then "create control", so it must be correct. The red dot is probably because of our different LabVIEW Versions.

Creating a project:
In LV 7.1 I can not find something like "File > New > Project" at least not in my version.
I tried using the Application Builder, but I can not create pure libs, only dlls + libs. 
To be safe I attached it again as a zip file.

The program runs, but now due to the error handler I get an error if I end it:

Error 1 occurred at Wait on Notification in Testbench_Control_14.vi
Possible reason(s):
LabVIEW:  An input parameter is invalid.
---
NI-488:  Command requires GPIB Controller to be Controller in Charge.

What could be the reason for this error?  
 

Message Edited by johanneshoer on 10-07-2009 04:03 AM

[cirrusio]

Hey Johanne,

Nice job.  If we are looking at **_14 (rather than 13), I see coercion dots:

1. on the timed loop inputs
2. on the state machine selector in "Process Data" in the consumer loop
3. in "Output Data" where you are calculating the average time
4. on the input to DO VI in "Output Data"

Regarding the typedef enum as a constant, the answer is yes, changing the typedef will change the values available in the constant. 

The error that you are getting is being thrown because you are tying the error out in the consumer loop to the  Merge Errors.vi..  The Consumer loop throws an error of course because the queue ref is invalid (it's how you stop that loop.  You need to find a way to ignore this error; don't bundle would be my immediate answer and find a way to handle real errors that occur gracefully - this is dependent on the requirements of the program you are designing for and is often one of the more difficult tasks.

Good luck, Matt