LabVIEW
Issue on Queued message handler and dynamically load/close subvi
Solved!
Hi, Dear LV users
I am learning how to use the Queued Sate machine Architecture. I created a simple project including a "main.vi" to dynamically load a sub vi "sub_Vi2.vi" in the "initialize" case. The sub vi simply open a setting file and load setting to some control and write those values back to the setting file. If the setting file is not created, the sub vi will create it before user close the subvi.
In the "Exit" case of my "main.vi", I send "true" to the stop button in subvi to stop running it. But the sub vi did not write those values back to the setting file, nor created a new one when I delete the setting file.
There is another vi I made "main1.vi", which dynamically load and close the subVi. And it work as well as I expected: create the file and write data back!
Can any one help me to understand the code? I also attached the front panel and diagrams and the source code. It is in LV 2012.
Best regards
CQ Li
Just a couple of observations.
Clean up that block diagram. It hurts to look at it, and it distracts from the task at hand if you need to concentrate on following all those criss-crossing wires and wires end up behind other wires. Besides, in just about every case I've seen, disorganized wires promote disorganized thinking. But the other way is true, also. Cleaning up your wires organizes your thoughts.
Hi, Bill
thank you very much for your suggestion. I cleaned the block digrams and simplified some functions. Infact, most of the code in "Main.vi" was generated by Labview templete. I only added some portion in "initialize" and "Exit" case in Main.vi.
The strange thing is:
Main1.Vi works well: load subvi, create or replace the setting.txt file. Although Main.vi can load subvi, the subvi could not write data back to setting.txt, nor create a new file if setting.txt was not there.
thank you very much.
I reposted the source code too.
I would get rid of sub_vi2.vi and take its sequences and put the first sequence (minus the sequence structure itself) in your init state and your write sequence (minus the sequence structure) in your exit state. Wire the data directly since you will no longer need the controls to shuttle the data back and forth...
Hi, Bill
In fact, the Sub vi was a very simple version of a Vi by third party for controlling some equipment. I hide the controlling part with the while loop.
The puzzle is: in the exit case, the sub vi stops after "true" was sent to its stop button, but the setting file was not replaced/created. But in the Main1.vi, it works fine.
best regards
@CQ_Li wrote:
Hi, Bill
In fact, the Sub vi was a very simple version of a Vi by third party for controlling some equipment. I hide the controlling part with the while loop.
The puzzle is: in the exit case, the sub vi stops after "true" was sent to its stop button, but the setting file was not replaced/created. But in the Main1.vi, it works fine.
best regards
LOL - sorry that I didn't recognize that. I was wondering why absolutely nothing was going on inside that VI. That's a neat way of incorporating a standalone VI into your code. I see nothing wrong with the implementation of main1.vi, actually. If I was being nitpicky, I would say replace the polling of the stop button with an event structure, but is it really worth the effort for something so simple? Unless this is kind of like a "self-training exercise" (I do this a lot to solidify my understanding of new methodds of doing things) to try to implent a QMH architecture, I see no problem using the main1 method.
[edit] This is a great day for me to not read things thorughly. Sorry, you ARE trying to learn! Sorry 😞 [/edit]
Hi, Bill
yes, you are right. it is a self training. I also want to check if my idea of stopping a Vi by "sending command" outside of it works or not with QMH.
