Jump to content

Xenna

Members
  • Gesamte Inhalte

    33
  • Benutzer seit

  • Letzter Besuch

Xenna's Achievements

Newbie

Newbie (1/14)

0

Reputation in der Community

  1. 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.
  2. Xenna

    Watchdog Feature in FW

    In the end I decided to do my safety in hardware. I got some cheap 555 timer ic's and rigged up a watchdog that would limit the relay activation to 45 seconds. For my application that works well and it almost completely prevents the software from messing things up. Almost, because when the software closes and opens the relay at a short enough interval I'd still be (literally) stuck. But the chances of that are probably very small.
  3. Xenna

    Number Pad

    I'm not that great with housings and stuff, so my ideal device would have a nice case around it. A number pad with arrow keys and an LCD screen, come to think of it, that would be EXACTLY like my house alarm system With a nice case so that you can easily mount it on the wall and control all your Tinker stuff with it...
  4. I think the best way to solve this is with something like closures (missing in C). I've done it in Python like this: AN_UID = { "pp1":"PP1", "pp2":"PP2", "pp3":"PP3", "pc1":"PC1", "pc2":"PC2", "pc3":"PC3" } # Analog IN bricklet UIDs per button ( label:UID ) # Note that I've renamed my bricklets to pp1..pp3, pc1..pc3 (in my case 6x Analog In). def button_callback( source, floor ): # Called when voltage drops below 0.1V def handler(voltage): print "button_callback(%s,%d,%.3f)" % (source, floor, float(voltage/1000.0)) if destination() > 0: control( 0, 'doublepress@' + source + str(floor) ) else: control( floor, 'buttonpress@' + source + str(floor) ) return handler # And then: for b, uid in AN_UID.iteritems(): print "0000: Setting up analog in bricklet %s: %s" % (uid,b) ai[b] = AnalogIn( uid ) ipcon.add_device( ai[b] ) setup_analog_in( ai[b], button_callback( b[0:2], int(b[2]) ), monitor, BUTTON_THRESHOLD, BUTTON_DEBOUNCE ) The source and floor variables are available in the handler when the callback occurs. So I've basically created 6 handlers this way.
  5. Mit zwei geht das nicht glaub ich. Zwei Tasten gibt 4 moeglichkeiten, aber die 00 moeglichkeit zaehlt nicht. Von drei Tasten kann man aber 7 Tasten machen und das ist schon sehr schoen. Bleibt mir nur noch die Wunsch dass Jemand eine schoene Hausung dafuer macht (und verkauft). Eine art Brick Bedieningspanel mit vier directionstasten und 3 extra Funktionstasten.
  6. Sah Gut, das werde Ich mal untersuchen...
  7. Ah, gut das dass schon mal besprochen ist. Ein 4e Taste wuerde fantastisch sein, aber Ich bedenke mich dass eine Menuoption 'Back' natuerlich auch moeglich ist, nicht so freundlich aber allerdings moeglich.
  8. Vorschlag an die TF Herren: Bitte machen sie fuer LCD20x4 v1.1 ein leichtere Anschlussmoeglichkeit fuer externe LCD-Tasten. Die Tasten die jetzt montiert sind sind so doch kaum nuetzbar? Ich glaube 4 Tasten wuerde besser sein, dan hat man up, down, enter und back, kann man schon ein ziemlich complexes Menusystem ansteuren. Also bitte Anschluesse fuer 4 externe Tasten
  9. 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
  10. 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.
  11. 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...
  12. 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.
  13. Something wrong with the forum. Posting fails most of the time. Picture:
  14. There's a difference between read contacts and reed relays. Reed contacts are just switches so they should work without problems on the IO16. I tried some and they worked fine. Reed relays are just small relays that use little power. I'm using 3 of them in my project. AFAIK the IO16 brick can supply 25mA per port. The reed relays I'm using (Conrad art. 504513) use only 10mA so they shouldn't pose a problem. I'm using them without problems even with a LED with a 330 ohm resistor in parallel. As far as mounting is concerned I just drilled some extra holes in a stripboard (Conrad art. 530173) and mounted the bricks and other parts on it. That worked pretty well although my soldering skills suck. Speaking of sucking: it's a good idea to buy a desoldering pump if you don't already have one. My project has 2 master bricks, 1 IO16 bricklet, 6 analog in bricklets and a temperature bricklet all mounted on one board with some screw terminals. I'll post a pic in a new message, last try posting failed.
  15. Well, I received my Raspberry Pi from Farnell this week. Actually my second, but the first one from RS Online was broken. It loses USB and ethernet connections after a few minutes after booting up. This one runs and keeps running. So I decided to try my brick(let)s on it. I use the standard Debian Squeeze distribution, installation of brickd was easy: apt-get install python-twisted apt-get -f install wget "http://download.tinkerforge.com/tools/brickd/linux/brickd_linux_latest.deb" dpkg -i brickd_linux_latest.deb brickd started without errors, good! Install python bindings: wget "http://download.tinkerforge.com/bindings/python/tinkerforge_python_bindings_latest.zip" unzip tinkerforge_python_bindings_latest.zip Copied source/tinkerforge to my project directory. Connected my Tinkerforge bricks. Everything seems to work!
×
×
  • Neu erstellen...