Feature request: watchdog timer

[Xenna]

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.

 

[borg]

That sounds like a good idea indeed. The big question is: What functions on which Bricks/Bricklets would need such a timer.

 

Having a timer (and reset) for every available function would totally blow up the API.

[Xenna]

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...

 

[Plenz]

In my opinion, a really good watchdog should only work from outside the system. A simple relay could do it if you connect its switch to one input pin of the IO16 bricklet. Switch the relay on/off and check from the input pin if it is really switched on/off. Repeat this after some seconds/minutes.

[batti]

Xenna, have you solved these strange EMI problems?

[Xenna]

Well...

 

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.

 

[Xenna]

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.

 

X.

 

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

 

[photron]

It would already be a great improvement if one could specify the IP address of the  brickd server on the command line

 

Brick Viewer version 1.1.1 now remembers host and port information.

[batti]

Any update here Xenna?

 

We are currently discussing possible improvements...

[Xenna]

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.

 

 

[batti]

Ok...

 

That was not the answer I was expecting , but it's nice that you enjoy the tinkering...