Jordan Kuehn

In the spirit of all the DB discussion yesterday which has coincided well with some tools I've been working on this week, I've got a question of my own. Essentially I just want to make a ring buffer stored in an SQLite database (sure, it could be any type of db) to buffer some data acquisition for use as pre-trigger data as well as a local window. With that in mind I added a trigger to ShaunR's Data Logging Example and increased the decimation factor high enough to not decimate (didn't want to mess with the rest of the example). The trigger code is below for a buffer of 1000 entries. Now, this seems to work fine and not blow up the size of the db or anything with my limited testing, but are there any issues with simply deleting preceding rows and allowing rowid to continue increasing? If there is an issue with this implementation, what proposed solutions do you have? I could create pointers and such and manually iterate around in LV when inserting, but I really want the db to handle this and have it be transparent to my application. I have an understanding of writing to and querying db's and use them a lot for test specs and results, dynamic field population, etc., but I haven't done much in regards to buffering or storing acquired data and am working on exploring how doing more work on the db side can make things easy on the LV side. DELETE FROM graph WHERE rowid%1000=NEW.rowid%1000 AND rowid!=NEW.rowid;

Excellent intro presentation. I attended one of the earlier AF sessions at NI week in 2010 (I think) and came away with a good impression of it and it's power, but an article like this would have saved me a lot of time picking up the basics. A good follow on topic could be taking the pyramid structure of Actors shown in Part 3 and digging into that a bit and effective communication techniques between parts of the system. Some focus on messages and routing perhaps.

Awesome. Thanks!

Yeah, this is an old thread, but I can't find what I'm looking for. Any SQLite support for the newer linux based RT targets?

Definitely pursue a time and materials basis like ShaunR outlined. Make sure to have clear milestones with time and cost estimates (often our first milestone is purchasing all of the hardware) and then not only get a sign-off, but try to negotiate so that you get paid after each milestone. This serves two purposes, it helps keep you from fronting too much time or money, and secondly it is a very firm indicator that they agree that you have accomplished that milestone to their satisfaction (deliverable and actual cost). If you run into trouble down the road (total # hours differs too much from the estimate for example) you can point to that sign-off and payment as proof that you and the customer both agreed to progress on the project after that point. That being said, don't make milestones too small. Depending on the size and scope of the project you might look at 20-80 hours of work. You don't want to be spending a ton of time writing invoices and making them cut checks.

Even simple FPGA code can take quite a lot of time to compile. There are various strategies for maximizing each compile, and minimizing the compile time. You can use a Windows PC to program all the cRIOs. If you can use the scan engine, you can get a simple to moderate level system working without too much pain. Adding the FPGA can add significant development time, especially if you have never programmed one before. Here is the NI development guide that is a good resource as you have some more detailed questions. http://www.ni.com/compactriodevguide/

I was about to comment with the same thing about FTP not being enabled. I can't confirm the exact year, but I think fairly recently the FTP server is not even installed by default.

That seems to be a question that would produce limited replies without the VPN caveat.

In a similar application to the off-shore oil well (fracking happens in very remote areas on land) we've used the GSM c-series module from SEA and other 3rd party DIN rail mount modems (MOXA) via a VPN hosted by the customer's IT department. In addition to providing security and locking all other access down, the VPN gives us the ability to access the cRIO as if it were on the network and update software and such beyond just communicating via whatever protocol you've defined. Aside from that, most of our applications exist in a separate factory floor LAN with no internet access. That typically leaves us only concerned about locking the operator out of screwing with the system.

Link to the original example?

I can see the benefit to this, but callback VIs seem to obfuscate the code greatly to me, as you mention in your disadvantages list.

While perhaps not relevant for your applications, I am still quite intrigued by the loosely alluded to cross-platform nature of these "wires". If communication across platforms was as easy (and much safer than) using local variables I see a great benefit. One big hurdle with cRIO programming comes about when a host computer is needed. Some of the new platforms mitigate this need, but don't eliminate it. If I can run a (LV) wire from a cRIO to a host machine without doing any configuration and have a loss-less transfer mechanism implemented I would be quite happy. Sure I can do the same thing with streams (or any of the raw TCP communication methods), but they can be clumsy and need to be wrapped with auto-connect logic to handle real world situations. We use a high level language for many reasons, but abstraction is near the top of the list.

Shared variables aren't loss-less unless you have some magic I don't know about. This seems to be a combination of NSVs and Network Streams without the additional configuration.

To summarize, all the complaints I'm seeing are related to the representation on the BD. Is that accurate? To me this seems like an incredible concept if done correctly. Essentially a loss-less local variable that can communicate cross-platform from what I've gathered. As a final note, I think this subject deserves its own thread and this one can return back to highlighting the new features in 2015. Though it might be a pretty short thread then...

Thanks!

Fab, This looks really cool, I look forward to digging into it. I haven't looked through all of the sessions next week, any chance you will be presenting it during one?

Side note: I did not know this and reading this made me very very happy.

No problem. I think that the Database Connectivity Toolkit should include a primer on ODBC that's easily accessible. This same issue drove me crazy several years back.

http://digital.ni.com/public.nsf/allkb/E7984C0DA0F0E65086257694005B4CB7

If you insist, try Ctrl+Shift+N.

That's an interesting thing to observe. I'm not entirely certain exactly what that would mean about code I've produced for a customer, but I might look into this. I think it may describe a great deal about the type of application. I could see creating similar amounts of code for two different applications and producing very different results according to this metric.

Look at the stop event condition and follow the logic

When starting out with simple tasks, get a task to work with the assistant. Then copy it and open the front panel to convert it to a VI and poke around in the Block Diagram. Basically ready-made example code for your simple application which will help you understand how to make more complex operations.

DataFlow 6.0.4

As usual hooovahh is more eloquent than me. Check out "find examples..." under the help menu for some of the referenced content. If you are looking for a quick and dirty FPS calculation my link will do just fine though.