LabVIEW Real-Time Idea Exchange

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

Wouldn't it be nice to have a native LabVIEW XML parser available on real-time targets? Storing your config data in XML rather than in Config-ini files is more flexible, techniques like XMLRPC would be easier to implement etc.
Yes I  know about the third party EasyXML library, but I don't want to spend extra money as we are already paying for LabVIEW 😉

I understand that the FE vi's needed to be optimized for speed so that they could be put inline without disturbing RT timing.  But it would be nice to be able to send a string description

with the fault so that it would show up in the DSM.  An example would be a fault due to trying to send an invalid remote message.  It would be nice if the invalid message string could be logged with the fault event.

I think making it optional would still preserve the determinism when needed.

I do not know about most people use cases with RT system, but I have the reflex to click the run arrow to test all my VIs. When I am on site and I do have access to the hardware, everything is rosy. But, when I do not have access to the hardware, and depending on the system complexity, I now have to wait up to over a minutes before I can resume working. It would be nice if somehow once I realized my mistake I could notified LabVIEW (right away) to run my VI in the main application instance instead of attempting to deploy it on the missing target.

Alternatively, once I made the mistake once, LabVIEW could automatically run the VI in the main application instance.

I do not know what is the best approach to fix this, but I know that I am very annoyed every time I make that mistake.

It is allmost impossible to find errors in "Reentrant SUBVI's" without the debugging possiblities.
 
 
 
 
Need a possiblity to read out the installed BIOS Version to check if the system is updated..

1. Right Click on Blank Cursor Column will crash DSM

2. Make cursors Max and Min actually work

 

In the Distributed System Manager add the capability to export Historical Data.

Also, in the DSM Allow Historical Traces to be deleted.

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
Message Edited by Laura F. on 10-22-2009 01:32 PM
It would be nice to have an option to reboot RT into safe mode from MAX rather than having to create a safe mode disk.