LabVIEW Idea Exchange

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

For accessing Linux in our products we will have an on-going need for Telnet.  The Internet toolkit is no longer supported, and though we can keep bringing the latest one (2012) along, it doesn't seem wise to build on an old toolkit.  It would be great if Telnet and SSH were native to LabView in the future. 

I would like to suggest that NI add some needed functionality to the FTP VI's that it ships with. As  you can see in this thread: http://forums.ni.com/t5/LabVIEW/Access-FTP-with-whitespaces-in-dir-names/m-p/3097215#M886371  the FTP LIST command does not work well for some FTP servers when the directory being listed has spaces in its name. The FTP MLSD command does work in this case, but there are other servers which don't support MLSD. My post on the above thread implements a fairly crude mechanism for using whichever command does work. But more importantly, the MLSD isn't even included in the NI FTP library. It would be great if the NI FTP VIs worked over a broader range of FTP servers.

Several users of XNET miss an important function from the driver: to read signals' logical value from the database.

For example, the value of 1 means 'Initialized', 0 means 'not initialized'. We would like to read those strings.

 

See this thread.

Standard IEC 61850 Allows INT64 this is not support by NI-Industrial Communications for IEC 61850.

Add support for INT64.

It would be really nice if the Flatten to JSON supported more LV data types.  In particular, I find it very annoying that it doesn't support flattening a waveform to JSON since those are very common in most of the measurement APIs.  

 

In the mean time, I have come up with this little work around, but it really seems like this is something that should be natively supported.

 

Waveform to JSON.png

 

JSON to Waveform.png

Allow the network address to be specified when performing TCP and UDP writes in LabVIEW. 

 

For example, universal plug and play uses multicast messages for discovery. However, the multicast vi only transmits on the default network address. This makes multicast discovery impossible when I have multiple UPnP devices on multiple networks (I have multiple network interface cards and additionally use a VPN that acts as a virtual network adapter).

In the Simple Messaging Reference library, the STM Get Connection VI always requires an index to establish a desired connection. However, this mechanism does not lend itself well if the program needs to add/delete connections on-the-fly. Specifically, it takes some work to determine the next correct index. As a work around, the user can use a property node and set a connection "Name" to search on. What I would like to see is a name/index polymorphic input instead, as well as a disitnct VI to 'Get Properties'.  This would enable the program to retrieve properties necessary for the Get Connection VI to be used on-the-fly without explicit knowledge of the name/index.

Today I discovered NI has discontinued support for NI-CAN hardware (not XNET) beyond LabVIEW 2015SP1.   If you want to use your code with NI-CAN hardware and LabVIEW 2016 and beyond, you are out of luck unless you have the cash to buy XNET replacements and want to rewrite your code for the XNET API.

 

I have a very large J1939 simulation/monitor application I wrote and have supported for the past 8 years that is used on several lab benches and by numerous software developers across the country.  Now, we stuck with LV2015SP1 forever unless we can find a large amount of cash to replace all the NI-CAN hardware, which isn't going to happen anytime soon.

 

So, my idea is for NI to keep supporting NI-CAN in current and future versions of LabVIEW

LabVIEW needs native SSL/TLS support for the TCP primitives. The HTTP functions support it (see \vi.lib\httpClient\ConfigSSL.vi). There are several great LabVIEW native MQTT libraries that could be commercially usable if there was native SSL/TLS support. Not having this functionality for the TCP primitives makes LabVIEW a poor choice for an IoT platform.

I have 208 data producing test stations, located in 10 different labs in 4 different countries.

I need an easy way to copy or move the files from the test stations, to a lab data computer, to a “web service” to a master global data base in the US.

Within each test lab I am thinking a network shared drive.

However, getting the files from China, Taiwan and Germany to the US automatically is challenging.

I am thinking that a web service like “amazon web services” would work.  But setting it up and programming it into LabVIEW is more challenging than it should be. 

It would be really nice if Nation Instruments would create a simple easy solution to do this.

This idea directly comes from this issue : http://forums.ni.com/t5/LabVIEW/Issue-when-using-SOAP-requests-with-HTTP-POST-function/td-p/3169229

 

More and more devices are equipped with embedded webservers. And some of them require more controls HTTP protocol capabilities.

It would be nice to give the access to these VIs diagrams or to give more options set header fields !

I think there should be a way to have a network stream endpoint creator continuously wait for a connection. The problem with that is there's no good way to stop that "wait forever". I propose we create the network stream in two parts. The first one just creates a handle that can be closed later. The second one does the actual waiting like the normal create endpoint.

 

Network streams.png

 

Closing an HTTP handle should stop HTTP functions (GET/POST/etc)

 

HTTP abort.PNG

For example, in the above code, if the GET is taking a long time, the user might not want to keep waiting and hit the close button. The above code should skip the remaing wait and cleanly cleanup any refrences as needed.

Hello,

 

I like to suggest ECU Measurement And Calibration Toolkit to support XCP on FlexRay. FlexRay become available in more and more products, and XCP support it would increase the usability of XNET HW.

 

Best regards

Mario Krömer

Hello,

 

since FlexRay is rising in more and more products, a FlexRay support is needed. I suggest to extend the Automotive Diagnostic Command Set to support UDS on FlexRay, too.

 

Best regards

Mario Krömer

Hello,

 

I like to suggest adding a possability to show the text definition of signal values inside the XNET database editor, (e.g 2 => 'moving'). Right now I need to open another tool to check the meaning of a value that is already describt inside the opened dbc.

Hi there,

 

in my opinion the XNET database editor is nice to handle database carrying some 10th of signals, but not some 100th to 1000 if a specific property is used.

 

- Implement a list view of all signals with its details, so that signals could be sorted by their properties, e.g. static or event type.

- Highlight FlexRay coldstart frames and nodes icons in tree view

 

 

 

 

There are database out there that define signals with 64 bit length. And avoiding the need to use them as RAW frames would ease up the handling.

Hello,

I suggest to handle CRC calculation of frames by XNET HW (similar to other thread in this foram that suggest handling message counter on CAN).

 

In every project there are frames that needs a CRC over whole frame content, e.g. for CAN:

<Data1> <Data2> <Data3> <Data4> <Data5> <Data6> <MessageCounter> <CRC from Data1 to MessagCounter>

 

Currently, all is handled by CPU which results in dependence to CPU and OS. Actually, complete frame raw data must be build in PC to calculate CRC (even if symbolic signal names are used).

 With multipe CAN busses in parallel use and different repetition rates of CAN frames, timing may become critically.

 

It would be great if it would be possible to configure CRC-8 calculation for frames. Since the calculation has some parameters that are different from customer to customer, a perfect solution would be a formula node, that could be shifted to XNET board and liked to multiple frames with parameters:

 

- frame name

- CRC protection start byte

- CRC protection stop byte

- CRC byte position or signal name

 

 

We have cloud computing, virtual Machines, CPU virtualization etc. - There are numerous ways of achieving parallel and distributed computing, available at different architectural levels. The inherent parallel nature of the LabVIEW graphical programming means we can often achieve parallel computing without thinking.  

 

-But in cases where the programmer actually needs to make a decision we now have the Loop Iteration Parallelism option.
If an action is to repeated multiple times and the execution of each run takes longer than the overhead of communicating the input data, execution code and/or output data across to multiple targets, parallelization can reduce the total execution time, and/or reduce the load on each target. Now, in some cases the execution time can justify parallelization even across slow communication channels. 


What if we expanded the user-friendly loop iteration parallelization mechanism to also support remote processors?

 

  • On the targets we want to offer as execution hosts we will need to install a host service. This service might offer us the choice of offering all, or just a subset of the available cores.  Perhaps even decide this based on the current load on the target, or time of day(!). The targets can be of different platforms as long as the code is possible to recompile for it.

 

So how would this look like to the programmer? Well, we simply extend the for loop parallelization function dialog to something like this:

 

For Loop Iteration Parallelism Across Targets.png

 

  • The loops should also allow this setup to be changed at run-time. You could have a general VI to define the default targets and establish a link to them, and each for loop could have input terminals to specify the parallelism options to be used at the time of execution.

  • Another fun consequence of this functionality would be that you can really distribute *any* part of you code across multiple targets simply by wrapping it in a 1-iteration only loop.

 

With this functionality in place getting 10 machines to work on a heavy problem instead of just one would really be as simple as drawing a for loop...Smiley Very Happy