07-27-2011 09:24 AM
@Motorbreath wrote:
The other cases probably will have same algorithm, I'm doing this case structure approach in order to make the process step by step.
Probably? If they are going to have the same algorithm, then there is no need to have a case structure based on the physical channel name.
If they aren't going to have the same algorithm, then that is something you need to figure out now. So far, with what you've shown in the case structure, I wouldn't call that an algorthim. I think your project is a case where it is critical for you to sit down and design what you want the program to do even before you start laying down wires.
I don't think building a case structure that uses physical channel names is a good solution for you. It is too likely that physical channel names will change down the road.
If I were you, I'd use an enum to define the cases. Call them something like Channel Type A, Channel Type B, Channel Type C, ..... Then if you need to vary the case structure based on the physical channel, use a subVI that takes the channel name and uses some sort of lookup table that determines which channel type is should output as an enum to feed to the case structure. This would make the code a lot more modular and you don't have to go in and revise the case structure everytime a channel name changes. At worst, you'd only have to change a subVI. If things are designed well enough, then the subVI will have the intelligence built-in to figure out the correct channel type based on the name. But probably the best option is to have the subVI read in configuration file that links the channel name to the channel type enum. That way if you need to change a channel name or channel type, or add a new one, all you need to do is edit a text file rather than revising a case structure or even editing a subVI.
07-27-2011 01:26 PM
Working on this now. The "super block".
07-27-2011 01:32 PM
Your code is not very efficient. It also doesn't make much sense. What is the purpose of the Boolean controls? Are these intended to select which microphones to gather data from? Why not gather all the data and use the Select Signals VI to pick out the ones you want?
Also, why are you writing to the tab control via a local variable? Your case structures are in a loop. This means if you have more than one case active your tab control is going to keep switching between two cases. That would seem very jarring to me.
07-27-2011 01:44 PM
Calm down smercurio 🙂
The booleans are for leds, when 1 case finishes, led is on to say you're done.I'm "TRYING" to prepare this for a person who has not even little knowledge about the process.
It doesn't keep switching between each other, once a OK button is pressed it is done with the tab. I'm not using continuous samples, so it doesn't matter so much.
The thing I'm trying to manage is prepare a interface as simple as possible, step by step and it can be hard sometimes for me. I've never said I know all about programming in labview; I'm newly getting used to its interface and programming logic. So you do not need to be harsh.
Sorry if I'm mistaken or misunderstand anything.
Regards
Özgür
07-27-2011 02:02 PM
@Motorbreath wrote:
Calm down smercurio 🙂
I'm perfectly calm. What made you think otherwise?
The booleans are for leds, when 1 case finishes, led is on to say you're done.I'm "TRYING" to prepare this for a person who has not even little knowledge about the process.
It's not going to work that way. There is no data dependency between the setting of the LED and the rest of the code inside the case structure. LabVIEW will happily set the LED before any of your other code is done.
It doesn't keep switching between each other, once a OK button is pressed it is done with the tab. I'm not using continuous samples, so it doesn't matter so much.
What OK button? I don't quite understand what you mean the since you're not using continuous samples it doesn't matter so much. What doesn't matter?
I'm still not clear on what you're trying to accomplish in the first place, so perhaps we need to take a step back here and you explain better what you're trying to do at a high level, rather than asking how to control a case structure. You said you're trying to create an interface. What kind of interface?
I'm newly getting used to its interface and programming logic. So you do not need to be harsh.
Oh, trust me, you ain't heard harsh yet.
07-27-2011 02:21 PM
Okay, so now you got 4 buttons (Mikrofon 2 - 4 and something I can't read). They can each select a case structure.
What happens if I select 2 buttons?
What happens if there are no buttons selected? Will your while-loop just spin as fast as it can ? (100% CPU load?)
How can I see witch one I have activated before, when the Tab control has changed page?
There seems to be some questuions you are missing asking your self.
Draw a flowchart ( State or Activity diagram in uml ) of what you would like your program to do.
Don't think about the front panel design, that is the LAST thing right now.