Disappointment in XNet Database Functions on RT

[Hooovahh]

So I have a test setup that is using one of the new Linux RT cDAQ chassis.  Overall I love the hardware and with the embedded UI I can look into designs that eliminate the need for an industrial PC and just run everything from this hardware.

One of my feature requests from users, is to have the ability to walk up to a station, plug in a USB drive with a CAN DBC on it, select it, and then start taking CAN measurements and logging to the USB drive, then be able to take the drive to their computer and run analysis on the data that was logged.  I thought one feature I'd like for traceability is to take whatever database was used on XNet for a session and log it along with the data, so that when the drive is taken away to a PC the actual database used would be kept with the data recorded so there no confusion about what database was used for what measurements.

Because of limitations with XNet API on RT hardware I can't do either of these things.  The Add Database returns -1074384580 (The feature is not supported under LabVIEW RT).  So I can't add a DBC from a USB drive, I must perform a deploy from an industrial PC.  Even if this was the case, I also cannot perform any kind of Database Save, or Database Export, to save a copy of the database used in the log file, because they also aren't supported.

Is there any solution?  I noticed that deployed databases are saved in a SQLite database in ./var/local/natinst/nixnet/dbCache/.  Is there a way to turn these SQLite databases into either a CAN DBC, or the FIBEX XML?  That way I can at least save the database with my data, and can be used elsewhere for processing.  Is there any other solution for adding a database from the RT?  Is there any plans to add these features in the future?

[luda.mattski]

Hi Hooovahh,

I don't have enough insight - as we're relatively low on R&D staff because of the Thanksgiving holiday - to speak on whether or not this is under development but would be a great addition to the Idea Exchange.  The XNET driver is still undergoing development and adding features since it is a relatively new addition, so it definitely could be in a future release.  Posting to the Idea Exchange can only help to speed up the addition of that database functionality to the XNET driver's natively supported function.  

[Hooovahh]

Idea made.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Improve-XNet-API-Support-on-RT-Targets/idi-p/3547788

But I'd still be interested in any work arounds R&D can suggest, either for the import or export.

[JefeL]

Thanks for posting the idea. I did a little research into the background of the current implementation to get a sense of why it is the way it is. Parsing the FIBEX or DBC files on a RT target uses a significant ammount of memory and processing. We currently offload most of that overhead to the more powerfull development machines so that we can significantly decrease the time required to initialize an application on RT. The use cases you have provided are certainly valid and we will take a closer look them moving forward.

Unfortunatley there isn't much we can do in terms of workarounds. Deploying the databases from the development machine is the only way to make it work at this time.

[Hooovahh]

Thanks for the update.  I'm sure the term "significant ammount of memory and processing" is relative and the development of any RT code probably has a very large focus on performance.  Traditionally on RT you want really tight timing loops and taking more than a few milliseconds to parse a file can be a cause for consern.  But clearly as these RT targets get used more with the UI and users interact with them, having something like an initialize step that takes several seconds to parse a file before performing any actual work, isn't that big of a deal.  Assuming you aren't doing anything like a feedback control at the same time.  The issue clearly is when you have a design more like a PLC with tight timing, and your program never really stops.  

In my case this is more like a sequencer where the user can set it up to do a bunch of things then hits Go.  Before starting the sequence the code is doing nothing other than polling (at a very slow rate) to update the UI with data, waiting for user interact, or waiting for a network stream to tell it to perform an action in the same way the user could.

What about the second half of my question.  Is there anything useful that the SQLite database can be turned into?  Is there a converter that can take that database and turn it into a FIBEX after it has been transfered back to the Windows side?  I think I have a solution for now, but for tracability I was hoping I could make a copy of the database the RT is using.  Then once the data is transfered back to the Windows PC, I could parse the log data and use the actual database the RT was using when it was logging.  I'm conserned databases will be updated, and the one on the RT won't match the one that is assumed to be used.

[JefeL]

We haven't created a utility to convert a *.db file back to a FIBEX or DBC database so, from an abstract point of view, it is similar to a hash.