LabVIEW
memory goes crazy when calling a sub-vi
jcrooke wrote:
> Thanks for your insight, Greg. I was surprised to learn that global
> references each contain a copy of the data. This implies that each
> time data is written to a global, each copy of that global must get
> updated. The process sounds amazingly inefficient. Now I know why
> globals are taboo in LabVIEW.
Well for scalars they are ok. But never use them for arrays. The reason
this must be done so, is that LabVIEW execution is determined by dataflow
almost exclusively and that allows for multiple code sections executing
quasi-simultanous. Treating globals by reference could give you an issue
where one part of the program reads the global while another one writes
it, causing the read to read half of the old data and half of the new
data. In C you have typically sequential execution and if you happen to
create multiple threads and read a global from one thread while writing
it in another it is the programmers responsibility to protect that
resource or his program will behave erratically at best.
> I have noticed that most of the NI code for interfacing with registers
> and managing memory have a dll at the core. The function details are
> handled outside of the LabVIEW development toolbox, precompiled and
> self contained. It sounds to me that the only way to efficiently and
> effectively get control over the memory is to write the code block (in
> c or something) to manage the data the old fashioned way. It appears,
> as I have anxiously suspected, there's no substitute for knowing how
> to manage memory at the lowest level.
That is not the main problem. LabVIEW data types are a little different
than what C usually uses and it is easier to create the translation in C
than in LabVIEW. And since almost all direct hardware interfaces are
really C oriented this means that there is a DLL sooner or later. You
can't write a device driver in LabVIEW at all, as that is privileged
code executing in kernel space. Accessing a device driver from LabVIEW
although possible is quite a pain as the high level data structures used
in LabVIEW are most often completely different than the low level
interface of the device driver. So there again you need an intermediate
translation unit which is simply more convinient to write in C. And if
you don't know how to write that in C you couldn't possibly create a
direct interface in LabVIEW, but since you then know C it is easier to
do it in C then.
Not to mention that device driver interfaces are mostly undocumented and
often considered company secret. Putting the interface in a DLL hides
this interface much more effectively than trying to do everything
directly from within LabVIEW.
Rolf Kalbermatter
> Thanks for your insight, Greg. I was surprised to learn that global
> references each contain a copy of the data. This implies that each
> time data is written to a global, each copy of that global must get
> updated. The process sounds amazingly inefficient. Now I know why
> globals are taboo in LabVIEW.
Well for scalars they are ok. But never use them for arrays. The reason
this must be done so, is that LabVIEW execution is determined by dataflow
almost exclusively and that allows for multiple code sections executing
quasi-simultanous. Treating globals by reference could give you an issue
where one part of the program reads the global while another one writes
it, causing the read to read half of the old data and half of the new
data. In C you have typically sequential execution and if you happen to
create multiple threads and read a global from one thread while writing
it in another it is the programmers responsibility to protect that
resource or his program will behave erratically at best.
> I have noticed that most of the NI code for interfacing with registers
> and managing memory have a dll at the core. The function details are
> handled outside of the LabVIEW development toolbox, precompiled and
> self contained. It sounds to me that the only way to efficiently and
> effectively get control over the memory is to write the code block (in
> c or something) to manage the data the old fashioned way. It appears,
> as I have anxiously suspected, there's no substitute for knowing how
> to manage memory at the lowest level.
That is not the main problem. LabVIEW data types are a little different
than what C usually uses and it is easier to create the translation in C
than in LabVIEW. And since almost all direct hardware interfaces are
really C oriented this means that there is a DLL sooner or later. You
can't write a device driver in LabVIEW at all, as that is privileged
code executing in kernel space. Accessing a device driver from LabVIEW
although possible is quite a pain as the high level data structures used
in LabVIEW are most often completely different than the low level
interface of the device driver. So there again you need an intermediate
translation unit which is simply more convinient to write in C. And if
you don't know how to write that in C you couldn't possibly create a
direct interface in LabVIEW, but since you then know C it is easier to
do it in C then.
Not to mention that device driver interfaces are mostly undocumented and
often considered company secret. Putting the interface in a DLL hides
this interface much more effectively than trying to do everything
directly from within LabVIEW.
Rolf Kalbermatter
jcrooke wrote:
> I want to thank you guys, Greg and Rolf, for taking the time to
> elaborate on the issue and encourage you to do so in the future. You
> both seem very knowledgeable and it helps to get a better
> understanding of what is really going on with the code. I have been
> operating under some flawed assumptions. This is a good forum for
> gaining understanding of some important, basic LV characteristics.
> Perhaps some of the passive readers of this discussion will benefit as
> well.
>
> I don't really want to extend this discussion line further, but I am
> curious as to how you know so much about the internal structure of
> LabVIEW. Have you actually worked as a developer for one of the
> LabVIEW products
, perhaps LabVIEW itself?
Well for Greg it is easy. He is one of the core LabVIEW developers and
although he doesn't know every detail from his head, he can go and look
in the sources, if he needs to.
For me it is just 12 years of working with LabVIEW and having read a lot
on Info-LabVIEW, as well as having done my own extensive low level C
programming. Besides that, there has been a time when I had some spare
time left to dig rather deep into LabVIEW and experiment with it on many
levels to find out some of its internal workings.
Rolf Kalbermatter
> I want to thank you guys, Greg and Rolf, for taking the time to
> elaborate on the issue and encourage you to do so in the future. You
> both seem very knowledgeable and it helps to get a better
> understanding of what is really going on with the code. I have been
> operating under some flawed assumptions. This is a good forum for
> gaining understanding of some important, basic LV characteristics.
> Perhaps some of the passive readers of this discussion will benefit as
> well.
>
> I don't really want to extend this discussion line further, but I am
> curious as to how you know so much about the internal structure of
> LabVIEW. Have you actually worked as a developer for one of the
> LabVIEW products
, perhaps LabVIEW itself?
Well for Greg it is easy. He is one of the core LabVIEW developers and
although he doesn't know every detail from his head, he can go and look
in the sources, if he needs to.
For me it is just 12 years of working with LabVIEW and having read a lot
on Info-LabVIEW, as well as having done my own extensive low level C
programming. Besides that, there has been a time when I had some spare
time left to dig rather deep into LabVIEW and experiment with it on many
levels to find out some of its internal workings.
Rolf Kalbermatter
