LabVIEW Idea Exchange

Hello,

It should be nice to improve the standard LabVIEW TCP/IP VI library in order to include a way to test if data can be read on a connection.

=> Data available VI ... something like ByteAtPort for serial interface.

Having such a VI could help to create TCP/IP applications without having to hang and wait for timeouts !

Thanks.

Manu.

The current way to bind many shared variables to an OPC client, is through browsing a tree and selecting.

This is very time consuming when you have hundrends or thousands of tags to bind. Specialy if the all the tags are not in the same path.

A better way, is to bind the variables, by simple text.

Example: We will insert the following text

A1M01Z1:value

A2M01Z1:value

A3M01Z1:value

and LabVIEW will automatically create 3 variables, bounding to those addresses (with the same name, prefered). Many OPC Servers supports this type of address.

Note that the true path of A1M01Z1 could be something very big, like:

My Computer\OPC ABB.lvlib\_OPC1\[Control Structure]\Root\NETWORK 1\Nodecm3\Extended Process Objects\MB300 AI\A1M01Z1\VALUE

This way you can add thousands of items in minutes. It is quite easy for the R&D team to implement and will help many professional engineers.

Most probably, this idea will not accept many kudos, but i think R&D must consider to implement this.

(this was discussed with NI technical suport, Reference#3279019)

Thank you all, for reading

Although it appears that the 2020 version of the Block Diagram Cleanup Tool (BDCT) does do a better job than its predecessors, I would still say that the BDCT’s results are still less than optimal. Most LabVIEW Idea Exchange posts concerning the BDCT talk about label positioning and alignment.  Here I would like to focus on the issue of horizontal expansion of the block diagram and a holistic view of what LabVIEW features contribute to that effect.

Like most programmers, when developing a VI block diagram, I try to keep the diagram no more than one screen wide.  I have learned a few tricks over the years that help manage horizontal expansion, such as resizing an object’s label so that the words appear on multiple lines before running the BDCT. This allows for some compression horizontally and allows for some growth vertically to compensate. Horizontal expansion of the block diagram is certainly expected to some extent because data flow happens left to right, of course; but it would seem logical to incorporate that knowledge into the BDCT algorithm to compensate and find ways to adjust the spacing so that the rearrangement creates more a bit more vertical expansion and less horizontal expansion—while still satisfying usual criteria such as no backwards-running wires.

Because data flow is horizontal, to help the BDCT work better, NI may want to think about what visual features—other than left-to-right data flow—contribute to a unnecessarily wide block diagram. I seldom have an issue with a block diagram becoming too tall.  Admittedly, poor programming technique can result in too-wide block diagrams, but let’s look at a few other things. What elements of LabVIEW’s block diagram unnecessarily consume width? Here’s a few that I could think of:

1. Long names in bundle/unbundle cluster objects, property/invoke nodes, Enum/ring constants, local variables, formula nodes, etc. – Most LabVIEW-supported languages are left-to-right horizontal. Long names, especially when using nested clusters, take up horizontal space. I like being able to use long names; it helps the code to be more self-documenting. If those type of objects supported word-wrap, that would help conserve width.
2. Expression nodes and multi-digit constants – no word-wrap available here either.
3. Named terminals of timing and event structures – They are what they are, and you cannot remove all of the ones you don’t use, and so they take up space horizontally.
4. Some native functions – There are some LabVIEW native function icons that are wider than they are tall. Some examples: In-Range/Coerce and Initialize Array.
5. Shift registers – It has a subtle effect, but shift registers are wider than they are tall. Do they have to be that way?

To fully tackle this issue, I believe you have to look at things holistically and not just as potential improvements that could be made in the BDCT.  Recognize that data flow is left-to-right horizontal and you will have long text names; you can’t really do anything about that. However, there are other things that could be done in LabVIEW feature-wise to help compensate for width-wise block diagram growth.

One of my planned projects is to write home automation software for my new house. I already have three iPads installed in the wall (kitchen, theatre and upstairs), all my awning windows are motorised, I have a solar powered hydronic in-slab heating system that needs the right type of control, earth tubes, a whole-house fan, solar chimneys, many other passive climate control features and plenty of data cabling throughout the house. User interface access would also be via iPhone, which I carry in my pocket at all times, and mobile iPads.

The intention is to automate the house for climate control, lighting, theatre control, security, monitoring electricity usage, monitoring phone costs, controlling the hot water system, seeing who’s at the front door and letting them in (even if I'm not home), setting up a in-house phone/intercom system, limiting phone use, changing TV channels, looking at weather forecasts for activating systems in anticipation of tomorrow’s weather, remotely viewing the inside of the house, and plenty more. You could call it a life-long project!

I’d like to use LabVIEW for programming since it’s the most fun language I know. The only problem is that when it comes to easily programming a great user interface, I can’t find the way.

1) Data Dashboard for LabVIEW is too limiting with only 6 indicators and no controls (and needs work at the iPad end?)

2) Web UI builder is way too expensive (I need a free solution) and cumbersome

What’s also important is that different rooms can have different user interfaces. Perhaps each can reflect the front panel of a sub-VI.

There are plenty of examples on the web of great looking Home Automation iPad user interfaces. Apart form the example shown above, http://a2.mzstatic.com/us/r1000/089/Purple/v4/d9/23/ec/d923ec9c-0a31-6a62-cb7c-e74a4f8feecc/mzl.uayvvtoo.480x480-75.jpg looks good. Such great user interfaces and there is no way (or I don’t know how) to make them happen using LabVIEW.

This may not need to be a product development, per se, but may actually just turn out to be a step by step set of instructions on how to achieve the outcome using existing tools and an example application. Given what I imagine as a wide appeal for such a LabVIEW user interface, I think it’s worth the effort and could be used for many other application such as process control.

The basic criteria are:

1)    Must work with iPhone, iPad (and Android devices)

2)    All programming at the desktop (I don’t want to stand in front of multiple iPads setting them up/updating)

3)    User interfaces must look as good as the examples on the web (and sampled here)

4)    No additional cost

Wouldn’t it be great to have a LabVIEW based Home Automation user interface that is versatile, easy to use and free?

I posted this in the discussion forums here, but after forming my thoughts, I realize that it is really a suggestion for product improvement, so I'm cross posting here.

In short, I would like the ADCS toolkit to use Frame In/Out Queue Sessions instead of Frame In/Out Stream Sessions when running on XNET hardware (or at least make that an option).  This would enable the separate use of a Frame In Stream Session to log all of the CAN traffic on a port.

This was recently made possible for the ECU M&C toolkit in version 2.3, and I think the same concept should be extended to the ADCS toolkit.

A cursory test of ADCS 1.1.1 suggests that this may already be an undocumented feature of the toolkit, but there are some subtle bugs that may need to be worked out for this to be fully supported.