Jump to content

Jordan Kuehn

Members
  • Content Count

    552
  • Joined

  • Last visited

  • Days Won

    12

Everything posted by Jordan Kuehn

  1. This last part doesn't seem to be working. The path control and any other test controls I drop down don't seem to be recognized. I've started working my way through your configuration code, but I thought I might check and see if there is a simple mistake I've made. Edit// Looks like some work is still to be done to get generic objects/controls to display as images. I've worked on that some and made it work. There are some other things I want to do as well. Perhaps I'll post my changes when I'm done, though don't count on me to take things over.
  2. The combined schema from drjdpowell's suggestions with the trigger I alluded to at the end. Works well enough right now while I'm playing around with it. I like the streamlined View and Inserts and simple interface with LV. Thanks for the help. BEGIN IMMEDIATE; -- wrap initial work in a single transaction DROP TABLE Buffer; DROP TABLE BufferIndex; DROP VIEW OrderedBuffer; DROP TABLE History; CREATE TABLE Buffer (Value); CREATE TABLE BufferIndex (I); CREATE TRIGGER BufferIncr BEFORE INSERT ON Buffer FOR EACH ROW BEGIN UPDATE BufferIndex SET I = ((SELECT I from BufferIndex
  3. 1. I would download from NI directly or host the installer and download from there on the remote PC. Not a direct transfer. 2. We have had no issues using the RAD for RT and FPGA updates. What did you discover? 3. 4. 5. This has proven useful when we migrated several dozen tools from LV 2010 to 2013. Host PCs were used as backups at times during the migration, and sometimes they were of differing versions between tool and PC. Of course, other things may break instead... Props for successfully making a change of this magnitude remotely. We update our tools remotely, but always af
  4. That looks very promising! I'll give it a try. I thought that using a VIEW might be a good approach for retrieval. Thanks! I've used your toolkit as well and will probably use it for this implementation.
  5. ORDER BY looks like it would work if I also include a tick count or something with my data. Works for me on the retrieval side, and that is a nice aspect to the DB. On the insertion side, I suppose I could create an auto-increment variable in the DB that would modulo with my buffer size and provide the rowid to UPDATE. I also like the idea of setting up triggers to say, average my buffer and store a point in another table each time it wraps around.
  6. That's a fair point and yes it behaves more like a fixed length fifo that crawls along in memory rather than a ring buffer. The UPDATE command would require some note-keeping of where the pointer(s) are on the LV side, but does sound like the *correct* way to do this. I would like to be able to insert element(s) and read the entire buffer already in order in LV without doing that. I think a VIEW would perhaps be the way to go for the retrieval side, I'm not sure about the insertion. As far as not using a db, that's also a fair point and I may not ever wind up using this for my stated pu
  7. 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. No
  8. 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.
  9. 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?
  10. 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 fr
  11. 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/
  12. 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.
  13. That seems to be a question that would produce limited replies without the VPN caveat.
  14. 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 typ
  15. 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.
  16. 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 thi
  17. 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.
  18. 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...
  19. 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?
  20. Side note: I did not know this and reading this made me very very happy.
  21. 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.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.