LabVIEW
Pre-processor commands
m3nth wrote:
> Does LabVIEW have anything equivalent or near equivalent to
> pre-processor commands? If not, is there any plan to include this in
> future versions?
No it doesn't and I think it would be a bad move to try to add that.
Most C text books agree nowadays, that the preprocessor is a cludge to
solve problems which should have been solved by the C syntax definition
itself.
The only useful thing I can think of for LabVIEW is constant definitions
and that can be solved by globals quite fine.
Rolf Kalbermatter
> Does LabVIEW have anything equivalent or near equivalent to
> pre-processor commands? If not, is there any plan to include this in
> future versions?
No it doesn't and I think it would be a bad move to try to add that.
Most C text books agree nowadays, that the preprocessor is a cludge to
solve problems which should have been solved by the C syntax definition
itself.
The only useful thing I can think of for LabVIEW is constant definitions
and that can be solved by globals quite fine.
Rolf Kalbermatter
m3nth wrote:
> Well I was actually thinking along the lines of a case structure
> inside of which nothing would be compiled, depending on some switch or
> variable not within the program itself but a setting for example. In
> my situation I have two sets of nearly identical hardware drivers and
> want to have the code available for both during development, but don't
> need both of them compiled into the executable, only one or the other.
> In general one of the things I have thought would be quite useful,
> ever since beginning LabVIEW programming is a true way to comment out
> code so that there is no attempt to compile it, which is a big
> difference from a case structure that must be put around compileable
> code and wired to a False constant. Having a "Comment" structure
> instead, or something of the sort, to make anything inside, broken
> wires, invalid definitions--anything would be ok, you could just drag
> stuff in there and there would be no attempt to compile it. Having
> some sort of flag, option or setting then on top of that to set
> whether or not it should compile would be more along the lines of what
> I was thinking of.
Ok, there is a feature in the LabVIEW pipeline along this line but it is
currently only available in LabVIEW PDA and I think FPGA. It is not very
thought out at the moment, and has some implementation issues as it is,
and it won't allow user conditions but rather is conditioned on the
plattform architecture. The problem here is that it is a late addon to
allow code to be conditionally excluded which wouldn't run on the PDA
for instance.
The solution for your different hardware drivers has two solutions. If
you can have the low level drivers installed anyhow in the machine or
your VIs do not call into DLLs but rather use standard LabVIEW
communication channels such as network, VISA or such, you just create a
device abstraction layer which defines at initialization time which low
level driver to use. If you don't won't the hardware drivers to be
installed and they are DLLs, you rather need to consider a sort of
plugin infrastructure. The wrapper VI does on it's initialization load
the according VI through VI server maintaining the reference internally
and then calls that hardware specific driver by reference whenever
needed. You basically write a LabVIEW 2 style global for the wrapper
with a similar connector pane interface as the actual low level drivers
use. All the low level drivers of course need to have the same connector
pane. Works like a charm, is flexible, dynamic and easily extended.
Rolf Kalbermatter
> Well I was actually thinking along the lines of a case structure
> inside of which nothing would be compiled, depending on some switch or
> variable not within the program itself but a setting for example. In
> my situation I have two sets of nearly identical hardware drivers and
> want to have the code available for both during development, but don't
> need both of them compiled into the executable, only one or the other.
> In general one of the things I have thought would be quite useful,
> ever since beginning LabVIEW programming is a true way to comment out
> code so that there is no attempt to compile it, which is a big
> difference from a case structure that must be put around compileable
> code and wired to a False constant. Having a "Comment" structure
> instead, or something of the sort, to make anything inside, broken
> wires, invalid definitions--anything would be ok, you could just drag
> stuff in there and there would be no attempt to compile it. Having
> some sort of flag, option or setting then on top of that to set
> whether or not it should compile would be more along the lines of what
> I was thinking of.
Ok, there is a feature in the LabVIEW pipeline along this line but it is
currently only available in LabVIEW PDA and I think FPGA. It is not very
thought out at the moment, and has some implementation issues as it is,
and it won't allow user conditions but rather is conditioned on the
plattform architecture. The problem here is that it is a late addon to
allow code to be conditionally excluded which wouldn't run on the PDA
for instance.
The solution for your different hardware drivers has two solutions. If
you can have the low level drivers installed anyhow in the machine or
your VIs do not call into DLLs but rather use standard LabVIEW
communication channels such as network, VISA or such, you just create a
device abstraction layer which defines at initialization time which low
level driver to use. If you don't won't the hardware drivers to be
installed and they are DLLs, you rather need to consider a sort of
plugin infrastructure. The wrapper VI does on it's initialization load
the according VI through VI server maintaining the reference internally
and then calls that hardware specific driver by reference whenever
needed. You basically write a LabVIEW 2 style global for the wrapper
with a similar connector pane interface as the actual low level drivers
use. All the low level drivers of course need to have the same connector
pane. Works like a charm, is flexible, dynamic and easily extended.
Rolf Kalbermatter
