LabVIEW Real-Time Idea Exchange

Top Authors

User

Kudos

Post an idea

I don't know really it is possible or not in analog domain but I am bit confident about this in digital domain.

I am facing this problem in my current work. Why not, we implement this as mentioned in the below picture in labview. If I am wrong with anything, please let me know.

I am just using labview from 2 months and I am not sure this is possible or not. I guess I can not use any filter here for separating exactly those peaks. May be in some systems, peaks shouldn't place always at the same frequency.

I hope you will understand after a look at picture. I just have taken that picture from my notebook. If it is not clear, I will try to give much clear picture.

LabVIEW provides an interactive front panel when running an RT application in the LabVIEW development environment. However, once you deploy this front panel is no longer available. I think it would be helpful to make the front panel look differently or somehow give a visual warning/indication that this is a debug feature and will not be available at deployment. (This could be something as simple as a watermark, similar to the evaluation watermark that LV employs). Many new users get confused and run into problems by using lots of front panel controls/indicators and then finding out later these are not applicable at deployment.

Android target option for TPM

I know there has been some discussion in other areas about an "Android build" of LabVIEW, but I am thinking specifically about the Touch Panel Module. An option to target and deploy an HMI onto a low-cost, readily available Android tablet would be tremendous for RT projects, in my opinion. I've got 2 different projects right now that require expensive Win7 tablet PCs, but all they are doing is running a custom LV application to be used as a basic HMI, which is complete overkill. I know the webserver is an option, but it has some limits, and I'd like to have multiple varieties of HMIs available to show varying degrees of system data and performance, which gets dicey with a webserver situation (at least, in my experiences so far).

It just seems like expanding the TPM so that it's keeping up with the times (Android and iOS dominance) seems like a win/win for NI and developers.

View All (3)

If you right-click on the RT target in the project and select Utilities you can:

-View in system manager

-View in browser

-etc...

It would be useful to have a View in FTP Client there as well. I seldom need to access the web interface, but I often want to delete files prior to a new deployment e.g. and this would be a quick way to do it.

Yes, you can use the web interface to access the files as well, but that's much more cumbersome than to just open an ftp connection.

If you try to select "Run As Startup" before having built the application you are stopped by LabVIEW with the phrase "The Real-Time application has not been built. You must build the application before deploying."

This is bad behaviour. Instead LabVIEW should silently do the requested task, including any prerequisite ones (the build), or at least offer me to grant it access to do so. The Run As Startup choice already includes the deployment option (no complaints from it if I have not done that yet), there is no reason why it could not do the build as well.

I've been attempting to perform a relatively simple homing routine on a motion axis where there are two limit switches (forward and reverse) and a home switch located somewhere in the middle. The homing routine starts by advancing forward and if it does not see a home switch, it will continue in the forward direction until the forward limit switch is activated. At this point, the routine will reverse the direction of motion and continue searching for a home switch until it would eventually see it (thus it is guaranteed that the home switch is found.) Once the home switch is activated, the routine performs a fine tuning procedure by slowly backing away from the home switch (in the forward direction again) until it is no longer active.

When using a c-series servo interface module, there is a Stop Mode property that one can set for each limit switch to either stop immediately, decelerate or disable the drive (See fig. Axis Properties and Limit Stop Mode ). When the stop mode is set to Disable drive, the homing routine fails upon triggering a limit.

There are property nodes available to read the stop mode however the nodes are read only. (see fig. PropertyNode)

It would be nice to have the ability to programatically change the stop mode depending on the motion being performed. Our application requires that the drives be disabled upon activation of any limit switch under regular motion. However, during a homing routine since the disable drive stop mode impedes the routine, it would be benefitial to be able to change the stop mode to decelerate for the duration of the homing routine, and then change it back to disable drive once homing is complete.

Convert RT front panel into host VI

Sometimes, you really just want a RT front panel. Of course, there is no real front panel, but when you run in interactive mode Labview is automatically setting up network communication to pull data from the RT target and push data to the RT target. Wouldn't it be great if you could just convert that whole front panel into a basic host VI? Right now, you have to manually convert all controls and indicators to shared variables. Granted, this does force you to be very careful about limiting the number of network-shared items that you have, but sometimes you really just want to run the VI in interactive mode...but deployed.

Or, better than that, convert everything into a web service and automatically build a silverlight UI (using Web UI Builder) which is hosted on the cRIO. Anything that provides you with a quick and easy way to convert from the rt debugging UI to a basic host VI would be great.

I have been recently tasked with porting a Windows DLL to Phar Lap. So, code is not my own, there's a lot of it, and the DLL is crashing with stack overflows. Recursion is not a problem here, so it's obvously a local variable space. The default thread stack size is 128k, which is a bit on the low side. An ini setting that would allow to increase this would be most welcome. Especially if you're not getting errors in your own thread, but in the LabVIEW ones.

On all of the RT platforms, if the CPU maxes out at 100% the RTOS goes through a sort of "load shedding" and begins suspending non critical threads to lower the CPU overhead and hopefully maintain determinism. One of the first threads that gets suspended is the TCP thread which essentially cuts off the RT target from the ethernet and outside world.

While I understand the concept of the load shedding, I believe that if you have the CPU pushed that hard, then your determinism is out the window anyway. Dropping the TCP thread only serves to disconnect the RT system from the development environment or the built application with no real benefit. I have yet to see a single application that was actually able to accomplish anything substantial after the point that the TCP thread was suspended. In most cases, the high CPU usage happens during the development of the application or when something is critically wrong with the setup of the deployed app. In those cases, it wouldn't matter how many threads you suspended, the CPU will still be maxed out.

It is akin to blowing out a match in the midst of a forrest fire.

I would propose that the RTOS be reconfigured to show the TCP thread as one of the critical threads and keep it from being suspended during high CPU excursions OR give the developer the option to turn this feature on or off throgh the device properties.

Debug reentrant VI in LV RT

I really miss the ability to debug reentrant VIs in LabVIEW real-time. Currently there is no way at all, short of indirect probing by programming your own debug functionality (logging of some sort).

I understand there are inherent difficulties in this, since LV RT systems are typically headless, and definitely GUI-less (except for maybe www-access).

But, maybe if we had a way to send a BD reference to a Host PC, the block diagram could be opened there? Something like an Open.BD method with a "destination" input on it? Then the reentrant VI could open its own BD on another LabVIEW instance running Desktop LV.

View All (4)

Hello,

it would be very nice if i could give users in the Web-based configuration more specialized filesystems rights.

In the moment i only can give the user the right to write on the whole filesystem or on nothing.

In my case i would like to sent our customers updates of the startup.exe, which they can install their self via ftp. Without them having access to everything on the filesystem.

Please vote if you would like to have this option,

Westgate

View All (3)

When developing RT code (especially system upgrades) it would be truly helpful to have a virtual machine (VMware, MS Virtual PC, Sun Virtual box, etc....) that would allow us to run the actual VxWorks OS and LVRT in it's native environment, within the Windows OS. This would allow the code to run on the actual RTOS (I realize that determinism would be scacrificed) and provide the ability to actually test the functionality of the code in the actual environment to ensure that it runs as it should. It would also preclude the need to have a bunch of RT controllers sitting on the shelf in the event that you might need them.

There is and emulator for PDA module, why not for RT.

It should be nice to add a new "Build specification" in Labview RT which could generated something like a RT Target installer.

This installer could contain ...

The application to download
The drivers required
Additionnal custom files and directories
The default setting of the target ( Like the MAX target configuration)

When the installer is executed, it should be nice to show all the available targets ( Like in Max ).

The user should have to select the destination Target in this list.

Then it should be nice to show the target configuration (like in Max), initialized with the setting contained in the installer.

An installation could be like this ...

Launching the installer
The installer lists all available (and compatible) targets
The user has to choose a target
After target selection, the installer should view the target configuration ( as defined in the Labview project Build specification properties )
The user could then modify some parameters (like IP address)
After validating the configuration, the installer should
Install the drivers ... and perhaps the OS itself (as required by the project)
Modify the target parameters
Install the application
Set Time/hour according to host target
Download custom files and directories ..
...
And restart the target

This feature could be an easy way to deploy RT application without having a Labview RT installed on the host computer.

A RT application could be installed completely by a final customer of the application, without having to install the Target, drivers ...

This could also be nice to clone many times a RT application.

LabVIEW Real-Time Idea Exchange

Related to Signal process special VI.

Warning or different look/feel for RT front panel

Shared variable export to .csv should work with virtual folders

Android target option for TPM

Connect to FTP server option under Utilities

Make it possible to select "Run as Startup" without having to build the app first.

Have the ability to set the stop mode for a limit switch from within LabView for NiSoftmotion

Convert RT front panel into host VI

Add ni-rt.ini setting for thread stack space

Don't suspend the TCP thread when RT gets busy

Debug reentrant VI in LV RT

Filesystem Rights in Web-based configuration and monitoring

Add ability to change text color on the RT Debug String VI

Don't force a "Save All" prior to RT Deployment

Start including the Ethercat industrial communication drivers in the device driver DVD.

Provide a Virtual Machine (VM) in which to run LV RT systems on

Add a version number to RT EXE files

Complete installer for Labview RT Targets ...

Allow the deploy libraries method to work in RT OS

Native XML support on Real-Time targets