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.
I'd like to see NI develop a bullet proof way of communicating with a cRIO over TCP/IP to command that it reboot with no startup program, etc. I'm sure it can be done. The question is whether the cost to do this is warranted. I've had the cRIO lock up because of a corrupted deployment and it would not respond over the network until someone physically attended to it by setting the "no app" switch. This cRIO was mounted on a bridge over the Delaware river and was a real hassle to get to, and throw, that switch.
Suggestion: Dedicate a portion of the processor code to servicing the Ethernet ports that can't be consumed by the startup program. The user needs to always be able to reboot the cRIO and download new code.
During LabVIEW Development was a PXI Real-Time System connected (LAN) next to my Laptop and process Build/Deployment was no problem.
Now the RT has been shipped far away to customer site and i have no longer access to that network.
So I need an other way to distribute and
here is my IDEA #1: (below is another IDEA #2)
FACT : Most of all customers have no knowledge about "How to find the Real-Time System and update the Application on it".
So the new item will built an "Offline Installer.exe" and will run on any customer PC to a full automated update job automatically.
Features:
- create a detailed installation report which can be stored and send back to the developer.
- In case of the Real-Time System isn't connected to any LAN, the customer could use the "Offline Installer.exe" to prepare an USB-Stick which has to be plugged into the Real-Time System. Then a reboot will launch the full automated application update process. (the "RT LEDs" will give feedback when the process is finished)
I tried also another way but without success:
Step 1: Add a ZIP File into the Project Explorer : "My Zip File"
Step 2 : Configure the "My Zip File" => Add "My Real-Time Application"
Step 3 : Build "My Zip File"...but the Result was bad :
But anyway, if the would be successful there are a lot of more steps needed:
- sending the ZIP to the customer
- unpack ZIP
- find Real-Time System at customers network
- a FTP tool is needed to update the system.
- There is no way to stop the running Application (from a PC without NI-Software)
Conclusion:
The update with "ZIP" is far away from a comfortable solution.
IDEA #2
If the Real-Time System has a running webserver (the thing which is using Silverlight),
then the application could be updated by using a webbrowser.
So, first we have to update the webserver on the Real-Time System (as difficult as updating the application)
The only functionality of RT USB is mass storage. It would be helpful to add at least RAW Data USB support to use USB port for connecting i.e. USB / RS232 adapter. Many analyzers use integrated serial/USB converter chips to transfer data to PC, because no need of specialized driver (you get the driver with the chip). The ability of RAW USB support allows to connect these analyzers to cRIOs and RT PC Targets.
Ability to create a GUI (with touchscreens) using the graphics capability on desktop PC's. Maybe something like PEG (portable embedded GUI). For small testers, I don't necessarily want a PC or touchscreen PC running CE or XPE. The PC's involve a lot of setup, virus concerns, etc that I don't need on some testers. Support would be much easier also. Plus, in a lot of organizations, they don't understand the difference between PC's for desktops and PC's for production stands. You end up getting a "standard" PC with a lot of restrictions on it that requires several different groups to support when it fails.
A number of times, I have found the Real-Time Clock configuration screen in Measurement & Automation Explorer to be very limited. With only the options to set the Time-Zone/Daylight Savings Time/UTC, I feel like there could and should be more!
Adding a feedback to show what the current RTC is set to similar to the Windows Clock configuration would be GREAT! Additionally, add the functionality of the RT Set Date/Time VI to Measurement & Automation Explorer.
We frequently run into issues where the Daylight Saving Time value is different between the US and the rest of the world (frequently=twice a year).
I believe all of this can be resolved by adding 1 layer of abstraction to translate a base RT system clock to the user-specified specifications to be added to timestamp data, schedule tasks, and so-forth.
If you use a VI to control a RT target via Web browser then only polling is possible to register user actions. Since: "RT targets support the Event Structure only with dynamic events." (LabVIEW Help 2010) You can program such graphic object events but they doesn't work.
The support of graphical object events would improve the capabilities for applications with cRIO and sbRIO without a LabVIEW-Host.
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,
It should be nice to create a low level CAN toolkit which could create or parse the 64 data bits of a CAN frame, without having to use the existing heavy tools.
What i would like to see is a list of low level VI's like readBoolean, readInteger, readFloat, readSingle ... writeBoolean, writeInteger ... with direct handling of the data coding (Intel / motorola)
These VI's could read/write channels directly to the 64 data bits of the frame.
These VI's are not very difficult to build ... and everyone who has already use the frame API, without DBC or NCD has done this work before.
My need is to create an official, validated list of low level channel read/write ... without having to use the channel API or CAN engine which ar not very powerfull.
For example :
ReadInteger ( in data, in startBit, in integerLength, in coding(Intel/motorola) , out integerValue )
ReadUInteger ( in data , in startBit, in integerLength, in coding(Intel/motorola) , out UIntegerValue )
readBoolean
ReadFloatCodedInteger( ........ offset, gain )
readFloat
ReadSingle
...
write....
When you speak with NI CAN users they all say ... NI CAN is too slow ... I think that this toolkit could help many CAN users to come back to NI CAN.
The top would be to create, using this low level API and a little bit scripting, a wizzard which could generate automaticaly the read and write VIs for selected frames of a DBC/NCD file. ( A frame = 1 read VI, One write VI and 1 cluster per frame containing the channels )
The generated result could be something like a polymorphic VI.
Streaming data is an important part for many applications. If the amount of data is very large, a RAID can improve system performance significantly.
Sadly, RAID is currently not supported for RT so Real Time Applications cannot use this valuable tool for enhancing streaming performance.
On Hypervisor systems, RAIDs can be used, but data has to be passed from the RT to Windows first. So streaming does not work like/with DMA but it uses CPU load which is in fact a waste of resources.
I frequently use the RT Debug String VI to add useful comments about the health of my application. Sometimes, I believe it would be nice to indicator error/danger conditions with a different color of text.
Do you feel it would be useful to have the ability to change the color of the string? If so, vote me up.
At the moment Labview RT does not support high speed USB 2.0 (EHCI) functionality on PXI-8xxx controllers even if the controller has supporting hardware. We implemented a copy operation to transfer data files from a harddrive on the PXI chassis to an external USB connected flash drive using the copy VI, and only obtained speeds at USB 1.1 (OHCI) levels. We also tried a move version using the Move VI with similar results. The controller used in our tests was a PXI-8186, which has USB 2.0 ports.
My discussions with NI Support and the R&D team indicate this a limitation imposed by the ETS RTOS from Phar Lap that Labivew RT runs on. This is inline with the fact that VxWorks supported controllers have access to EHCI speeds as per this faq:
The Distributed System Manager does not allow one to see the values for a cluster in a deployed process. It would be nice to view and edit values in the cluster.
When running a VI in development mode while targeting an RT device, you must "Save All" prior to deployment. This is annoying, especially when using SCC. I'm sure that SourceOnly will minimize this effect in LV2010, but the concept still remains: I don't want to be forced to Save All when I don't want my edits (or automatic linking edits) to persist.
I am using the AF-1501 Frame Grabber Module from MoviMED. Right now I am able to capture and store images in BMP and TIFF formats at the RT level but I would like to be able to create AVI videos at the RT level.
The idea is to be able to record videos and then store them (either in the internal memory of the RIO or in an SD card using the NI-9802).
The problem is that the RT processor does not run windows and has no cocdecs. Therefore the AVI generation VI's from the vision palet do not work. Even if it is tight to a particular codec, it would be great to be able to create AVI's on the RT target.
Create an RT FIFO Primative similar to the Get Queue Status VI that returns the number of elements in the RT FIFO. Currently RT FIFO Read and RT FIFO Write return the number of elements in the RT FIFO, but calling these VIs will affect the contents of RT FIFO.
A workaround for this would be to maintain a count on a shift register and increment/decrement it each time the RT FIFO Write/RT FIFO Read VIs are called. This solution does not work when trying to monitor the size of an RT FIFO in a running VI in another VI that is used to detect memory leaks.
VI Server nodes are asynchronous nodes. I would like to be able to get the VI Name in a subroutine. This could be done now with an XNode. Or, it could be a compiler optimization. Since VI Server nodes are a shared resource, they can cause a priority inversion.
The development environment for RT is really a great, integrated system. It's so convenient to develp on a regular PC and deploy the VIs for testing. The real-time UI feedback during development is a boon to productivity. It's difficult to imagine a useful RT workflow that doesn't include a live panel in the development mode -- it's an idea that is both powerful and intuitive.
What I would really like to see next is similar RT panel interactivity in a deployed run-time system.
At the moment, I am using a 'remote panels' implementation to stream an interactive panel view back to the PC. (I assume that this is similar to how things are managed by the development environment itself.) The problem with this approach is that the Remote Panels API seems a bit flakey at times. I don't always seem to get a reliable connection. What's worse is the programming overhead associated with setting up the remote panels connection, and the sometimes fickle behavior of Windows in allowing a remote PC to connect.
Since the RT development environment already has the capability of seamlessly displaying an interactive UI on the Windows client, would it be that difficult to add UI panel feedback into the run-time executable environment?
I realize that, at first glance, this may seem to defeat the whole purpose of an RT system. However, I have built a few different Vision RT systems over the last few years, and the same challenge always seems to come up in every project. When I need to implement a calibration, focus and/or alignment mode on the RT target, I find myself performing all kinds of contortions to retrofit a simple interactive RT utility for use in the deployable application.
If I could simply implement an RT VI that presents an interactive UI on the Windows client (just like when you are in the LV Development mode), perhaps I could eliminate the complexity of my current strategies: Either 1) developing an elaborate case structure and messaging system on both sides of the network connection to pass images and parameters across the network in real-time, or 2) implementing a (hit-or-miss) remote panel linkage to a self-contained RT configuration VI over a remote panel connection that isn't always as robust as I wish it would be.
If the heavy liting has already been done for the Development system, surely it wouldn't be too much of a stretch to enable similar functionality in the run-time environment..?
