dmurray

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.

Do you mean just for testing packages before sharing? Or something more powerful?

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.

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.

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. Another point is that the .so file in this case would not be compatible with the TSXperts compiler for RPi, which I believe is imminent. Edit to add: Just realized you mean will there be a dependency problem for users when they install the package. That's something I need to check on a second machine.

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). Another possibly important detail about the shared object file in this case is that it will only be compatible with the LabVIEW LINX tools. There are already some conditional disable options set up for the RPi in that case:

Done. Thanks again.

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, much appreciated.

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.

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 errors. So everything is fine up to this point. The problem occurs though when I install the VIPM package (to vi.lib, although it doesn't matter where). All the VI's in the package are broken (see pics below). I can solve this by simply opening up each CLFN on the block diagrams and then closing them- the VI is fixed and the Run arrow becomes unbroken. So this will solve the problem. But I need to do this for all the VIs in the package which is tedious. Does anyone have any recommendations on how to solve the broken VI problem? To be honest I don't mind the fix I have (opening and closing the CLFN for all VIs) but other users might not like this idea, and sharing decent code is one of my aims in using the RPi (in the Maker tradition). Open and close CLFN to fix broken VI: Fixed VI:

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,

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!

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.

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.

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 in my usual LV programming, so I'm not quite sure what I want here. If I was using a CRio I could use the built in HW watchdog timers, but that doesn't apply here. So I guess I need some sort of SW timer. What's the general advice here regarding custom-built watchdog SW timers?