Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation


About dmurray

  • Rank
    More Active

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2013
  • Since

Recent Profile Visitors

1,384 profile views
  1. Okay, just to tidy up this post, the steps I used work with no dependency issues when I tested on a second PC (just got around to testing this now). The package(s) are available on the NI forum here, if anyone is interested. Thanks to everyone who helped me with this.
  2. You need to place them in "/usr/lib", but you also need to be logged on as the root user working in the LV chroot. I wrote a simple document on how to create these shared objects and where they need to go on RPi. All the information should be there but if anything is unclear let me know.
  3. Now that you mention it, I am actually getting a second PC in place to test these packages before I share them anyway. That will tell me a lot.
  4. I don't think so, the build process doesn't seem to care too much about the file once it can 'see' it in the Shared Object folder I created in vi.lib. However, users will still have to copy the shared object file into the correct location on the RPi, using Filezilla or some other means. And it needs to go into the user space that the MakerHub LINX tool creates. See Local IO description here for more details on the architecture if you're interested. So a user still has some work to do, which isn't ideal. I'm sure the process could be automated, but that's lower priority at the moment. Anot
  5. TARGET_TYPE doesn't seem too work in this case. Or, to elaborate, it works fine when building the package, but not when I deploy a project to the RPi (I get an error that the .so library cannot be opened). Also, on the project that I'm deploying to the RPi, I can't now set the TARGET_TYPE parameter to Unix try to get around the error. It says something about the symbol being reserved by LabVIEW. Possibly I'm doing something wrong. I don't think it matters that the user can only work in a project. I think they actually have to, as they need to set the target to Raspberry Pi (see below).
  6. Works perfect, thanks for the suggestion! Here's the steps I used, for anyone else who has this issue: 1. Created a directory in vi.lib for this shared object and future shared objects. 2. Used the 'Specifiy path...' option for the CLFN, and created the sub-vi for the path. 3. Created two options for the path; one for OS == Win and the other for OS == Linux. 3. When I build the VIPM package, I use the OS == Win symbol. 4. Then, in projects that I will deploy to the RPi, I use the OS == Linux option. Thanks again
  7. Doesn't seem to work unfortunately. For some reason a phantom file "libLV_2835.dll" has now appeared in the project dependencies, but the original problem still remains.
  8. I've built a VIPM package of re-usable code which I want to use with the Raspberry Pi, the RPi effectively being an embedded linux platform. For the code I first built a shared object file (.so extension, basically a linux DLL) for this GPIO library. I then wrap the functions I need using LabVIEW CLFN's. Of course Windows hates this file and LabVIEW will complain if it tries to access it, but I can solve that by building my library inside a project with RPi as the target. When I build my VIPM package, a search takes place for the .so file, but it gets ignored and the package builds without err
  9. Don't change on my account, the discussion is relevant and interesting to me. Any more questions from me will probably be distinct enough that I will start a new thread anyway,
  10. It turns out the RPi does have an internal watchdog feature, as you suggested, although apparently it has some issues. But I also found this, which will serve as an external watchdog if I need it. As well as the watchdog functionality, the real time clock itself will also be useful, as the RPi needs to be connected to the internet to keep accurate time (i.e. it doesn't have native or on-board real time clock functionality). So this is perfect for what I want. Anyway, I'm probably overthinking this, because on reflection the concepts are really simple. But thanks for your help!
  11. Okay. So is my thinking correct here?... I could use a HW Real-time clock module and configure it with a timeout. When my SW is running on the RPi, I just 'kick' the module timer periodically to reset the timer. And if the module does time out (because my SW has presumably hung), the module sends a signal back to the RPi which will reboot it.
  12. Not sure why I thought this was difficult. I just added a Watchdog Event Loop to any sub-VI I want to monitor, and send the status to the client. So it's more of a status monitor than a watchdog timer, although it does flag timeouts to the client as well.
  13. Related to my post here regarding designing a decent architecture for Raspberry Pi, I want to implement a watchdog timer, or timers. My current architecture is shown below. The three main loops that I think I need to monitor are the RPi Scan Engine, RPi Command Handler, and the Data Logger, The Scan Engine reads the system temperature and high-temp alert.The RPi Command Handler accepts commands from a TCP client and updates system settings. The Data Logger just logs the temperature and alert status at 1 second intervals. Regarding watchdog timers, the problem is I've never had a need for one i
  • Create New...

Important Information

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