Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
Browse by label or search in the LabVIEW Real-Time Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW Real-Time Idea Exchange. Be sure to submit a separate post for each idea.
Watch as the community gives your idea kudos and adds their input.
As NI R&D considers the idea, they will change the idea status.
Give kudos to other ideas that you would like to see in a future version of LabVIEW Real-Time!
Currently, when you add a new (not existing) cRIO controller and chassis to a LabVIEW project, there is no check as to whether this is a valid configuration or not. For example, you can successfully add a cRIO 9072 controller with a 9112 chassis to a project, even though the 9072 is a controller with an integrated chassis. I believe that the LabVIEW Project interface should notify the user (via dialog box) that this is not a valid configuration before they can add modules and start developing code to use an invalid configuration.
It would be nice if attaching a thumbdrive to a cRIO / RT usb port triggered a "mounted" event or interrupt in the RT OS. Currently the only way to discover if a thumbdrive has been connected is to periodically run a file/folder info VI and see if one is present. It would be nicer if we could register a dynamic event and wait for it using an event structure, or similarily register for an interrupt event would work as well.
In my case, the use-scenario is a field maintenance person going out and manually plugging in a thumb-drive about once every 4 weeks to get the stored log files off of the controller. (No, we cannot use remote access in this case due to customer network restrictions.) So, in my case, I can easily use the polling solution, but if there is one thing I don't like to do, its to write polling code of any sort. It seems so wasteful. Other possible use cases could be to detect the presence of a thumb-drive and check for patch/updates, copy over new configuration files, etc.
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:
I was replying to a message thread someone had about question marks showing up for the times in the I/O channels for a compact Fieldpoint system. While investigating, I notice on my system that I had timestamps for data that occurred later in the day than the current time. So I know those timestamps were from a day prior than the current day. Actually, the test stand had been idle for quite a few days, so I pretty much know those I/O channels had not been updated for a while. But I could not tell from the timestamp when exactly that data was from.
In the attached screenshot, the current time was about 1:44 pm. Some data shows it had just been timestampled. Some data was from 7am, other data from 2:19 pm or 4:19 pm. I know that that data had to have been from yesterday or older. The 7am could be from today or older, but there was no way to tell. Based on my usage of that test stand, I'm pretty sure all of that data is at least 3 days old, and perhaps 6 or 7 days old. That is okay and not a problem. But there is no way of knowing how old that data actually is based on this screenshot.
I think MAX should show the date as part of the timestamp when looking at the I/O data.
Message Edited by Ravens Fan on 10-20-2009 11:48 AM