Forcing a case

[Mattetc]

Hello,

I am writing a control program for an experiment setup that involves several instruments. I decided I would like to run the whole experiment with one VI. To keep the control panel within the screen I decided to use a tab container to seperate the different instruments.

I have wired the tab control to a case structure. This means that no instructions are executed on a tab unless the tab is selected. Each tab controls a different instrument, except for the last tab which is the measurement tab, where the user can configure and run a measurement. That's fine but if the user were to run a measurement and then attempt select another tab in the middle of the measurement then there is going to be issues.

On the other hand, it would be handy to be able to navigate to and view the other tabs while the measurement is in progress, but not actually change any values in these tabs because it would mess up the measurement.

Can I force one case (measurement) to run all of the time while the other cases only run if selected, and at the same time use the tab control to govern the case structure?

I realise that normally one would just not include the case we want to force in the case statement and just have it run in the next frame of a sequence structure (so that it runs all the time), however, I'd like the tab control to govern the case statements.

I could just get over it and not even have a measurement tab, but have the tab containter sitting on the front panel and next to it I could put the measurement functions but I would like to keep the measurement tab because it makes the front panel neat.

Alternatively, can I make it so that when a 'run measurement' button is pressed it is impossible to use the front panel until the measurement is complete. This would preferably inlude pop up alert messages that inform the user, if they attempt to use the front panel, that they cannot navigate away or alter any settings until the measurement is complete. These pop ups should also not interupt the execution of the measurement program either.

The downside of this second option is, again, it would make it impossible to go and view the other tabs while the measurment is in progress.

I hope this makes sense and hopefully someone has good advice.

Matt

[MoReese]

---

@Mattetc wrote:

Hello,

 

Can I force one case (measurement) to run all of the time while the other cases only run if selected, and at the same time use the tab control to govern the case structure?

I realise that normally one would just not include the case we want to force in the case statement and just have it run in the next frame of a sequence structure (so that it runs all the time), however, I'd like the tab control to govern the case statements.

 

---

You could use a state machine to control execution of your case structure.  But no, you cannot run one case all the time and then run another in parallel in the same case structure.  You could use a second case structure with your measurement tab that runs in parallel with your main case; however, controlling both cases with the same tab control will yield the same result.  You could provide a range for the case such as 0..5,  or however many cases you have.  This would except all ranges for the tabs and run the case no matter what.  Another option would be to include the measurement functions into a sub-vi before the case structure within the while loop, but it sound like you are deadset on keeping everything on one block diagram.

[Mattetc]

Thank you for your reply. Those suggestions may come in handy.

I have figured out another idea, see what you think.

I use a sequence structure where the first sequence frame contains the case statement which is controlled by the tab control. But I leave the measure case empty. Then in the second sequence frame I have the actual measurement controls.

This way I have renendered the measurement tab effectively independent to the rest. The downside is that when viewing the other tabs while a measurement is taking place they will be static (because there is some for-loop running which needs to finish before new instructions are executed, so those tabs won't be updated). But at least you can flip back and see what the settings were before running the measurement without disturbing it, even though you've changed the case statement.

Another way is to not bother at all with the case statement. You can still have the tab container and run all your instruments on the different tabs and view them while the measurement is taking place. They will still be static however while a measurement is taking place. This is more or less unavoidable unless you interleave measurement instructions with instructions on other tabs (and who would bother?).

The advantage to keeping the case structure is that because only the tab which is selected is running, the CPU is freed up. I'll have to investigate a bit to see if that actually matters. If not, it makes sense to simply not bother with the case statement.

Cheers,

Matt

[JÞB]

NO NO NO !

OK so you want to configure equipment to take a measurement- take and analize the measurement and, (Why oh why but maybe OK) let the user fool around looking at the selected instrument configuration during measurement execution.  (by the way- isn't your system supposed to be doing something more important than feeding the technician's curiosity?)

Sure give the user the chance to abort the experiment-  goes without saying- but, use sub-vi pop-ups to set configuration and options. theave the main experiment execution in its own world and leave it alone as it is going!  (even Schroedenger encouraged that!)

[Mattetc]

When I program it the way I just described that is exactly what happens. The measurement can run undisturbed and you can also view the different tabs. It's a win-win situation.

[JÞB]

---

@Mattetc wrote:

When I program it the way I just described that is exactly what happens. The measurement can run undisturbed and you can also view the different tabs. It's a win-win situation.

---

not really.  I want you to think about the experiment- in a scientific manner.  design the hypothisys, configure the data collection, perform analisys given the equipment constraints as perposed. draw conclusion.

What you are putting forward as advantagous, is contrary to every general purpose test equipment's control structure.  for exactly this reason- the test (your application) will operate differently if the user is allowed to perturb it by peeking. (yup- those peeks and tab turnings take machine cycles, change timing and are additive to the Heidenburg princpal)  hence, if you are going to experiment- use a proven method.  The analist can always look at the data report to discover the conditions of test. The operator does not need to "fat-finger" around and add anaomilies to the data.

[Mattetc]

The time it takes for tab turning is insignificant since before incrementing in the measurement control there is always a query sent to make sure a measurement has been taken at the correct step, the next increment does not happen until that query is positive. I'm not sure what the Heisenberg uncertainty principle has to do with that.

I think that will be all.

Thank you

[MoReese]

I believe Jeff was simply pointing out that by changing one parameter causes another to be unpredictable (or less predictable).  You can control one parameter, timing, but not control, or vice versa.  I've been on this forum for awhile now and have come to respect Jeff and his advice he's given in his posts.  Don't get offended when someone try's to help.  We are all volunteers here.  Keep an open mind when someone with more experience trys to give you suggestions.