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.

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.

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

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.

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.

Sah Gut, das werde Ich mal untersuchen...

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.

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

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

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.

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

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.

Something wrong with the forum. Posting fails most of the time. Picture:

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.

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!

Would like to share your your Python script with us? espaecally for those like me which like to play arround with webservices. (but somebody of the admins said, perhaps the php bindings could be released next week.) greets from germany... Chris I'm not ready to share my code, probably never will, but I distilled a small sample Q&D web service out of it that's probably more useful to you. This one allows a http request to retrieve the status of a temperature bricklet in XML. The request is in the form http://hostname:8888/temp/status Data returned is: <response> <temperature>20.50</temperature> </response> The Python code: #!/usr/bin/env python BRICKD_HOST = "localhost" BRICKD_PORT = 4223 WEB_SERVER_PORT = 8888 TEST_MODE = False from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_temperature import Temperature from twisted.web import server, resource from twisted.internet import reactor if __name__ == "__main__": ipcon = IPConnection( BRICKD_HOST, BRICKD_PORT ) # Create ip connection to brickd thermo = Temperature("6KG") ipcon.add_device(thermo) print "Listening on port %d" % WEB_SERVER_PORT class Simple(resource.Resource): isLeaf = True def render_GET(self, request): uri = request.uri cat,cmd = uri.lstrip( '/' ).split( '/', 1 ) if cat == 'temp': print "temp cmd='%s'" % cmd arg = cmd.split( '/' ) if arg[0] == 'status': request.setHeader( 'Content-Type', 'text/xml' ) s = "<temperature>%.2f</temperature>\n" % (thermo.get_temperature() / 100.0) return "<response>\n" + s + "</response>\n" # Convert to XML return "<html>Error</html>" site = server.Site(Simple()) reactor.listenTCP( WEB_SERVER_PORT, site) reactor.run() Comments welcome, I'm a Python newbie.

Dass waere super!

I remember it needing an extra restart on Windows as well..

I guess I had been looking for a reason to try Python, so that's what I did in the end. I got a control program running pretty quickly and using twisted I was even able to very easily convert it to a web service. So now I can control and monitor my project with PHP and/or Javascript/Ajax. Unfortunately I'm still waiting for my Analog In bricklets that seem to be stuck in the German mail...

I upgraded to CentOS 6.2 and (most) everything is working fine (except from my RAID5 setup that suddenly developed a split personality, but that's for a different forum. Brickd is humming away nicely. I would appreciate an RPM eventually, though, to make things 'official'.

Couldn't you fit two more on the usb connector side on the underside of the board? That would help a bit I can't help thinking there would be quite a few potential customers who would just want to connect lots of bricklets to their PC (I currently have no need for motors/IMU or Chibi bricks). If that could all be done through one master that would be great. If you need an extra master per 4 bricklets, at 29 EUR a piece your solution suddenly becomes fairly expensive.

For my project I need one IO16 bricklet and 6 Analog In bricklets. That means I also needed two master bricks to connect them. That seems a bit inefficient. (I hope I won't run in to problems with usb power) I'd like a master brick that has more than 4 bricklet connectors. The Grove system for Arduino has a base board with many more connectors: http://www.seeedstudio.com/wiki/Grove_-_Base_Shield And a mega board with even more than that: http://www.seeedstudio.com/wiki/Grove_-_Mega_Shield Alternatively for my project a multi-Analog bricklet In would have been nice. Perhaps a 4 port or 8 port Analog In bricklet wouldn't need to be that expensive? The chips are tiny, so they would seem easy to fit. I also wonder about the mounting kits. Am I the only one who thinks there should be 4 more screws per kit? (4 to screw the brick(lets) to the supports, 4 to screw the supports to something else) With all that said, I'm really pleased with the Tinkerforge bricks. I'll post a description of my project when it's all done.

Update: - I couldn't install libusb1 from these rpms - Instead I installed Virtualbox on a Windows machine - I loaded up the Centos 6.2 image from here: http://virtualboxes.org/images/centos/ - Installed the USB drivers for Virtualbox - Changed networking to bridged - Added the Master Brick to the USB filters And then it all went smoothly: - yum update - libusb1 was already installed - yum install python-twisted - yum install python-gudev - ./brickd_linux.py I was able to run brickv on the windows box and control my bricks via the brickd on the centos 6.2 VM. So it seems upgrading my server to CentOS 6.2 would seem the way to go... (it's good to know this in advance that it's going to work before going through all the hassle of upgrading my server) Install Virtualbox and mount the Centos 5.8 image on http://virtualboxes.org/images/centos/ . You'll be up in 5 minutes. Many other system images available. Great for testing!

I'll try installing one of those libusb1 rpm's, I'll report back if I get it to work. I guess it wouldn't be a big problem to upgrade to CentOS 6, which apparently comes with Python 2.6 if I can't get it to work otherwise.

I could do without the hotplug so that's no problem. Done that, changed the config.py in the brickd/src directory, same result: # ./brickd_linux.py nodaemon Traceback (most recent call last): File "./brickd_linux.py", line 30, in ? from usb_notifier import USBNotifier File "/usr/src/Tinkerforge-brickd-1836e39/src/brickd/usb_notifier.py", line 30 class USBNotifier(): ^ SyntaxError: invalid syntax My Python knowledge is virtually non existent. Perhaps the CentOS python version is not supported? Info: Python 2.4.3 (#1, Feb 22 2012, 16:06:13) [GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] on linux2 Or perhaps I just don't have the right USB library installed...?