LabVIEW Idea Exchange

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

The Labview Web Services should support digest access authentication (RFC 2617) in stead of NI's own inventions NI Auth and NI API Key (the latter is broken in 10.0f2). Digest access authentication is becoming a standard and is intended to replace basic access authentication since it doesn't send passwords in plain text over the web. It is very useful for cases where HTTPS cannot be used, for example for performance or legal reasons.

 

Digest access authentication does not require Silverlight at the client side like NI Auth does - it requires only a recent browser. In this way the choice of HTTP clients is much less restricted and for example a cell phone can be used too.

 

It shouldn't be that difficult for NI to get this done, the webserver behind it already supports it. Of course the Labview HTTP Client should also support digest authentication.

Dear all,

 

timeouts and UID properties of "Modbus Master.lvclass" and "Modbus Slave.lvclass" can currently be set but not read out (they should).

 

See discussion here.

 

Sincerely,

Hello all, 

 

I have a suggestion about Automotive Diagnostic Command Set. It is currently designed for CAN-based diagnostics only and diagnostics on serial lines (K-line and L-line) are not in the scope of the Automotive Diagnostic Command Set.

 

I would like the Automotive Diagnostic Command Set to support diagnostics on serial lines (K-line and L-line) too. 


Automotive Diagnostic Command Set User Manual
http://www.ni.com/pdf/manuals/372139a.pdf

 

Best regards

Rutsu Kenmoku 

It would be nice to see a string terminal added to the TCP/IP function so that you could choose which character set you would like the TCP/IP read to look for before ending its read.  Then instead of having the CRLF mode it would be called Character Search or something that would appropriately fit.  I have run into this being an issue when I have used a serial to TCP/IP converter because not all serial equipment sends a CRLF character such as Alicat Scientific Flow Meters and Controllers.  This came about because the converter does not buffer the data once a TCP/IP command is sent making it hard to build a loop that builds up a string of data one character at a time by setting the read byte count to one then looking for the control character and ending the loop when it is found.  This is because once a single byte read command is issued the device releases it's entire buffer and every thing after the first byte of data is lost.  Perhaps I have overlooked something. If I have please do not hesitate to let me know.

Currently, the only way to add a webservice to a project, is by right clicking a Target and selecting New->Web Service.

There's no way to add existing Web Service definitions to a project, other than manually performing the copy operation at the XML file level.

This prevents proper re-use of IP!

 

Webservice in project.png

 

I would propose extending the capabilities of a Library to also support Web Service definitions as Child objects.

That way, the library can act as a container for the Web Service definition, and can easily be reused in other projects:

 

Webservice in library.png

I tried using an XML editor to manually put a Web Service definition underneath a Library, LabVIEW didn't like that!

Not just via Datasocket. All of them, property nodes, programmatic creation, controls bound to, etc.

Selection_002.png

Screenshot from 2017-12-11 16_52_41.png

Is there some intrinsic reason why SVE is possible only on Windows, like (I read) is said for OPC?

Possible scenarios:

 

A) You right-click in your project and instead of adding a new target e.g...you can add a data source. This data source could be a web service, an XML file (eithe local or at a http address...), an ODBC database, a modbus TCP/IP register etc. etc. You can now access the data from this by dragging the source icon in the projects list onto your block diagram. This would give you a reference and polymorph accessor VIs.

 

B) You drop a data source express VI onto the diagram and it pops up with a dialog that allows you to select the type of source.

 

C) Perhaps we could even integrate this even more; if I right click on a table e.g. I can choose to link it to a data source - and have a wide variety of sources to choose from. Yes, we already have the shared variable or data socket based data binding option, but we should be able to bind it to lots of different, open and industry standard sources.

 

Mads

LabView has supported SSL secure communications for the web server for some time now.

But, there is no support for using SSL to a data socket.

 

In these times, with the NSA and hackers snooping everywhere, it seems like a necessity.

 

There is a third party library "SSL Library" on the NI site.  It has no documentation.  It uses Microsoft .NET calls to do SSL, but it is not clear how to make it work.

 

We have been using a proxy written in perl to get SSL to a LV data socket.  It is a kludge solution.

 

Why can't LabView handle this?

 

Mike

 

Please make the LabVIEW Web Server more efficient! I love the idea of the LabVIEW Web Server as it allows me to create powerful, dynamic web pages for my clients. However, I recently published my VI using the "Embedded" option of the LabVIEW Web Server and found that this uses 3 Mbps per instance. An NI support tech was kind enough to point me to the following article: http://www.ni.com/white-paper/3277/en. This article confirmed my fears: the LabVIEW Web Server is transmitting all of the data for each object (even the invisible ones) at the 10Hz update rate of my application.

 

For this reason, I've decided to use Windows RemoteApps (using the Windows Remote Desktop engine) to publish my VI. In doing so, my network bandwidth is reduced from 3 Mbps to 10 Kbps with zero loss of functionality. However, RemoteApps are a pain to set up and aren't nearly as nice to the end user as a web published LabVIEW front panel. I would like to suggest that you all look at the algorithm behind Windows Remote Desktop and use something similar for the LabVIEW Web Server. In my understanding, Remote Desktop simply sends CHANGED pixels from server to client, and sends mouse and key clicks from client to server. Why would you need anything else?

Can we please have some official examples for the HTTP Client VIs under Data Communication > Protocols?  There are currently none available.  Thanks.

LabView has email capability but if you do not have a mail (POP or Exchange) server on your network, or like in my case use of the company exchange server is restricted to users with logins, but automated test machines and ATE system users are not granted logins, you can not send email using the LabView vi's.

 

Sure it can be done by getting a G-mail account and using the POP servers on G-mail through active-X but that is a lot of hoops to jump through just to send an email, and who knows how long G-mail is going to allow use of the POP servers.

 

It would be a lot simpler if LabView had a basic POP server vi that could directly send email with settable outgoing port just in case port 110 is blocked for some reason.

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 !

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.

Currently the native (by which I mean noncustom) numeric data types for shared variables are pure numbers (i.e., without units).  It is simple enough to add units to, say, a DBL numeric control and define this as a custom type, but the DSC module does not support value-based alarming for custom types.

 

Since

1) we would like to support value-based alarming AND units

and

2) I suggest this is (or should be) a very common use case

I propose that LabVIEW have numeric types with units as native shared variable data types.

 

I suggest that using units for engineering applications would be both more convenient and safer

 

I also think this would be quite simple to implementThe only question is on which unit to do the value-based alarming.  (Likely this would be on the SI unit on the wire.)

 

I have attached a very simple example that shows the current state of things.

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.

 

 

                  I would like to be able to program the XNodes.

 


                                  img_1-557_smile_triste.png

 

 

          Include the programming of Xnodes in labview features

 

                               ... for the next Christmas   clin d'oeil _ 1.gif


 

                                         noel_1.gif

 


 


This would be useful for variables whose value is not yet available at deployment time, and is filled later by some process.

 

Currently (LV2017.1f3), it is not even possible to input a non-numeric value in the inital value page in the variable editor. Attempting to do it programmatically like this:

LabVIEW_2018-11-18_12-48-49.png

produces a LabVIEW:  (Hex 0x8BBB0018) Invalid float value.

Whereas, blindly editing the lvlib file to 

 

<Property Name="Initial Value:Value" Type="Str">NaN</Property>

produces a "deployment failed (error: -1950678996, LabVIEW:  The variable configuration is invalid.  Edit the variable properties to correct the configuration.)." at deploy time.

 

Currently the "Bytes at port" property only applies to serial ports. If you are trying to write a generic driver or communications package that supports multiple connection types you cannot use the "bytes at port" since it will not work for anything but a serial connection. There is a related idea here which proposes the "Bytes at port" can be added to the event structure. It also suggests that this be expanded to other connection types. My idea suggests that at a minimum the VISA property node can be expanded.

'Database Variant To Data' cannot be placed in an inline enabled VI making it impossible to use in malleable VIs. 

It would be nice to be able to draw on the power of the 'Database Variant To Data' VI in malleable VIs so we could be more flexible when writing database related code.

 

Please make this possible or offer a workaround (like the polymorphic instances of the VI).

This is a bit esoteric but for those who use the DSC toolkit to read trace data from a Citadel DB you will find that you cannot always obtain the most current value

of a trace.  Here is the text describing what a ghost point is:

 

Citadel uses ghost points to maintain real-time awareness of traces that do not change frequently.

For example, suppose you configure a thermocouple measurement for logging with a deadband of 1°F. The thermocouple is in an environment that remains at a constant temperature most of the time, but you need to know when any major changes occur. If the temperature remains within 1°F for one hour, Citadel does not log redundant points, even if the temperature is sampled once every five seconds. However, if the logging system experiences a failure at some point during the sampling, you want to know the temperature at the time of the system failure. You also want to know the approximate time of the failure. Citadel handles this situation by logging a single ghost point for each trace. The ghost point in each trace updates constantly at a rate based on the time group specified for the trace. The ghost point always reflects the most recent time and value of a trace.

Citadel stores ghost points in a .tgpffile that updates once every ten seconds. This file ensures that Citadel has an accurate record of the value for every trace at the time of a system failure.

 

It would be very useful to be able to specify in the trace read vi that you would like it to return the ghost data points.  Otherwise, it is very cumbersome to try to detect if you are missing this data point and then have to programmatically read it yourself from the originating data system.