data types used in a sub VI - selecting the correct input and output types?

[dave_vic_ozz1]

data types used in a sub VI - selecting the correct input and output types?

I can never work out how to choose an input or output format for Subvi's.

I want to create a SubVI for the code in red. I needs an VI Server Reference compatible input and an output that goes to  a waveform.

Thanks in advance.

[GerdW]

Hi Dave,

select the part of the blockdiagram marked by your red line and choose "create subVI" from the edit menu: no problem creating a subVI and choosing the correct in/out datatypes…

- You don't create a waveform output, you create a DDT output!

- Why do you typecast your reference to an integer number?

- Why do wire the typecasted reference to the DDT input of the SetAttribute function?

[dave_vic_ozz1]

Thanks GerdW

- You don't create a waveform output, you create a DDT output!

A. thanks

- Why do you typecast your reference to an integer number?

A Still getting my head around data types. My goal is to link the name on the screen (numeric label) to the CSV file header which is currently "Untitled n" as the local variable passes its value only. The name on the screen chages from time to time as relocate pressure tansducers and temperature probes. I want the CSV file to follow these changes automatically.

- Why do wire the typecasted reference to the DDT input of the SetAttribute function?

A. Followed an example shown elsewhere. 

[GerdW]

Hi Dave,

My goal is to link the name on the screen (numeric label) to the CSV file header which is currently "Untitled n" as the local variable passes its value only.

- Which "local variable" are you talking about? There is none in your image…

- How do you create your CSV file?

- Why don't you write a header line in your CSV file containing the column titles?

The name on the screen chages from time to time as relocate pressure tansducers and temperature probes.

Why does the LABEL change? The label is given at edit time and CANNOT change in runtime.

In conclusion you need to edit your VI to change label names, and when you do so you can also edit a column title array seved in your CSV file…

If you want real runtime changes you should use CAPTIONS instead!

I want the CSV file to follow these changes automatically.

Use captions instead of labels.

Use arrays, filled by a configuration file, to store channel/column names. Save that array as header line in your CSV file…

[dave_vic_ozz1]

GerdW,

I realise now I have taken us in the wrong direction. apologies for that.

History, this is not my code and I do not own the process and NOT my preferred method of using it. I was looking for a simple way to make subtle changes.

What we do - We use these programs to collect data from typically 6 pressures and 6 temperature probes and capture RS232 / USB VISA strings from sensors.

So every few weeks / months or up to a year we rearrange each sensor location to suit the new process. I did not write the code. I cannot change the procedure too much without resistance.

So headers in the CSV file have the DaqMX string passed through the code. Great.

Other data to the CSV file comes from calculations or extracted from the VISA string. Hence why we have headers with "Untitled 1 ()". These values also go to a History Chart.

So I was looking for a simple way to read the the local variable label as it is always linked to the front page indicator. People can cope with editing the indicator label, save the VI and hit run.

TL;DR - GerdW is now a psychologist.

[GerdW]

OMG…

Apart from other stuff: what's the point in using a Relay function that is ALWAYS enabled?

So every few weeks / months or up to a year we rearrange each sensor location to suit the new process. I did not write the code. I cannot change the procedure too much without resistance.

So every few weeks someone fiddles with the code (in a rather bad manner) instead of a professional making up a scalable/configurable code within one or two weeks?

Sounds like a very reliable measurement you are doing over there…

[Dennis_Knutson]

Omg squared. Horrible looking code. I'll echo Gerd in recommending that program be tossed and rewritten from scratch by someone much more familiar with LabVIEW.