LabVIEW Idea Exchange

If we can have instrument simulator VIs, we can test our codes prior to the actual hardware acquisition

The idea proposes device driver packages from IDNet to include a vendor instrument simulator VI that can be run prior to code testing. The VI can be configurable (VISA based on virtual ports created during runtime, file paths to read from to simulate measurements and responses to messages, etc) and started asynchronously (call & forget) at the start of the program and terminates when the caller terminates.

or as a template from the "New > Simulated Instrument" where user can modify according to the instrument that they are going to use.

...and that it covers NI and 3rd party instruments

See Also

Simulated Devices in TestStand Workspaces

Project and Workspace Context in MAX

Link to those ideas in next post

We can already create tasks, channels and scales in a LabVIEW project but, We cannot then use MAX to run those Tasks and we must use MAX to create a simulated device on a development machine. After a few projects the Max configuration becomes cluttered. Deployment and importing of the hardware configuration can get problematic to say the least!

On the other hand- if the Hardware, Data neighborhood and IVI session set-ups could be added to the project deployment would be a snap! just import the *.nce from the project without having to create one from MAX and exclude items not concerned for the project we are installing.

For integration and station troubleshooting the Sessions, Aliases, Tasks et al would be organized by application or project in MAX and fault identification has all the "tools" any repair tech could want to isolate a failure.

For ethernet and GPIB communication I have the choice between the LabVIEW "native" drivers (residing in function palettes "Instrument I/O" and "Data Communication") and VISA. LabVIEW 6.1 was the latest version which also supports "native" drivers for serial interface. In LabVIEW 7.0 and later you are forced to use VISA.

Besides all advantages of VISA - the biggest disadvantage of it is its HUGE communication overhead it produces. If you use interface sniffer like PortMon, you will see that VISA heavily communicates with the interface chip (requesting its status etc.). So for sending a simple "Hello" over RS232 you don't have only four actions (configure port, open port, sending "Hello", close port), but ten and more.

As consequence VISA often lockes out if you have heavy traffic on your serial interface (e.g. if you have to send data every 250ms over the interface) - and if VISA lockes out, you have a serious problem...

So PLEASE, give us the native driver for serial interfaces back!

We have quite a few LabVIEW users here, but not many of us have the application builder or the experience to use it. So I get many requests to build an executable and installer for others. Each time I have to take their DaqMX tasks (in the form of a *.nce file from their machine), import it into my MAX and then when creating the installer essentially re-create the same file. Can an option be added to the Hardware Configuration tab to allow you to select a NCE file instead of create one?

Thanks,

-Brian

I know this is another Raspberry Pi idea, but hopefully the answer is simpler than some of the past requests (maybe as simple as "no"). I am wondering if it would be possible to run a simple labVIEW executable on a Raspberry Pi with the sole purpose of viewing network published shared variables. This could provide a low cost UI terminal for distributed hardware. My hope is that the required drivers are minimal in that only a network connection is required and no hardware drivers for the NI products would be required. Basically, it would be similar to the data dash board app but would allow much more customization by the developer for software based analysis and display.

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:

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.
Expression nodes and multi-digit constants – no word-wrap available here either.
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.
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.
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.

View All (3)

It would be great to determine properties of a disk drive i.e. type and size. There have been a number of my applications that would benefit from knowing the difference between a local drive and a network drive. Drive Types are shown below.

It is simple in LabVIEW to get a list of disk drives on a given computer as shown:

There are round about ways to get drive information such as command prompt and the system exec.vi and registry vi’s. These methods require a lot of overhead and programming. There is currently no simple function in LabVIEW that I can find that will return the properties of a disk drive.

This idea is more of a request for National Instruments to include a new VI that will get Properties of a Disk Drive. This new VI should be similar to the existing Get File Info VIs.

The current VISA read and write primatives do not have the ability to abort early. Under many circumstances if the timeout values are short this is not an issue but it can be an issue if a long timeout is required. The current work around is to use a short timeout value and loop continually ignoring the individual timeouts until a threshold has passed and then pass the timeout error out. This apporach requires the extra code to "monitor" the process of the communication. It also requires shift registers and associated logic to maintain the data. It would be desireable to simply set the timeout for the desired value and have a separate VISA property that can be set cause the current operation to abort.

View All (4)

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

View All (2)

View All (3)

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?

View All (1)

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.

Data Dashboard for LabVIEW (https://decibel.ni.com/content/docs/DOC-19387 ) is an exciting and interesting product. I like the idea of using my iPad or iPhone to interface to my LabVIEW application remotely. Of course, the Android platform is also catered for. It’s early days for Data Dashboard, but it is currently very limiting with just 6 indicators for tablet devices and 1 indicator for phone devices and no controls. So, Data Dashboard has a long way to go. The images presented here is the capability I’d like to see from Data Dashboard for LabVIEW.

Wouldn’t it be great to have a remote LabVIEW user interface that looks like the images here?

View All (2)

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

LabVIEW Idea Exchange

TCP/IP, UDP/IP Get connection information function

Implement More than 14 User Ideas in the Next Version of Labview

Instrument simulator VIs

Simulated Devices in LabVIEW projects

Native drivers for serial interface (RS232 etc.)

Include the capability to choose a *.nce file when creating an installer instead of having to re-create it.

Add Windows/Linux/OSX PC Target in a project

Develop software to allow porting of LabVIEW executables to Raspberry Pi to enable reading and graphical display of Network Published Shared Variables

Block Diagram Cleanup Tool Should Better Manage Horizontal Expansion

Properties of a Disk Drive

Add an "Abort" event to VISA reads and writes

Proper Smith Chart

Bulk binding Variables to OPC Client

Byte at port or Data available for TCP/IP VIs library ...

LabVIEW Home Automation User Interface

Use Frame Sessions for Automotive Diagnostic Command Set (ADCS) on XNET hardware

Data Dashboard Direction

Improvements to the "NI Update Service" (shut down the system, when you finish the download.)

LV/PDE for Windows 10 IoT Enterprise targets

Card specific DAQmx/LabVIEW Property Nodes