Forum Replies Created
-
Posts
-
It should definitely still activate the start lever, even when the input guide is empty; that’s one of the critical tests that we repeat dozens of times. Let it sit for an hour or two and try again. :)
Sorry to hear about the trouble. The ball release wire is carefully tuned in length, so it probably is a good idea to let it warm up, adjust to room temperature, and so forth before worrying about anything. If the balls and brass pins are cold and condensing water, that could easily cause additional friction, so give it a bit of time.
Every single one of these First Edition kits is tested on (quite seriously) hundreds of balls worth of operations, to make sure that the ball release mechanism was “just so,” that every flip flop was working smoothly and that it was 100% reliable on every single function before it ships. It probably will not need much (if any) adjustment to get it to work well. Once it is warm, you may want to “exercise” the start lever and flip flops, gently, to make sure that nothing is catching anywhere.There are at least some code adjustments necessary, but I have not tested it, and I do not know if there are any major stumbling blocks that I had not considered. Obviously, the signature bytes and fuse bytes are different, but some register names have changed as well. You can read more in Atmel’s app note on the subject:
Yep. Potentially, the nine LED lines could be used to drive up to 9*8 = 72 LEDs through charlieplexing.
You probably can’t really drive 3 LEDs in series directly from each output.
The absolute maximum voltage for the microcontroller is 5.5 V; do not exceed that value. The actual voltage output may be up to 0.8 V below the input voltage, so you may get as low as 4.2 V output– only 1.4 V/LED. If this is the case, the LEDs may not light up at all, even without a resistor. On the other hand, the voltage drop on the output may be lower, so it’s possible that you’d get up to 1.83 V/LED, which may be enough to overdrive them. So, you are trying to match the 3X the forward voltage of the LEDs– a not very specific spec –to be less than or equal to the power supply, less the voltage drop of the microcontroller– a not very specific spec.You’re welcome to try, of course, but I wouldn’t guarantee that it would work.While that *is* true vector clip art, it isn’t actually “eggbot ready,” because of the way that it’s designed.
Try opening up the file in Inkscape, and looking at where the lines actually are. Select all, and then ungroup everything. If you look at how that drawing is made, all of the white parts inside the flower are actually white-filled regions on a larger back backdrop. To see how the Eggbot would actually draw it, select all, turn the fill type to “no paint” (none), and select a consistent stroke width, say 1 px. Then, you’ll see all the same hidden lines that the Eggbot will.
It is possible to “fix” this, by going and deleting all of the hidden lines (and Inkscape has some pretty neat “boolean” tools that can help) but clip art is never a “sure thing.”The example on that page is not actually a vector, so I can’t say whether or not the “real” version is suitable. You could certainly trace it, if it is not already true vector art.
Thanks for the feedback on the capacitor– we’ll take a look.
You are welcome to post code here, and this is a good place for discussions. :)OK, great– thanks! I’ll mark this one as the “featured” installer. :D
As for the version number, it probably should have been updated, but was not since (IIRC) only the “extra” extensions and the installer itself were updated.Please try this version of the installer, which was created specifically to solve this issue, and let me know how it goes:
(If it does not work, I have a workaround that is known to work, but I’d really prefer to verify that the new installer solves the issue.)I’m sorry to hear about the trouble.
We’re currently using really nice Cree brand red LEDs in our RGB Bulbdial Clock kits, and we have (at least until now) always found them to be of exceptionally quality and consistent in all of their important properties, including orientation.We have checked the remaining LEDs that we have in stock– which we believe are from the same batch –and they appear to be correctly, and consistently manufactured. It seems *extremely unlikely* to us that there could be a manufacturing error of that magnitude that would affect only part of the batch, especially from this brand.The Bulbdial assembly instructions indicate a very specific way to identify the polarity of each LED in the kit: to look at which lead is longer, and our LED bending jig is specifically labeled that you should use it this way. The flat is also a generally reliable indicator of polarity. However, the internal leadframe shape is *not* a reliable indicator, and is indeed different between the red LEDs and the blue/green LEDs.The pattern that you are seeing is also consistent with having the red LEDs installed backwards; the classic sign of a backwards ring is that they light up in pairs. So, as a first step, you need to fix that issue.Then, you’re back to the initial problem, which is that the LEDs weren’t lighting at all. There is likely some other soldering issue that is causing this problem. The most likely cause of this kind of problem is a bad connection somewhere between the microcontroller and signal line LED10. It turns out that the most *common* cause of this exact problem is that people forget to install R10– any chance you skipped that step on your faster trip through the instructions on this round? If it is there, double-check the soldering at resistor R10, on the vertical jumper LED10, and on the corner pin of the microcontroller, close to D15.>My son is extremely disappointed.
I would think that this would be good motivation for you to look a little harder and figure out what the problem is. This is a very simple circuit, and there isn’t much that can go wrong.– If it was left on for more than a few tens of seconds with the pins connected together, it may have drained the batteries pretty well. Try swapping in a new set, to see if that makes a difference. If the circuit was getting hot when it was turned on previously, it’s also possible that there’s actual damage to the circuit board or components.– Check very carefully to make sure that there are no remaining “solder bridges” or other short circuits. If you have other solder joints that look blobby, cracked, or dry, you should probably touch those up again. If you like, you could send us a picture of the bottom side of the board, and we could help you find what else might be wrong.– Double check that the chip is inserted with the correct orientation, and that the battery wires are soldered with the correct polarity, too.– If you have an extra LED in your kit, you can touch the leads across the leads of the LEDs on your circuit board, to see if it lights up. If it does, you may have inserted the LEDs backwards.Please let me know how it goes.Well, that is good news– I’m glad to hear that *at least* the hardware is okay.
(Again, I’ll hopefully have more time for Eggbots and setting up a testbed once our holiday rush is over– we’re in full-on production mode on the Digi-comp, working 20 hours a day or so.)I wonder if you could possibly run some debugging tests on your machine, by making modifications to the Eggbot Control python script, to hopefully narrow down what the root cause might be. It could be an issue having to do with pyserial, or perhaps there’s an actual bug in our code that’s causing it. Have you had any experience with python?Try changing the speed settings on the programmer; you may be trying to send the data too quickly.
There are two available PWM pins specifically for driving LEDs. One is the standard nightlight, D2, on OC2B. You can use the “nightlight” function to dim it– see the “sleep” nightlight mode for an example of how to do this.
The second one is D1, on OC2A. There’s normally no LED here, so if you want to add a signal to drive a big LED, this is a good place to do it. Or, put it at location D2, so you can use the nightlight code directly.
