Dan
Forum Replies Created
-
Posts
-
yes, three amps is enough for the kit we make.
All three are treated the same, motor agnostic. None of our other customers have reported a similar issue.
I will pull down a ready-to-go kit and see if I can repeat your results. Do you have a gcode example of a test you are running?Also check your PS has enough amps.
An M3x16 screw through ball joint, the arm, and then a nut. the ball should be on the side AWAY from the base of the platform. do the same thing at the top.
If everything moves double then I would suspect the stepper motors are 200 step per turn – they move 2x more per step than the model we use.
Because the v2 ships fully assembled we have no plans to release v2 instructions. When a v3 is built we would make the v2 fully open source.
Where did you obtain the laser cut parts for the v2? To my knowledge we have not released those files.
What values are you setting, what values are you seeing?
Defaults are 50 degrees for pen down and 90 degrees for pen up.One quick fix would be to test 90 pen up, then physically remove the horn and place it at the right angle. After that everything should be fine with default settings.
configure.h should be in the firmware_rumba/ folder.
AFMotorDrawbot.h should be in the firmware_ams/ folder.
If you don’t see them there then you’ve done something unusual when copying the files to your computer.
I’d need more information to hazard a guess. I don’t know why you can’t update Java or which exception has occured.
It should keep sending >. The fact that it does not is a problem. Maybe disconnect the servo and see if that makes it better.
Yes, on the serial monitor. Also in the advanced window (minimized at the bottom of makelangelo software)
servo? possibly.
The software is sending commands to the robot but the robot is not saying “I finished, give me more.”
The robot should send back “> ” when it is ready for more.We don’t officially support AMS2, it’s a pretty slow board so we never bothered. IIRC some features appear in code because dedicated DIY users sent in the code.
You should not have to change M1_PIN or M2_PIN. There is no support for limit switches in the AMS 1 or 2. We tried that in the past and could not make it work reliably.
It looks like your version of arduino can’t find the firmware_ams/Adafruit_MotorShield/Adafruit_MotorShield.* files. This is a problem since Arduino ~1.6.7. Move the Adafruit_MotorShield.* files to the firmware_ams/ folder and change
#include "Adafruit_MotorShield/Adafruit_MotorShield.h"to say
#include "Adafruit_MotorShield.h"Somehow AFMotorDrawbot has been added to your Arduino libraries, tho it should not be. Please delete the
/Users/austinredman/Documents/Arduino/libraries/AFMotorDrawbot
folder and its contents.
Please get the latest firmware from the website. I moved files to solve this problem for you.
take the
documents/arduino/makelangelo-firmware/firmware_ams/AFMotorDrawbot/AFMotorDrawbot.*
files and move them to
documents/arduino/makelangelo-firmware/firmware_ams/AFMotorDrawbot.*
If I make the driving buttons larger the context-sensitive menu on the right must become much wider.
Unless I’m missing something. Can you draw me a picture of your ideal interface?Once the robot is homed the manual driving buttons will move fixed amounts around the paper.
There’s also the power to type GCODE commands directly to the robot in the advanced window at the bottom of the app (might be minized at start).
Are you asking for a scratch-like system to make loops?
If your rectangles are appearing “smile” shaped then I would suspect your home location is different from the software’s assumption.
The next likely culprit is the software settings are wrong – perhaps the software setting for measurement from motor to motor does not match reality.
Different pens change the center of mass and create the tipping problem.
One method is to adjust the belt position on the long screws at the top of the pen holder. This should fix the tilt and get better contact on the glass.
Checked in a fix for both firmwares that eliminates C++ error by typecasting pointers to long.
./ means “this folder”. In this case, I assume you are looking at [some drive]/[some folders]/firmware_ams
Reasons the image would be small:
– incorrect machine size
– incorrect pulley size (pulley 2x larger than reality = 0.5x desired picture size)
– incorrect number of motor steps per turn in firmware (should be 400)
– incorrect number of microsteps in firmware (should be 16)
– electrical failure (poor connection causes missed steps. motion non-repeatable)
– mechanical failure (belt slipping on pulley, pulley slipping on motor shaft. motion non-repeatable)If none of those check out, post your log file, please.
3.2 RUMBA is correct.
What is your paper margin setting? When you first load the program, you can see a faint grey rectangle on the simulated paper. If the rectangle matches your results, that’s the issue.
Next I would check your pulley size. The pulleys on the 3.2 are all 20 tooth GT6 belts. I hid the option to change the number because who needs it? It’s a never-changing factory setting.
If none of that helps, send me a picture please. Maybe I don’t understand the results you’re getting.
You could follow the steps in the github wiki and then compile it for yourself. After the first roughness it’s as easy as git update, run latest. And I mean latest nightly build, as fast as anyone can check in the changes. If you’re brave enough to build a custom machine, the next logical step is to participate in the software development.
Send me an email and I’ll send it to you personally.
