LabVIEW VI 能否判断其输出端子之一是否已接线?

发布于 2024-09-15 06:35:55 字数 153 浏览 4 评论 0原文

在LabVIEW中,是否可以从VI内部判断输出端子是否已连接到调用VI中?显然,这取决于调用VI,但也许有某种方法可以找到当前VI调用的答案。

用 C 术语来说,这就像定义一个函数,它接受的参数是指向存储输出参数的位置的指针,但如果调用者对该参数不感兴趣,则将接受 NULL。

In LabVIEW, is it possible to tell from within a VI whether an output terminal is wired in the calling VI? Obviously, this would depend on the calling VI, but perhaps there is some way to find the answer for the current invocation of a VI.

In C terms, this would be like defining a function that takes arguments which are pointers to where to store output parameters, but will accept NULL if the caller is not interested in that parameter.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

浮萍、无处依 2024-09-22 06:35:55

正如所说,您不能以自然的方式做到这一点,但有一个使用数据值引用的解决方法(需要 LV 2009)。给输出参数提供一个 NULL 指针是同样的想法。结果在输入中作为数据值引用(即指针)给出,并由子VI检查不是引用。如果为空,则不执行任何操作。

这是子VI(情况为true当然什么都不做):

alt text

这是调用VI:

alt text

图像是 VI 片段,因此您可以拖放到图表上以获取代码。

As it was said you can't do this in the natural way, but there's a workaround using data value references (requires LV 2009). It is the same idea of giving a NULL pointer to an output argument. The result is given in input as a data value reference (which is the pointer), and checked for Not a Reference by the SubVI. If it is null, do nothing.

Here is the SubVI (case true does nothing of course):

alt text

And here is the calling VI:

alt text

Images are VI snippets so you can drag and drop on a diagram to get the code.

枉心 2024-09-22 06:35:55

我建议你以错误的方式处理这件事。如果编译器不够智能,无法自行避免计算,请制作该VI的两个版本。一种进行昂贵的计算,一种则不进行。然后制作一个多态 VI,允许您在它们之间进行切换。您在设计时就已经知道想要哪个版本(因为您要么连接输出端子,要么不连接),因此只需使用多态VI的正确版本即可。

或者,传入一个变量来打开或关闭计算中昂贵部分的 Case 语句。

I'd suggest you're going about this the wrong way. If the compiler is not smart enough to avoid the calculation on its own, make two versions of this VI. One that does the expensive calculation, one that does not. Then make a polymorphic VI that will allow you to switch between them. You already know at design time which version you want (because you're either wiring the output terminal or not), so just use the correct version of the polymorphic VI.

Alternatively, pass in a variable that switches on or off a Case statement for the expensive section of your calculation.

千秋岁 2024-09-22 06:35:55

正如 Underflow 所说,基本答案是否定的。

您可以看看此处可以获得 NI 提供的最官方、最详细的答案。

扩展你的类比,你可以在 LV 中做到这一点,只不过 LV 没有 C 所具有的 null 概念。您可以在此处查看示例。

请注意,Underflow 链接中提供的代码在可执行文件中不起作用,因为在构建 EXE 时默认情况下会删除图表,并且 RTE 不支持其中使用的某些属性和方法。


抱歉,我发现我误解了这个问题。我以为你是在询问输入,所以我建议的想法不适用。不过,我指出的限制确实适用。

你为什么要这样做?可能还有另一种解决方案。

Like Underflow said, the basic answer is no.

You can have a look here to get the what is probably the most official and detailed answer which will ever be provided by NI.

Extending your analogy, you can do this in LV, except LV doesn't have the concept of null that C does. You can see an example of this here.

Note that the code in the link Underflow provided will not work in an executable, because the diagrams are stripped by default when building an EXE and because the RTE does not support some of properties and methods used there.


Sorry, I see I misunderstood the question. I thought you were asking about an input, so the idea I suggested does not apply. The restrictions I pointed do apply, though.

Why do you want to do this? There might be another solution.

南七夏 2024-09-22 06:35:55

一般来说,不会。

可以使用“脚本”功能对代码进行静态分析。这将需要拉动调用层次结构并跟踪线路引用。

对此进行汇总试验,存在一些困难。同一个图上的多个相同的子 vi 很难区分。此外,终端引用似乎主要可以通过名称来访问,这可能会导致与其他 vi 的同名终端发生一些冲突。

NI 针对该问题的变体做了一些工作;查看

Generally, no.

It is possible to do a static analysis on the code using the "scripting" features. This would require pulling the calling hierarchy, and tracking the wire references.

Pulling together a trial of this, there are some difficulties. Multiple identical sub-vi's on the same diagram are difficult to distinguish. Also, terminal references appear to be accessible mostly by name, which can lead to some collisions with identically named terminals of other vi's.

NI has done a bit of work on a variation of this problem; check out this.

遇到 2024-09-22 06:35:55

一般来说,LV 编译器会优化机器代码,甚至不会将未使用的代码内置到可执行文件中。

这不适用于子VI(因为无法知道您不会尝试以某种方式使用指示器的值,尽管如果LV在构建可执行文件时删除FP,则可以做到这一点,并且可能会这样做),但是有是将其应用于子VI的一种方法 - 内联子VI,这应该允许编译器看到未使用的输出。您还可以将其优先级设置为子例程,这也可能会执行此操作,但我不建议这样做。

按照官方说法,内联仅在 LV 2010 中可用,但在旧版本中可以通过多种方式访问​​私有 VI 属性。不过,我不推荐它,而且 2010 很可能在这方面进行了一些旧版本没有的优化。

PS 一般来说,编译过程的细节不会公开,并且随着 NI 调整编译器而在 LV 版本之间有所不同。整个过程应该在 LV 2010 中得到重大升级,并且 NI 网站上应该有一个网络广播,其中包含一些详细信息。

In general, the LV compiler optimizes the machine code in such a way that unused code is not even built into the executable.

This does not apply to subVIs (because there's no way of knowing that you won't try to use the value of the indicators somehow, although LV could do it if it removes the FP when building an executable, and possibly does), but there is one way you can get it to apply to a subVI - inline the subVI, which should allow the compiler to see the outputs aren't used. You can also set its priority to subroutine, which will possibly also do this, but I wouldn't recommend that.

Officially, in-lining is only available in LV 2010, but there are ways of accessing the private VI property in older versions. I wouldn't recommend it, though, and it's likely that 2010 has some optimizations in this area that older versions did not.

P.S. In general, the details of the compiling process are not exposed and vary between LV versions as NI tweaks the compiler. The whole process is supposed to have been given a major upgrade in LV 2010 and there should be a webcast on NI's site with some of the details.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文