10-23-2018 09:14 AM
I know this is pretty basic, but I just can't remember how.....
I have two programs, that need to run independently. Program A does a bunch of serial I/O and displays status on its front panel. It sends data via Global variables (I know...) to/from Program B. Program B does a lot of manipulation of the data and sends it back to Program A, again with global variables.
When I start Program B, it calls Program A and both start and run fine as long as Program B stays on the main screen. If program B calls a subvi, then Program A no longer response to controls on its front panel. All of the indicators on Program A (data) are still fine.
What is it about basic program control that I have forgotten.
Muddled in Munich,
Steve
10-23-2018 09:18 AM
Hi Steve,
What is it about basic program control that I have forgotten.
You forgot to attach your VIs A and B. Or atleast some exampe VIs to demonstrate the problem…
Program A no longer response to controls on its front panel
VI "A" no longer reads its control values?
10-23-2018 09:21 AM
You are right. I did not include them because they are massive. And unexecutable without the I/O attached. Is there some other way to illustrate? Photo? Movie?
Befuddled in Bavaria,
S
10-23-2018 09:25 AM - edited 10-23-2018 09:26 AM
Hi Steve,
I did not include them because they are massive.
Being "massive" usually is a bad sign when discussing execution problems.
What about some example VIs showing the same problem?
(Sometimes you will find the problem when you try to replicate it…)
Grüße nach München!
10-23-2018 09:51 AM
The examples attached do exactly what my programs are doing. Program B starts Program A. When Program B calls a subvi, SubVI C. Then my program, the discrete controls (custom) cannot be clicked. In the example attached it all works fine.
Frustrated in Friesing
10-23-2018 09:59 AM
It would have been easier if you named it so Program A called Program B which called subVI C.
You should off small waits in each of your loops. I just heard my laptop fan go crazy because of all those CPU burning loops.
What you are forgetting is that the loop in program B can't go onto its next iteration until everything inside that loop is done executing. Well the True case of the case structure is not done because the code inside of it is not done. The code inside, SubVI C is not done because you have a loop inside of it that won't stop running until you hit the stop button in it.
Basic rules of DATAFLOW.
10-23-2018 10:20 AM
Yes, I should have put the waits in there, but I was in a hurry.
I think that I understand you last paragraph, but my issue is that the sample works and my programs do not. And they have all of the waits in them. I even put an indicator on the i (iterative no.) of the while loops and can see them all running. But program A is still ignoring its controls.
Any other ideas?
10-23-2018 10:25 AM - edited 10-23-2018 10:27 AM
Do you have any event structures? And do they have event cases with the flag set to lock the front panel until the event completes?
What is different about your real program as compared to the sample program that the sample works but the real one doesn't?
10-23-2018 10:46 AM
I found it. My subvi's are modal, because I don't want the operator to skip screens. The example that I sent you all of the samples were default. I my programs when I was in a modal subvi, then it locked everything else up. If I put the Program A as modal, it now locks up Program B so I cant even call the subvi. At least I can see what is going on. Going to go read the tutorials WINDOWS BEHAVIOR now.
Thanks,
S
10-23-2018 10:48 AM
I'm glad you found it.