Nick S

The keyword is LabPython

Wow. I was so focused on trying to find it with the other OpenG tools that I did not even think to look for a separate project. Thanks for the pointer!

Okay, I feel stupid posting this but it has bothered me long enough that I need to ask. I see images on the OpenG website of the Python package, have heard people talk about using it, but have had zero luck finding the actual code anywhere! It is not in VIPM and not in the OpenG SVN repository as far as I can tell...

Would some kind soul point me in the right direction so I can try out this nifty sounding bit o' code?

One vote for GIMP (bitmap) and Inkscape (vector).

I'll put in another vote for GIMP. There is a definite learning curve, but GIMP matches more expensive packages like Photoshop and PSP all for the low, low cost of $0.

Congratulations Jim!!

Hoping someone else will do it because of the nice technical challenge this provides would require less time on your part but has a very good change to happen somewhere between now and the end of all worlds . It would be different if such a solution would be possible to be commercialized but I see little chances for that.

Same thing could be said of the possibility of having a stable, powerful PC operating system that is freely available AND distributes all the source code associated it, and last I checked it is not Armageddon (talking about Linux btw in case the reference was too oblique)

Kidding aside, I'm not waiting on this for a job that I currently have lined up, or one I am even planning on doing. GoGators asked if it'd be useful, and I was positing a use case. If he does it, great, I'll take a look. If he doesn't, the world goes on. If I'm bored some day (or in this case, week), maybe I'll look at it myself.

So I trying to say your idea is ahead of the technology but if you prepnow you could be ready when cheap targets have enough horse power topull that plow.

Perhaps some background - I work a lot with RT targets on PXI systems. PLENTY of horsepower there for running whatever you need (since PXI systems often have desktop-caliber processors in them). This probably isn't the best choice for a cRIO quite yet, but who knows - SQLite is pretty well, light. If someone tries it and it doesn't work, then they've at least gained the knowledge on the way. If it does work, great! Other than doing something that causes permanent hardware damage, software experimentation is pretty safe...

Can you explain to me your use case for an embedded relational database more clearly? I would like to understand that issue.

I can't speak for GoGators, but for me at least the plan was never to leave the data in the database on the machine as I think you are thinking. Rather I would use it as a cache that provides atomic commits in cases where test data absolutely can't be lost. The problem with the binary file scheme that you talk about is if the system goes out to lunch during a write, you could end up with a corrupted cache file and lost data. True, it may only be a minute or two of data, but in some tests that is unacceptable. Because SQLite provides atomic commits, if the system goes out in the middle of a write, no problem - SQLite knows exactly how to handle the incomplete data and nothing is corrupted. Having the data already in relational database format also means an easier time cloning the data to a central database (where MySQL et al would be appropriate).

The other unique thing about SQLite versus systems like MySQL, MSSQL, Postgres, etc. is that its calls are all done directly through the DLL/shared library - there is no "engine" running in the background. It is specifically meant to be used as an embedded database and says so right on its main page.

I will say though that outside the caching scenario, leaving a large amount of data on an RT system seems unwise, especially cRIO's.

I used a mid-range IBM ThinkPad with 8.5 for 1.5 years, and now use 8.6 on a Dell Latitude. I've never had any problems I could attribute to the laptops. I agree with PaulG - a mid-range ($500-$1000) laptop from Dell would do well for what you need.

If you look through old lava posts, people have talked about doing an OpenG project where they make SQLite work in LV. The idea was to make a DLL...

Okay, I understand now. I will have to look into those old posts - having a LV implementation of SQLite on RT targets would certainly be a worthwhile project. If you did a writeup on it I'd be very interested in reading it. We currently have a system that is logging all data as TDMS, but it would be a lot more intuitive (and easier to search) if it were in a relational database.

A) Anybody actually going to use this stuff, or am I wasting time.

Although I don't have an immediate need for this, this is something that I guess I would have assumed already had a solution and wouldn't have thought about it until I wasn't able to do it

So I know I would definitely be interested in reading more about this. It never hurts to have more tools in the toolkit.

C) Anyone been working on the SQLite thing lately?

I'm just slightly confused what you mean to do with this. Do you mean to have your LV program transact with the local SQLite instance and then clone the data on the RT over to another machine, or is there functionality for network databases in SQLite that I don't know about?