LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

According to this document only 14 ideas from the idea exchange were implemented in LabView 2010.This is a fantastic start.

 

There are at least 100 more great ideas on the Idea Exchange that should be implemented in the next version of LabView. Keep listening to the users. Keep improving LabView in every way.

 

Smiley Happy

If I "create constant" from a path input, and start typing into the path, the control grows to the left, away from the function that accepts it as an input.

 

But for VISA and IVI, the name controls grow to the right as you type into them, covering up the icon of the function that accepts the input, along with the wire connecting them.  Let's make VISA and IVI behave better.

 

23852i492819D58059CA42

I think it would be extremely useful to add the possibility to have as a target in a project a Windows PC target.

This would help keeping well organized applications running on more than one PC, and would make debugging easier.

 

23126iBEF6B464E54D2588

The Vision Acquisition Software seems to send all GigE attributes to the camera that have been set in the camera file. There should be an option to select which attributes are sent to the camera when connecting. This would allow the settings configured through vendor specific third party tools to persist when acquiring in MAX or LabVIEW.

 

This could possibly also alleviate the "Attribute value is out of range" error if MAX is only sending the attributes you specify.

Currently LabVIEW only has support for Mandriva, RedHat and SUSE Linux.  What's even worse, only 32-bit versions of those are supported.  Today, 64-bit linux installations are on huge raise, and Ubuntu is getting more and more popular.  LabVIEW Linux support should be expanded to include Ubuntu, and 64-bit versions are needed.

 

cheers,

Pekko

 

TCP/IP, UDP/IP, IrDA
LabVIEW doesn’t have any VI or function to retrieve connection information/properties like IP address, local port or service name, remote port, ect.
In order to get connection information, you have to make a functional global vi to manage connection information by connection ID for later to retrieve.

Native function or VI will be great help.

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.

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.

Would like to target Labview embedded on a host of platforms. Specifically x86, lynuxworks, Vxworks and xilinx platforms - boards, SBCs, COMs, stacks, PC/104... Like PXI, the way to get the users onboard is to show that the industry supports this direction and you are not tied to one vendor. It would be expensive if in an iterative learning process (necessary but collaboration is also necessary with well established & matured platforms/standards) the users one chosen platform vanishes (maybe like fieldpoint?). Packaging options is also very important to achieve something like Adlink's MilSystem 800 that the application demands.

 

Pavan Bathla

Currently VISA only has a single timeout value and there are use cases where a different read and write timeout is required. Today you need to constantly modify the timeout between each read and write. It would be prefered if these timeouts could be set independently.

Traditional IVI drivers haven't worked. The industry has been waiting for this for too long.

 

Best regards, Pavan

Hello,

 

I work as a LabVIEW integrator and for one of my customer I develop application, with maintenance goal for their installation all over the world with RS232 or Bluetooth communication for example, deployed on targets as PDA (PocketPC 2003 & Windows Mobile 6) or Touch Panel (Windows CE 4.2 to 5.0) using LabVIEW 8.6 Mobile Module.

This LabVIEW additonal module works quite well to deploy the same application in this differant targets, but I encountered some problems and I have some suggestions for Mobile Module :

 

1/ MMI (Man Machine Interface)

      -  for graphics indicators (as Gauge or Slide) graphical object ramp or multi Slider is deleted by LabVIEW when you build an EXE => I think that a graphical objets with all its graphical property could be added in Mobile Module (and works on these all targets). See examples in GraphicalObjects.PNG

      - as I say in my introduction my application is deployed all over the world and usually I used "Caption" dynamic modification for multilingual management for all my controls & indicators. But in mobile module we can't do this (but we can modify dynamically boolean text), so I think that it could be possible.

 

2/ VISA (& Bluetooth) Management

      -  I think there is a bug with VISA installation. Indeed with the installer you can choose the installation directory (default directory or specific directory : in non volatil memory) but if you don't install VISA support in default directory it doesn't work (with PocketPC 2003 for example) I think that could be resolved

-  As I said in introduction my application could communicate throught different protocols (RS232, Bluetooth) and with LV 8.6 Mobile Module we can now use VISA : great !!!. But in Windows Mobile 6, VISA does not support bluetooth (it seems to have an incompatibility with virtual aliases in the registry) ; and in PocketPC2003 it works very well. I think that could be resolved

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.