LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Continuous Measurement and Logging LV2014

Solved!
Go to solution

Hello,

 

I am examining the CML template which can be found in LabView 2014. It is very nice, I learn a lot just by playing with this template. However, due to the very minimal documentation (practically zero), some things are not clear why are there implemented?

 

1., In the UI Message Loop, the Case structure has a "Confirm Quit" case. As I see, this case never can get triggered, since the stop button is disabled during DAQ, why is it there? I guess for to give an example, if someone wants to enable the option shutting down the app during DAQ, without stopping the DAQ?

 

2., Since it is not explained in the documentation, could someone explain the behaviour of the enum type def in the UI Message Loop? I think I understand that, before stopping the DAQ, we have to be sure about first the DAQ is stopped. Second, all the data is logged, so the logging loop can be also stopped, and finally we can go to Idle state and "update status" message can be broadcasted. Am I right? Somehow it is still a bit "fuzzy" for me... 🙂

 

thanks for help!

Regards,

 

Maind.png

0 Kudos
Message 1 of 11
(4,688 Views)
Solution
Accepted by Blokk

1. Confirm Quit is activated if you click on the red 'X' to try to close the Main VI window during an acquisition.

 

2. Yes, we must make sure that the logging and acquisition loops are in an idle state before we can close down the app. That's the purpose of the UI State enum.

 

Our documentation team already has a task to update the documentation to discuss these issues (it's tracked as CAR 397078).

Message 2 of 11
(4,675 Views)

thanks! It is more clear now 🙂

(i overlooked that there is a close panel? event, I think the best just to disable the X on the window, so the user does not feel the "urge" to close it that way 😄 )

0 Kudos
Message 3 of 11
(4,658 Views)

@Blokk wrote:

 

I think the best just to disable the X on the window, so the user does not feel the "urge" to close it that way


That's how the sample project was implemented in LabVIEW 2012. We got some complaints that users expected to be able to close the window with the red 'X', so we enabled it in LabVIEW 2013. But in order to facilitate that, we figured it was a good practice to add the Confirm Quit message as well.

0 Kudos
Message 4 of 11
(4,648 Views)

It is quite funny that how user habits (I guess people start to feel "uncomfortable" if the looking of the window is not the usual one...) create unnecessery additions to the code 🙂

0 Kudos
Message 5 of 11
(4,645 Views)

I don't even put Stop buttons on my programs.  Almost always, somebody who was not familiar with programming LabVIEW would use the 'X' to close the window.  So when I discovered the Panel Close? event, I was overjoyed.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 6 of 11
(4,639 Views)

@crossrulz wrote:

I don't even put Stop buttons on my programs.  Almost always, somebody who was not familiar with programming LabVIEW would use the 'X' to close the window.  So when I discovered the Panel Close? event, I was overjoyed.


yep, actually the problem is not that the user uses the X or a "stop" button, but that, we let the user to be able to quit the application without first stopping the DAQ. Would not be just easier to fire a pop-up dialog, telling the user, "hey, first stop the DAQ before you quit!" ? 🙂 So some state-check could be avoided in the UI Msg loop`s case structure...

 

2.: May I ask a CML related additional question? If I wish to extend the template with another DAQ loop, which has a different rate, or a loop which controls for example a flow controller, how would you do it nicely? Of course we create additional queues (notifiers too if we need graph plotting), etc. but how do you implement the state machine for this new loop? I think we need a separate enum typdef in the UI msg loop, since we need total decoupling between the DAQ and DAQ2 loops? Is that correct, or is there another way to do it? Maybe more compact if we create a cluster typedef, and we put the enumtypdef1 and enumtypdef2 in it, and we unbundle by name them only in the corresponding cases?

 

0 Kudos
Message 7 of 11
(4,633 Views)

I thought about this use case when I added the state checking in 2013. I think once you get past 2 processing loops, the approach taken in the current template becomes unruly. It seems like you'd want an array of states that you dealt with, as opposed to keeping all the states in a single state enum.

 

I'd like to spend some time working something up along those lines, it just hasn't bubbled up in priority yet.

0 Kudos
Message 8 of 11
(4,621 Views)

it would be very interesting to hear more about this topic/template if that possible soon or later (hopefully sooner 🙂 )...

I am still "very" medium level LV programmer, and I am recently digesting such a level templates (learning toward CLD exam in December), ActorFramework and other OOP things still scare me away 🙂

0 Kudos
Message 9 of 11
(4,618 Views)

Good luck on your CLD! Don't forget to read my blog post about preparing for it:

 

http://labviewartisan.blogspot.com/2009/01/labview-certification-preparing-for-cld.html

0 Kudos
Message 10 of 11
(4,616 Views)