LabVIEW Idea Exchange

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

According to the increasing number of questions about this communication protocol, it would be time to rewrite the MODBUS library. I also suggest to add it to the NI device drivers installer.

 

This could be the place to list the expected modifications. Some comments and bugs are already listed in above linked page.

I am communicating to parker motor controllers through the Ethernet (parker sample code). Apparently since it is Ethernet based, the code uses socket, where the sockets require admin rights (another discussion about ethernet based and admin rights). In order for my VI to connect to the controller I need to run LabView as an administrator. The problem is I am making this program into an executable for production work.

 

When I create the executable it will not connect to the controller unless I am running the application as an administrator. As this program will be used in production I want it to be as simple as possible to perform. I don't think there is a simple way to change the environment to run without the need to run application as an admin. Are there any ideas to either change the executable to run as an administrator through the application builder? My plan is to create an installer through the application builder.

 

Some ideas that I had is to create an installer file and create the executable. Change the privilege level of the executable (properties>compatibility>privilege level>run this program as an administrator). Use a batch file to install drivers and application, then replace application with the one with the elevated privilege level. Another idea I had is use a batch file to do a runas command to run application as an admin. I cannot get either method to work. Does anyone have ideas?

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.

Estoy tratando de hacer una adquisición de datos mediante la placa Arduino mega, pero no se bien como deba hacerlos en labview, porque no debo usar el toolkit de arduino, si no tomar los datos de texto desde la placa arduino y convertirlos a número, y despues discriminar cada una de las señales, ya que estoy leyendo 6 de las entradas de Arduino, agradecería sus comentarios y ayuda, gracias

Module to further customize the remote panels generated by the tool "Web Publishing Tool". That is, because right now we can only customize a title, header and footer.

 

remote panel2.PNG

 

 

Would be very nice if we we could customize things further. This I thought, because many do not have the knowledge related to web design, but if you constantly use remote panels and would like to see the most pleasant pages. (For example, see a image, or a different color, so on). Something similar to what was done with the "Model Builder Robot simulation" of the "LabVIEW Robotics" that now allows create our own worlds and robots. But would focus on web design.  

a simple idea would be: 

panel2.PNG

As far as I can tell the SMTP Email VIs on the SMTP Email pallet do not support any sort of authentification.  Unless I am missing something this makes them close to useless.  It definately makes them usless to me.

 

I think there should be a login (and logout) VI where the login session is passed into the other VIs via a reference object.

Currently the Labview Database Tool Kit doesn't support returning or working with temp tables in a stored procedure.  This makes a SQL/Labview developer have to make complete hacks (such as returning tables in comma delimited form) to return results that take multiple table manipulations to generate.

 

See this thread for an example:

 

http://forums.ni.com/t5/LabVIEW/SQL-Query-Works-in-MS-SQL-Server-2008-but-not-when-using/m-p/2151492

 

The current implementation for remote debugging needs two ports to be opened on a stand-alone firewall in between.

  • Port 3580 to connect to the NI service locator on the target machine
  • A random port for the application on the target to connect to
    This port is dynamically assigned to the application by asking the OS for a free one

 

This dynamic port cannot be pre-configured on the stand-alone firewall except by opening up the whole port rang above 1024.

The latter is something no IT person with any sense of security will do !

 

So we need to be able to pre-configure a certain port for the target application, so that we can open a dedicated port for this connection on the firewall as well.

Otherwise this whole remote debugging feature is useless to us.

The current tcp/ip testing api is problematic for testing ethernet connections.  The behavior of the function set does not allow you to bind to an ip address unless the ethernet connection is active in windows.  This means that a unit under test must be powered before binding to the connection as a host.  Additionally, powering off the unit causes the host connection to be forced to completly cycle its startup (re-bind the listener and junk all the old connections, foricbly by polling because you cannot bind to the port when no connection is present.)  

 

This behavior can be achieved in C program, but cannot be called by labview in a dll because all dlls exist in the same thread.  Windows tcp function calls rely on the calling thread to determine the connection, which means if you need multiple connections it simply cannot work with dll calls.  

 

Suggestion:

 

Implement TCP/IP function calls so that a listner connection can be bound to an IP address that does require an active etherenet port and that is persistent across plugging/unplugging.

 

 

 

 

                  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

 


 


HTML5 supports WebSockets which allows low-latency, two-way communication between browser and server.  There are various screen-sharing technologies in existence based on this, but integrating a similar server in LabVIEW would enable capabilities that could be accessed from any desktop or mobile browser, no configuration required on the client side.  The key to this feature is the ability to configure the server and enable sharing from within LabVIEW or from a VI (i.e. a LabVIEW-aware server).

 

An idea of what this could do:

  • Remote control of LabVIEW development machine

remoteaccess_composite.png 

 

  • Selective sharing of windows, for instance allowing interaction with only LabVIEW windows.  The server application would have a mechanism for selecting which of the open windows to share.

app selection.png

  • A view-only mode so users could check the status of a running application from anywhere, including their cell phone.

 

remoteaccess_fo.png 

  • A brat or Express VI that when dropped in a VI would automatically share the VI when run.
  • Third-party toolkits and applications could build in sharing capability for their own app using the API.

 

This feature would be more powerful than Remote Panels in that:

  • It would give access to the LabVIEW development environment in addition to running applications.
  • No configuration or special software required on the client side, enabling multiple platforms including mobile.

Working in the telecoms industry at several different companies and for many products I need to be able to provide a test station with  DHCP functionalitly in order to be able to communicate with units under test. I have seen a posts on LAVA and the NI forurms that say I am not alone in this.

 

Currently I achieve this using third part products, typically with command line call using the system_exe. I mainly use tftpd, but it would be nice to have such functionality build into LabVIEW.

 

cheers

 

Dannyt

 

 

In reference to this knowledge base article:

http://digital.ni.com/public.nsf/allkb/A7DBA869C000B5AE862570B2007C4170

Along with my own personal experience trying to develop an RT program.

 

Choosing to force deployment as a zip file is incredibly obtuse and needlessly adds dead time to the development cycle. Now, when building a networked UI, if changes are required to the Real Time code, I must open, edit, build source, FTP, then run. Why can't I just build the Real-Time application and run it programmatically with a simple VI reference?

 

Alex

I am trying to send emails from labview for notifications, but I have troubles because email anti-spam protections.

It would be better if labview creates a email notification server where you can send a web query, something like:

http:ni.com.notification+javier@company.com+ALERT:temperature over maximum!

then the ni server would send an email to javier@company.com with text: "ALERT:temperature over maximum!"

Also the service could send SMS to javier mobile with same text.

 

The advantage is that it would work easily in any computer without change in email,antiviruses or antispam configuration

Hello,

 

when you use the URL property node for network streams you allways get localhost url only. 

NS URL.png

 

The Idea is simple. Just to change the information provided by this URL not for localhost but for the other endpoint of the connection. This would simplify managing multiple stream connections.

 

I would like to see a tool in which you can actively see outgoing SQL queries as they are generated by the program.

 

While attempting to troubleshoot one of my programs in which I was pulling and updating data from a database, I had no way to confirm that the queries I was sending out had the correct syntax.  The error message I was receiving indicated there was a syntax error, but it was a little difficult to confirm where the issue was, or if really was a syntax issue at all.  Being able to see a string of the actual query would help a lot for troubleshooting programs that generate queries dynamically.

Selecting the browse button of a path control of a VI under a real-time target brings up the file system of the host computer. This is completely useless and misleading. If you select any file or directory with this, it won't work when you run the VI.

 

I propose changing the behavior that selecting browse (on a path control) of a VI under a real-time target to show the file system of the remote target. I've seen X controls to do this before. In fact, Drivven has one. If not, I would at least remove the browse button.

It would be nice if we had the option to terminate a TCP Read on a single character rather than only a CR/LF. There are many times where you would terminate a read on some end character such as a 0x03 (ETX). In order to accomplish this now we need to have a tight loop which reads from the connection a single byte at a time. Even better would be if we could specify a string as the termination sequence. However, I would be happy with a single character option.

Extend the native LabVIEW queues to support network based queues. We have network streams which are very nice but they are point to point. Queues are extremely useful since they allow a many to one relationship. It would be nice if LabVIEW supported network queues. I have worked with a third party implementation which works reasonably well. However it would be nice if this was native functionality. Network queues are essential if you desire communication between different applications or for sending data from a TestStand environment to a LabVIEW front end GUI. They are quite powerful and would make it much easier for users to implement multi computer applications.

 

NOTE: I need to post an updated version of the Network Queue class. I have improved and extended this implementation.)

The import Web Service tool is very interesting and practical. However, many companies are using web services with authentication in xml script. This import tool doesn't work with the WSE3 protocol, from Microsoft, one of the authentication tools for soap services. I expect to see this implementation in the next version of LabVIEW.