LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

I would like to see the ability to select which network interface UDP writes are written to. Presently the UDP method in labview allows you to select interface for reads but writes automatically go out the "default interface" having a system consisting of a wired card, wireless card and a virtual interface is bringing about this need. I can manually turn off the virtual in the network control panel but there should be a way to just output to the device one wants to

I'd like to have a way to give the FPGA on my PCIe card direct access to a block of the host PC's RAM. At the moment, the FPGA is limited to its internal RAM and whatever might be on the PCIe card. With my PCIe-7841, I have about 1MB available to the FPGA. If I need more, I have to use DMA FIFO transfers - the FPGA can use one FIFO to ask the host for some data and the host can send it to the FPGA in another FIFO. This is a lot of overhead compared with simply using a memory method node to access the FPGA RAM.

So how about a method to allocate a block of memory in the host's RAM that the FPGA can access directly over the PCIe bus with minimal involvement by the host. For simplicity, it will probably need to be limited to a contiguous block so that there are no gaps in the addresses - the FPGA would only need to know the start address and the number of bytes in the block. Ideally safeguards should be established to ensure the FPGA doesn't access memory outside the allocated block, but leaving that to the LabVIEW programmer would be fine.

In short:

If the code tries to initialize and use port 10 as a serial port it should work without any issues as long as the hardware indeed supports this.

Background:

By default VISA will associate ASRL 10 with parallel ports and you have to manually modify the visaconf.ini file to be able to use it as a serial port instead. This is very cumbersome and not very intuitive for the users (if a serial port is installed and grabs port 10 (the fact that it can and will do this is alone a reason not to have the current behaviour) they do not understand why it does not work).

Serial ports are still quite common compared to parallel ports, if VISA has to dedicate an alias to parallel ports like this it makes more sense to choose a number less likely to conflict with serial ports - like COM99 or higher..

Currently the synchronous and asynchronous modes of writing data have little to no effect when communication over TCP. The write will return immediately after buffering the data to be written. However, the data it self may take considerable time to actually be written to the network. Absent some type of hand shaking at the application level there is no way for an application to wait until all the data has actually been written. The native LabVIEW TCP Write behaves in the same manner as the VISA write. Given this behavior it is impossible to implement a well behaved write queue for queuing up and transmitting data to a device. For example a normal print queue will open a connection and send the data to the printer. It will not attempt to open a second connection for the next print job until the first one has consumed all of the data. If a large amount of data is being written it can take time for all of it to be transmitted. The way the VISA or TCP write VIs behave the print queue would open a connection and write the data. However the call to the write would return immediately because the lower level network stack has accepted the data and buffered it. The print queue then believes the first job is complete and begins processing the second job. This will mean that a second connection will be opened. Some devices will allow multiple connections and some do not. However without the ability to actually wait for the data to be completely written the queue would have to continually try to open connections. This would be unnecessary network traffic and and unnecessary communication with the printer.

I would like to see an open on the write VIs to allow for a true blocking write. The write will not return until the data has truly been transmitted. The current behavior is also valid and can be retained.

Note: I have not tested the behavior on other types of interfaces so I am not sure if this is a TCP only issue.

View All (3)

View All (2)

I like using Linux whenever I can, particularly when running large software like LabVIEW, since it tends to crawl on my XP systems. I was happy to realize that LabVIEW works on Linux, but soon after I was disappointed by the lack of usefulness of it when interfacing with hardware. I need to use the RealTime module to interface with my RealTime Compact-RIO. I also need Linux support for the FPGA module, as I need to program the FPGA attached to my cRIO. I'm sure I am not the only person who would like the ability to do this.

Without support for any of the hardware or LabVIEW modules I need, the Linux version of LabVIEW is entirely useless to me, and XP as an OS simply cannot perform up to par for me.

View All (1)

Add mqtt client to LabVIEW

A common problem for usesrs is attaching additional input devices (eg. touch panels, keyboards, ...), to LV-based systems (including embedded controllers), but yet LV seems to miss an generic API/binding for that.

In Linux world (and BSD, too) we have standard APIs for that. On kernel side, there is evdev, which has lots of drivers for quite any kind of input devices you could buy (and easy to extent for new, even selfmade devices). In userland, there's an small wrapper library - libevdev - which encapsulates the platform/kernel specific stuff and is easily portable to other OS'es (eg. there's already a BSD port, Win32 and MacOS ports shouldn't be a big deal either).

This library could be directly called from a VI. This VI could also exist in several specific (and potentially highly optimized) versions, to Labview users have a generic API handling input devices (such as standard USB HID class) in LV.

View All (6)

Idea is quite simple - add to instrument drivers project wizard template for switch/MUX/matrix devices.

Custom switching boards are commonly used, b/c for some simple purposes it is cheaper to make custom design with simple functionality (some micro processor which controls relays), and which could communicate by serial line. Then instrument driver - is ideal solution to create simple API in LabVIEW for its control; but unfortunately, there is no template for such types of devices in New Instrument Driver project wizard.

Two recommendations:

1) Add an OSI Read VI for N wavelength spectra that returns each wavelength spectrum as a waveform (i.e. an N x number of channels array of waveforms). This will provide the time stamp of each wavelength spectrum, and will also be more efficient that reading one set of channel wavelength spectra at a time.

2) Add a VI that applies the wavelength scaling to wavelengths. This will allow the user to apply their own power spectrum peak search algorithm to wavelength spectra, whilst still applying the current wavelength scaling algorithm. This will free the user from having to use the OSI peak search algorithm.

We have found that the peak search algorithm utilised by NI-OSI performs poorly when the peaks in the power spectrum are poor quality, and that a much simpler algorithm yielded far better performance. Our algorithm was to simply report the maximum power wavelength in the sensor wavelength range if it was above a minimum threshold. This is in significant contrast to the NI-OSI algorithm that searches for peaks across the entire power spectrum using four algorithm tuning parameters, identifying all of the detected peaks that fall within the sensor wavelength range, and then reporting the one with maximum wavelength.

For reference, we have a PXIe-4844, and are using NI-OSI 16.0.

Multi-Board FPGA Generator

To generate a VI or set of VIs with a general driver to get low-end FPGA boards to work with LabView FPGA. Parameters will only come from the users to make this dynamic, this would be the total count of I/Os FPGA type, location of I/O items (eg. buttons) in the FPGA board, etc. It would be a bit of work, but also would pay off at the end. Doing such is no more than an extension of LabView if done well, let's say written in an xml file plus it would be a very powerful tool for researchers, and would generate more sales to use LabView FPGA for more researchers, university students, and engineers who want to test a few things without full initial commitment to NI tools.

View All (9)

Is it possible that the contents within the instr.lib to be defaulted to read-only every time LabVIEW launches? VIs that is drag-drop from the pallet onto block diagram is currently modifiable and may cause unintentional code modifications, especially due to the 'save all' function and hasty/improper shutdown. The extend of the damage may be inherited over time.

Also propose to default modified instr.lib VIs saves to be in active project folder instead of the instr.lib.

Hope to see these features in future versions.

In MAX if you create a virtual channel, you can select the channel and then go to the connection diagram tab to see a preview of how to hook up a sensor to a particular channel. It doesn't work for all hardware and channels but it seems to support more and more hardware with each release of DAQmx.

This is super useful for troubleshooting, and a great way to just see if something is hooked up right. Another use case I can see is to instead of selecting an existing virtual channel to preview, pick a DAQ card (by model) then have a listbox of physical channels. Selecting the physical channel can then change the image showing how to hook up to the input or output. Here is the existing diagram in MAX.

Basic Connection Diagram.png

Additionally this can be improved by being able to select multiple physical or virtual channels and see them at the same time, which can give a feel for what pins are being used, and what channels are available.

But what I REALLY want, is the ability to generate these images, for my own use programmatically. Either for documentation, or in the application. If a technician is troubleshooting a tester they could click on something in my application which shows the connection diagram, and opens a test panel. Or if I have a calibration routine I can show step by step instructions on how to calibrate the I/O with diagrams that are made on the fly for the I/O that they are calibrating. These might be for virtual channels, or tasks that aren't saved in MAX. I'd really envision an API where I give a piece of hardware by the model number, provide a terminal block if applicable, and then give a physical channel on that hardware and out would come the connection diagram image. It would be even better if I could provide an array of physical channels so one image could be generated which shows all the connections to that piece of hardware.

NI clearly put effort into making the user experience in MAX, and the DAQ assistant easy to use, please just allow us to make user experiences that are also easy to use for our users.

EDIT: Oh it seems that there is some support for multiple physical channels on one image, as shown by the document here.

I think that will be useful to have acces programmatically at Ni-Visa Driver Wizard

to search all connected device and to have as output a list with all connected device with PID and VID.

And if you whant to be possible to create a driver for a specific pheriferal from this list.

The VI "VISA Lock async.vi" should be reentrant to allow locking a connection while waiting for another connection.

Problem example:

Imagine COM1 is locked and for its lock is waited with "VISA Lock async.vi". While waiting, COM2 shold be locked (from somewhere else, with "VISA Lock async.vi"). Because the lock VI is not reentrant, this call is blocked until COM1 call finishes (because of success or failure). This is independent if COM2 is locked or not.

LV Versions with this behaviour: from at least 8.6 to 14

View All (1)

Logical shift in LabVIEW discards the shifted out bit. Logical shift functions in assembly labguage settings shift that value to an overflow bit register allowing the bit in question to be tested and program flow to be altered.

This kind of function is useful when dealing with low level protocols at the bit level, or dealing with digital devices that have a parallel interface.

I suggest the logical shift function have an additional output that contains the boolean value of the bit just shifted out of the number.

Logical shift should be able to output a single boolean, or an array of boolean. For the single case, the value would be the last bit shifted out with other bits being lost. For the array output, all bits would be captured with the first bit shifted out being the 0th index of the array.

LabVIEW Idea Exchange

Ability to select interface for UDP writes

Direct PC memory access by R-series PCIe FPGA

Make it easier to use port 10 as a serial port

Add the option to have a true blocking write for VISA

Need Labview plug n play drivers in OOP to realize the IVI dream

Linux Support for RealTime RIO Devices

Add mqtt client to LabVIEW

LV binding for Linux/Unix evdev API (eg. USB touch panels)

Instrument drivers: add template for switch/MUX device

Optical Measurement (NI-OSI) VI changes

Multi-Board FPGA Generator

niDCPower commit VI should change the range when output is in the off state

New additions in instr.lib folder to be defaulted to read-only

Create an API for the Connection Diagram

programmatically call NI-Visa Driver Wizard

"VISA Lock async.vi" should be reentrant

don't just discard the bit from a logical shift

Support JTAG on the 8452

labview with arduino

Allow Same Quick Drop Short Cuts...