Can I use the "Physical Channel Info" as case selector in case structure?

[Motorbreath]

Hi everyone,

Is it possible to use the physical channel as a case selector? I've been trying and could not managed to use it so.

My block diagram is like this;

Regards,

Ozgur

[RavensFan]

Sure.  It just coerces the value to a string.

How is it not working?  Why do you want to do something this way?

[Motorbreath]

You can see the "Mikrofon 4" there, when i use a enum constant as a case selector, the "cases" changes automatically into the items I determined. When using this Physical Channel, the cases doesn't change. That why I thought it is not working properly.

I'm trying to make a interface for sound measurement which forwards step by step, and this is the first part of it, microphone calibration. I'm using four microphones and want to choose ai0 for mic1 e.g., and determine its RMS value.

I'm trying to manage this by using case structures inside case structures, possibly there is a better way which i don't know. That's why i am doing this in this way.

Regards,

Ozgur

[Motorbreath]

Has anyone got any suggestions?

[RavensFan]

Suggestions about .... ???

Is there anything special about the physical channel for Microphone 4 that causes you to execute different code than you would for let's say Microphone 3?

Right now, all the code inside that inner case structure looks pretty generic, in other words, the same code you would use no matter which microphone you were trying to work with.

[johnsold]

He did say something about calibration, although the code shown does not distinguish microphones.

I suggest a Producer/Consumer architecture.  Do all the data acquisition for all channels in one loop (the producer).  In a parallel (consumer) loop, separate the data for the individual micrphones and do the calibration and any other analysis required. It is a more robust and modifiable approach.

Lynn

[Motorbreath]

The question was that why the cases does not change when using the physical channel as case selector? The other cases probably will have same algorithm, I'm doing this case structure approach in order to make the process step by step.

When I'm completely done with the code, i will try again to find out what is or seems to me wrong.

Thanks for your posts,

Özgür

[dkfire]

You are missing the point. Your case structure is changing its type. It is changed to string.

The reason for that is, that LabVIEW can't know in the development time how many physical channel are available dying runtime. 

You have to manual put in the string for you channels that you expect to be on the system. But do you really know what channels are available at runtime?

It is not the same for enums. Enums are being build at development time, and they stay fix at runtime. You can't change a enum at runtime. That is why LabVIEW is able to change to the name you have give for the enum.

Physical channels is not the best case selector. Maybe you should think a little about your design before going any further.

[Motorbreath]

I've changed the process by designing serial case structures with local variables. I will not be using the physical channel selector anymore.

Thanks for your advice.

Özgür

[smercurio_fc]

---

@Motorbreath wrote:

I've changed the process by designing serial case structures with local variables.

---

That certainly can't be good, whatever it means. What's a "serial case structure with local variables"? Is that something that's hidden away buried in one of those palettes somewhere that only gets shown when you put in a super-secret key in the LabVIEW.ini file? Inquiring minds want to know...