How do I pass a string structure into a VI?

[tbob]

---

@Samweis wrote:

There's nothing in the manual about connecting unused channels to a ground. I'm assuming the device is designed properly internally.

---

Samweis is correct.  Here is another excerpt from the manual.

"Each channel has a resistor that produces an input impedance between the TC+ and COM terminals.

and between the TC– and COM terminals"

So there is no need to ground unused channels because the 9211 already does this.

.

.

[Samweis]

Well I determined that it is the calibration that "fixes" channel 0. It appears that TC0 was calibrated, I have no idea how, and unfortunately I wouldn't know how to go about calibrating the remaining channels.

Anyway, I know it's the calibration because if I uncheck "Enable Calibration" on this screen (see attached) then TC0 begins to behave exactly like the other two channels.

Question: Is there a way to use the same calibration data for TC0 on TC1 and 2?

[johnsold]

I am not familiar with that module.

The manual does not mention calibration.  Are you referring to the internal cold junction correction or the auto-zero? If either of those channels is sampled immediately before TC0, it might result in the behavior you observed.

Have you tried shorting the unused channels?  The manual shows 20 megohms of resistance across the unused inputs.  If your environment is noisy, a high input impedance channel like that might pickup noise.

Lynn

[Samweis]

Oh sorry I forgot the image. See attached.

No I have not tried shorting it. I'm pretty sure it's a software / calibration issue because, as I described before, if I uncheck "enable calibration" on Channel 0 then it behaves EXACTLY like TC1 and TC2. That is, the same values and everything.

Therefore, if I could simply enable the same calibration correction on the other two channels then it would be fine.

[johnsold]

I do not have the DAQ Assistant so I cannot help you with that.

Lynn

[Samweis]

Okay, another (maybe simple) question:

How do I process an input data stream as individual data points?

The input from my thermocouples is coming into the DAQ assistant as a stream. I'm getting an error when I try and compare data points from two thermocouples.

The type of the source is Dynamic Data.

The type of the sink is double [64-bit real (~15 digit precision)].

"The type of the source is Dynamic Data.

The type of the sink is double [64-bit real (~15 digit precision)]."

I understand the error and why I'm getting it. But I don't know how to force my data to be interpreted in the correct way.

Please see attached screenshot for what I mean.

[smercurio_fc]

The Greater or Equal? function does not accept dynamic data for its lower terminal You need to convert the dynamic data to real data using the Convert From Dynamic Data VI.

[Samweis]

Sweet thanks that's just what I was looking for.

If anyone would be so kind I'm still having trouble with the Arcus-provided utility_panel.vi.  I understand how it works - with the case structure and everything - which seems to me a pretty clever little system.

Anyway, when I run the program this is what I see (screenshot5 attached), so I select the motor, and see this (screenshot6). There's no pull-down menu to select commands, although there should be, shouldn't there? So all I can do is manually type in commands. So that's boggling me.

And the other thing is, what is the array function doing?

[nathand]

---

@Samweis wrote:

Anyway, when I run the program this is what I see (screenshot5 attached), so I select the motor, and see this (screenshot6). There's no pull-down menu to select commands, although there should be, shouldn't there? So all I can do is manually type in commands. So that's boggling me.

And the other thing is, what is the array function doing?

---

Can you be a bit more specific?  Which array function, the one that's wired to the case selector?  The way they set up that program, it can "queue" several commands by building up an array.  There's a delete from array function that takes the first command off the list.  That first item goes to the case selector, and the rest of the array is kept in the shift register for the next loop iteration.  Each command in the array is processed one after another, and new commands can be added to the end of the array.

The utility panel appears to be designed as a top-level example of how to use the other functions in the library.  You probably don't want to use it as a subVI inside your program; instead, you want to use the other VIs in the library inside your code as demonstrated by the utility panel.  The command_center VI expects an input of an array of commands to execute, where those commands are enumerations (accessed through a pull-down menu).  A good learning experiment would be to modify the utililty panel so that there is a pull-down menu of commands.

[Samweis]

Yes I meant the one that is wired to the case selector. Thank you.

How would I go about editing the array, or viewing the order they're processed? I don't see it on my front panel.

So every state in the case selector is processed. I can buy that. Although the program is processing commands for no apparent reason (like getIdleCurrent, getFirmwareVer, etc. then this data is not displayed). When I add an indicator in the "getLowSpeed" and "getHighSpeed" states it does populate those values.