Running Call Library Function Node in UI Thread

[fransv1963]

Hi there!

The Call Library Function Node has a undocumented upper left input wire, left of the output wire, corresponding to the return value, if any.

It looks like I can use this wire to influence the order in which different Call Library Function nodes execute. Is this a documented feature I can rely on or am I walking on thin ice here ?

Furthermore I call the same non-thread-safe function twice in my VI, the Call Library Function Node of each being set to "Run in the UI Thread". If I don't enforce the functions to be called in sequence and I change the value of an unrelated VI control while the VI is running (in a While loop), the function generates an error as if it was called by LabVIEW assuming the function w
as thread safe. This behavior is very repeatible.
If I enforce both instances of the same function to be called in sequence (by wiring the output value of the 1st function to the undocumented upper left input wire of the 2nd function), all problems are gone.

Normally I'd expect that changing a totally unrelated VI control (double) which also runs in the UI thread may have no influence at all, but running the VI indicates otherwise. I tried to reproduce the problem based on a simple example, but I'm unable to obtain the same effect.

Is there anyone out there who can comment on the behavior I described ?

Thanks.

[Anonymous]

You are right on the money about using the greyed out terminal for
controling the execution of the call library nodes.

I have not seen the behavior you report and would be interesting in
seeing your code. What error do you get? Am I correct in assuming
that the unrelated numeric control has no wires that run to the call
library node? What version of LabVIEW are you using?

[Anonymous]

Jeremy,

thanks for the confirmation with respect to the greyed out terminal. I
had to find out the meaning of "being right on the money about
something", so thanks for extending my knowledge of the English
language too ... 8-)

Please find the LabVIEW code in attachment. It uses a HP836xx LabVIEW
instrument driver (controlling an RF source) and also calls a C API to
have work done in Mathematica (www.wolfram.com) using MathLink. We
know that the functions which communicate with Mathematica are not
thread safe, so all function calls are set to "Run in UI Thread".

If you look at the block diagram, you find the return value of
LSNAgetEquiTimeStamps() connected to both the greyed out input
terminals of both LSNAgetTimeData().

The VI runs fine, setting the source and collecting data, until I
change the "Power(dBm)" control value. After a few changes, the C API
indicates that the packages which are exchanged with Mathematica are
"out of sequence". The same happens immediately if I indicate that the
functions are thread-safe, by specifying them to be re-entrant. So I
tend to conclude that one way or another the 2nd LSNAgetTimeData() is
executed before the 1st one has finished.

If I eliminate the wire connecting the return value of
LSNAsetEquiTimeStamps() to the lower LSNAgetTimeDat () input terminal
and connect the return value of the upper LSNAgetTimeData() to the
greyed out input terminal of the lower LSNAgetTimeData(), everything
works fine. I can change the value of the "Power(dBm)" control "a
volonte". This is consistent with my assumption above: by changing the
wires I forced the 2nd LSNAgetTimeData() to wait for all inputs to be
available. Because one input is provided by the 1st LSNAgetTimeData(),
I'm sure this one has completed before the 2nd one is invoked.

I cannot explain what is happening. According to the manual, all code
linked to each function node should complete before code linked to
another function node is executed. However, I think I've read
somewhere on the NI website that the UI consists of two threads and
perhaps something goes wrong (internally in LabVIEW ?) when the UI
thread is informed about the fact that the "Power (dBm)" control has
changed.

I don't claim LabVIEW is to blame ... FYI ... the version I'm using is
(the evaluation version) of LabVIEW 7 Express.

Thanks.
Frans.