Forum Replies Created
-
Posts
-
Hi Bud,
I apologize for the slow reply– I was busy in another thread. ;)Our usual strategy is to loosen the screws that hold down the cable guide at each end, and to angle it upwards– up out of the carriage, and up out of the cable guide support on the frame, before re-tightening those screws. However, it sounds like the root issue was the rough edges on the cable guide. We rejected some that we caught with rough edges, but it sounds like some got through anyway– and I am sorry for the trouble. If you’d like a fresh replacement cable guide, please contact us directly by e-mail.-WindellHi LongArc,
I spent so long on that first reply that your first and second comments came before I had a chance to reply. I’m glad that you’ve got it working!Hi Sha,I’m sorry to hear about the difficulties. There are several different issues here, and we need to work through them one at a time.First off, I’d suggest putting away the paint, water, and paper until you can tell that the machine itself is operating correctly. The robot is not yet configured correctly until the motion is clean, smooth, and without any “stuttering” type behavior of any sort.There are two different behaviors that might be described as “stuttering”: One, which we call “cogging” is where the motor tries to turn but cannot and jumps from one position to another. The other, which we call “stuttering” or “chattering” is where the motor is turning properly, but the carriage is undergoing stick and slip type vibration as it moves along the rod(s). The latter can be annoying, but is not generally harmful (although it can cause the bushings to wear out prematurely), and is most likely caused by not having the two rods fully perpendicular. However, what you are describing– where the motor loses position — is cogging, and is much more serious.Now, onto fixing the problem.Unplug the bot (both USB and power), and turn the winches by hand— one at a time —to move the carriage to the home corner, and then to the opposite corner. As you go, check the following:(A) Is the spectra cord properly routed around the three ball bearings, riding in the groove?(B) Are both rod ends fully square to the frame (up against their stops, without any gaps) at each end of travel?(C) Is the motion clean, smooth, easy, and without binding of any kind?If the answer to all three is a resounding “Yes, absolutely, positively!”, then your robot is mechanically set up correctly, and you likely need to adjust the motor current. (Skip down this text until you get to the part that says “If you need to adjust the motor current.”)Otherwise, we need to work on the mechanical part.Begin by turning the winches by hand to move the carriage to the center of the frame. Remove the rods from the carriage, by lifting up the rod end sliders and pulling the rods out, sort of like you did at the beginning of assembly step 28. Leave the carriage attached to the robot by its cable guide, but set the carriage out of the way, for example on your table behind the frame. Re-install the rods.Next, move the winches by hand, returning the two rods all the way left and back, as though you were moving the carriage back to the home corner. Starting with the Y axis (motor 2 and its cord), check that the string is routed correctly over the entire path,as described in steps 15-18 of the assembly instructions. In particular, follow along with the numbered arrows on the frame, and make doubly sure that the cord is still laced into the grooves of the two ball bearings at arrow positions 3 and 6 on the WaterColorBot frame. Next, check that the rod ends are absolutely, positively square to the frame (without any gap, as shown in step 20). (If they were not square, then that would certainly cause the cogging that you had.)Turn the Y winch by hand, all the way to the end of its travel and back. The motion should be clean, smooth, easy, and without binding of any kind– much like an Etch-A-Sketch. (Your daughter should be able to turn it!) If you have enough tension, the cord should will still be laced into the grooves of the ball bearings. If you have too much tension, the motion may have too much friction, and won’t give that smooth motion that you need. In practice, the amount of tension is pretty forgiving, up to those two limits. Finally, after moving the rod to the end of its travel and back, check again that the rod ends are square to the frame.Then, repeat these steps for the other axis, and finally re-install the carriage.If you need to adjust the motor current…First, be sure that you need to. *DO NOT* adjust the motor current unless you’re sure that (A), (B), and (C) above are true. Then see our troubleshooting guide about how to adjust the motor current:As for the other issues– black paint and so forth — please get rid of the cogging first, and then try to describe to me what the current behavior is, and I’ll do my best to help from there.The Hatch Fill extension is without question the best method to use for text. We also describe some other methods of filling regions, here: http://wiki.evilmadscientist.com/Creating_filled_regions
Possibly the same issue as this: https://github.com/evil-mad/robopaint-rt/issues/15
If so, you’ll be able to run from source, but not from the standard distribution. I’ve uploaded a new test version that you might try, linked in that thread as well.I would too. ;)
To clarify a bit: When we talk about “cogging,” we are referring to cases where the motors are effectively skipping big steps, and losing track of where they are supposed to be– for example if the carriage does not return to the home corner (but goes elsewhere, or only partway back) when you ask it to.
In the video, there is some “jerky” motion, but it doesn’t look like any steps are being skipped. Rather, it just looks like it’s getting input slowly. If you’re seeing this in RoboPaint RT (which is Java based), you may be running up against the speed of the program on your computer. Two things you might try: Press the numbered keys on your keyboard to change the speed (1-9), slowing it down a little, and try sketching the drawing first, with the pause button selected, and then resume, to let the robot paint everything at once.The SVG images that StippleGen saves are pre-formatted to be used with the Eggbot, but it’s straightforward to use them with the WaterColorBot instead. Note, however, that stipple drawings look great when drawn with a pen, and not very good when drawn with a (presumably much broader) paintbrush.
We would *recommend* printing this kind of picture from within Inkscape, rather than RoboPaint, as it is better at handling complex SVG data of the sort that StippleGen produces.If you’re going to be printing from within Inkscape, open the WaterColorBot template, and then use the File>Import option to open up the SVG file. Select the object that was imported, and move it (drag it) onto the center of the page. If the drawing fits onto the page, it is ready to print. If not, you may need to resize it a bit.And, to draw with a pen, select Pen/Pencil mode from the Mode tab of the Control WaterColorBot extension.We have not actually tested printing StippleGen output in RoboPaint, but it should be possible (in principle at least). Go to the Create mode, and select File> Open SVG, and select your SVG file. Click the “Fit Content” button to move your drawing to the center of the drawing area, and it should be visible.To draw with a pen, go to the Settings> Painting Setup tab and select Painting/Drawing mode “No water or paint.”Hi Chris,
I’m glad to hear about the (partial) success– and we’d love to help you get the rest of the way there. :)We have generally found that when a WaterColorBot is correctly tensioned for the first time, it will need to have some additional slack removed after about an hour of use. But after that initial stretch, it will stay tensioned correctly for months on end. So, after running for a bit, check that the rods are square to the chassis, and take out the excess slack in the cord, and that should be *most* of the fine tuning that you need.If the cord is correctly tensioned and the rods are square, you should be able to turn the winches like knobs (with the power off), as though it were an Etch-a-sketch, or perhaps a bit more easily. The cords should be tensioned enough that they can be plucked like a string from a stringed instrument– such that they vibrate in place, rather than fall down listlessly. If it is too loose, the cord may fall out of the grooves in the bearings. On the other hand, it shouldn’t be so tight that it sounds like a guitar or violin string– if it’s too tight, that could increase friction and prevent motion.If it’s “stuttering” — I imagine the same thing that we call cogging (jumping steps on the motors) — after checking that the cord is tensioned correctly, then please read through our troubleshooting section about other possible causes: http://wiki.evilmadscientist.com/WaterColorBot_TroubleshootingYou should definitely not lubricate the rods unless you are finding corrosion to be a significant issue. The bushings are self-lubricating.In the picture, it looks like the effective brush width is increasing as you go along, suggesting that the paints are getting wetter and wetter as you go. I’d suggest pre-wetting the paint dishes with a drop of water each, and perhaps raising the brush up slightly, so that it isn’t pushing down quite as much.Hi Fletcher,
Thank you again, that is very helpful (and confirms that the “crash” bug is in fact a known text-handling bug in the latest Inkscape version).I am sorry for the continued trouble with the Eggbot connection; I’m not yet sure what the issue could be, but I will look into it further. We are not having any trouble connecting here from Windows 8.1, and should be able to (and in nearly all cases, does) find the port automatically.On the forum issue: I’ve just updated my Windows machine to 8.1 so that I can get a look at this for myself.OK– thanks! Very interesting!
If the “Name Poem” too is crashing, then this likely isn’t a machine control issue, but could be a matter of text handling (or something similar). We do know of a related issue, specific to Inkscape 0.48.4, that was causing a similar crash on Linux, but we have not heard of any trouble on Windows.Two things that you could try at this point:1. Download and (manually) install this updated version of our extension: https://code.google.com/p/eggbotcode/downloads/detail?name=eggbot_2013_08_11_2.3.4.zip To manually install the extensions, copy the contents of the ZIP archive to (Program files)Inkscapeshareextensions2. Try the previous version of Inkscape, 0.48.2, which is available for download here: http://sourceforge.net/projects/inkscape/files/inkscape/0.48.2/ (Note that if you re-install Inkscape, you will need to re-install the Eggbot extensions as well.)If either of these fixes does allow you to operate the Eggbot without crashing, we’ll update the installer accordingly.Hi Fletcher,
I have heard of a similar error twice before– neither in the last 12 months –and I wasn’t able to get any debugging information about what could have caused it in either case. So, I am sorry for the trouble, and you very likely aren’t doing anything wrong, but have some kind of rare configuration that somehow conflicts with either Inkscape or serial communications through python.Here are a few things that you might try, that might help point us towards a solution:* Please see if the error persists if you try to plot a blank document to the Eggbot.* See if other (default) extensions are working correctly. One way is to select Extensions>Render>Gear and click “Apply,” and see if that works correctly.* See if other Eggbot extensions that *do not* talk to the Eggbot are causing a crash as well. Select Extensions>Eggbot>Strip Eggbot Data, and see if that crashes.Also do you happen to have a custom Python version installed on your system, and/or have you changed the system %PATH% variable in a way that might affect Python use? Inkscape ships with a private copy of Python which usually gets called (in a separate process) when a Python-based extension (like ours) is executed.
imatool,
Yes, the Art Controller can be triggered by any low-going signal. However, that is a term that has a specific meaning, and if you cannot provide an appropriate input, then it will not work correctly.> If a buzzer makes a sound it is getting a valid signal.Yes indeed, but you need to remember that the buzzer is getting a valid signal for driving a buzzer. That does not mean or imply that it is getting an appropriate (or inappropriate) signal for anything else. A buzzer requires a specific type of input, just as the Art Controller does.>I also purchased the art controller for reliability. I really don’t want to slightly manage it.
Then you need to provide enough power to operate both kits, and a common ground reference between the two. From what I can tell, the 5 V on the Art Controller does not provide enough power to operate both it and the clock kit. And, a single-wire connection is never capable of providing a true “low going signal.”> Apparently this is not a forum that is monitored by company tech support. Maybe I should contact them directly.With all due respect, the person that actually designed the product is here, directly answering your questions, and trying their best to help you through an issue. Neither dismissing me nor saying that “nothing works” will help move towards a solution. I have made some specific suggestions that you are welcome to take, and if you would like additional help with debugging this application, I am here and willing to help.Hmmm… Well, I’m not sure exactly what happened, but I’m glad to hear that it is working now. :)
>What little I know about them, you are saying that the capacitor will act to collect voltage and smooth out the signal which might trigger the art controller?
No, not at all. Just that if you can’t provide a valid DC signal, you might be able to provide an AC signal that will slightly manage to trigger it.
