Jump to content

Feature request: watchdog timer


Recommended Posts

I use the IO-16 bricklet to switch some relays from a python program. The problem is that sometimes the program (or brickv or the linux usb library or some other link in the chain) loses connection to the master brick and I risk leaving a relay in the open state.


Now, in my particular application, leaving a relay open too long is something that you want to avoid (safety wise).


So, my request is to add a watchdog timer feature to the API which can be used to set the output ports of the IO-16 to a known safe state unless the timer is reset before it expires.


Something like this:


IO16.set_port(port, value_mask)

IO16.set_timer(port, value_mask, seconds)


Now, this probably wouldn't be very useful if it was implemented only in brickd. It would probably be best to put it in the code that runs on the microcontroller so it can still trigger when the usb connection is lost for whatever reason.


I guess a similar feature would be useful for other bricks and bricklets (stepper motors, relays, analog out, etc.), basically anything that controls something in the outside world could probably do with an extra safety net.


Link to comment
Share on other sites

Not too many I guess:


Bricks: Servo, Stepper?

Bricklets: Dual Relay, Analog Out, IO-4, IO-16


Setting and resetting a timer could be done with one function. (seconds = 0 -> disabled). Perhaps a generic set_timer() function could call even any other API function?


set_timer( object, function, seconds, arg1, arg2... )


Anyway, I hope I now found the cause of my 'crashes', anybody seen this Linux kernel message?


Jun 11 13:18:37 X kernel: hub 4-0:1.0: port 2 disabled by hub (EMI?), re-enabling...


Link to comment
Share on other sites



The problem (loss of connection between pc and bricks) used to occur about once a day. I tried to fix things by packing my project in a metal cookie box. That seemed to work well, because I had no more problems for 4 days! Yippie!


But... Then my family wanted their cookie box back so I took it all out again. I then expected the problem to return but everything's still running since two days ago. So much for diagnostics :(


So I'm afraid I can't tell you anything conclusive. I still plan to put things in a metal box cause that seems like a good idea anyway.


I still think a brick watchdog would be good, but Plenz has a good point of course. So I'm now wrestling with a 555 chip to set up a hardware timer with 3 different intervals on my board. The idea is that when the app closes a relay it also starts a matching timer (5, 25 or 45 seconds). When the timer expires the relay is released. That should be a pretty good safety measure.


Link to comment
Share on other sites

But... Then my family wanted their cookie box back so I took it all out again. I then expected the problem to return but everything's still running since two days ago. So much for diagnostics :(


Update: Another failure! Without the lo-tech shielding of the cookie box, today things started working erratically. The connection to the bricks was still up but when I fired up brickv one of my master bricks (the top one) seemd to have stopped functioning and all the bricklets connected to it stopped working. A usb unplug/replug solved things.


Hypothesis (warning: amateur): Something in the master bricks is sensitive to this thing and if it happens to hit the bottom one the connection to the PC is lost, if it hits te top one the connection to the top bricklets is lost.




PS: Couldn't the user interface of brickv be improved a little? I have to click so many times to change the state/function of the IO-16's ports. It would already be a great improvement if one could specify the IP address of the  brickd server on the command line :)


Link to comment
Share on other sites

  • 1 month later...

I can't really be sure if the problem was with EMI. To be on the safe side I added a 555-based watchdog timer that switches off the relay after about a minute even if the software and/or bricks die completely.


And then...


I started to enjoy the whole messing with IC's thing and I decided to redo the whole project with a Teensy controller and some comparator/optocoupler IC's. That turns out to work very well so I'm afraid the bricks are collecting dust at the moment.


The Teensy setup has a number of advantages for my project:

- It's cheaper

- It's much faster (100x) to use a comparator IC and a Teensy than (multiple) analog bricks and that speedup makes things a lot more responsive.

- It can run standalone (USB disconnected) as well as controlled by my server (USB connected)

- It's a bigger challenge ;)


The last advantage could be be seen as a disadvantage I suppose. But I'm quite enjoying the tinkering. ;)



Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...