Leaderboard

A new feature called the "Session Extension" has just been rolled into the trunk of latest release of SQLite (3.13.0). From the authors: In a nutshell you can "diff" a database and produce a patchfile of the changes (and the reverse). Now. Most are probably thinking source code control at this point which isn't very interesting in terms of LabVIEW. However. There is another use case - synchronizing remote acquisition databases. Previously we could have a SQLite database to store acquired data in, say, a cRIO or PXI chassis. Periodically we would want to back up or synchronize another database either for back up, offline exploitation or the file was becoming too large to store.. This meant making a backup copy locally and then sending the entire database file to the recipient. That could take a long time, was fraught with problems of disconnection and there may have not been enough space to create a copy. With this new feature we should be able to overcome or at least alleviate these issues and effectively implement "restore points" and "staged updates" for remote databases as well as bandwidth reduction while synchronising and configuring. For example. We may store configuration information, amongst other things, in the database and only want to update that section. We may only want the last 24 hours of data sent back for exploitation. We may only want error or waveform meta information....and so on. I'm looking forward to playing with this feature over the next few weeks. so if you have suggestions for another use-case, then I would like to hear it.

You make some good points, but I don't completely agree: Ever been to a robotics competition? NI is pushing their stuff there for sure. Then there are the engineering colleges that offer LabVIEW courses for those that aren't CS/CE. I'm not blind to changes, but I'd hardly call it a demise, especially in my personal life in the surrounding job market where I got 3 job offers in the last 3 weeks, and I'm not talking about random Linkedin recruiter messages.

Google trends for "Learn Python" Google trends for "Learn LabVIEW" I agree with another poster that it feels like LabVIEW is headed for the retirement home. Probably because that is where all the expert users are heading soon. Our LV user group is full of grey-haired old folks, while the yearly Python "boot camp" is full of 10 times as many bright-eyed kiddies. It doesn't take a math genius (although most of us are) to see what is happening. How can we stop the slow demise? The answer is, we can't. Only NI can do anything about it. I'd post a list of what they can do, but they won't do it.

I guess I would say look for the module being compatible with a 9074 in FPGA mode. This excludes things like the XNet interface which is RT-only but includes things like the raw CAN card. You can also emulate it in the project -- if the FPGA compiles, it will likely work. The two big showstoppers I've seen with ecat are... Yeah lots of small logic bits will save you with the ethercat...but theres also the risk you run out of space since the FPGA on those guys is so small. The other concern is the number of user-defined variables. While you can have full chassis worth of IO, you can only have like 64 or 128 or something like that UDVs per chassis.