Xenna Posted June 8, 2012 at 08:09 PM Share Posted June 8, 2012 at 08:09 PM 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. Quote Link to comment Share on other sites More sharing options...
borg Posted June 11, 2012 at 06:17 AM Share Posted June 11, 2012 at 06:17 AM 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. Quote Link to comment Share on other sites More sharing options...
Xenna Posted June 11, 2012 at 11:59 AM Author Share Posted June 11, 2012 at 11:59 AM 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... Quote Link to comment Share on other sites More sharing options...
Plenz Posted June 14, 2012 at 02:35 PM Share Posted June 14, 2012 at 02:35 PM 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. Quote Link to comment Share on other sites More sharing options...
batti Posted June 20, 2012 at 02:50 PM Share Posted June 20, 2012 at 02:50 PM Xenna, have you solved these strange EMI problems? Quote Link to comment Share on other sites More sharing options...
Xenna Posted June 20, 2012 at 04:45 PM Author Share Posted June 20, 2012 at 04:45 PM 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. Quote Link to comment Share on other sites More sharing options...
Xenna Posted June 21, 2012 at 03:29 PM Author Share Posted June 21, 2012 at 03:29 PM 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 Quote Link to comment Share on other sites More sharing options...
photron Posted June 22, 2012 at 02:36 PM Share Posted June 22, 2012 at 02:36 PM 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. Quote Link to comment Share on other sites More sharing options...
batti Posted August 10, 2012 at 11:22 AM Share Posted August 10, 2012 at 11:22 AM Any update here Xenna? We are currently discussing possible improvements... Quote Link to comment Share on other sites More sharing options...
Xenna Posted August 10, 2012 at 11:54 AM Author Share Posted August 10, 2012 at 11:54 AM 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. Quote Link to comment Share on other sites More sharing options...
batti Posted August 13, 2012 at 03:23 PM Share Posted August 13, 2012 at 03:23 PM Ok... That was not the answer I was expecting , but it's nice that you enjoy the tinkering... Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.