10-01-2014 09:19 AM
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,
Solved! Go to Solution.
10-01-2014 09:44 AM
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).
10-01-2014 10:25 AM - edited 10-01-2014 10:27 AM
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 😄 )
10-01-2014 10:30 AM
@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.
10-01-2014 10:36 AM
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 🙂
10-01-2014 10:39 AM
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.
10-01-2014 10:49 AM - edited 10-01-2014 10:50 AM
@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?
10-01-2014 10:54 AM
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.
10-01-2014 11:17 AM
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 🙂
10-01-2014 11:19 AM
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