Hi,

What's the state of the mega calibrate_doCalibration() routine? Is it working?

I've got endstop contact sensors like benden http://code.google.com/p/benden-drawbot/, but i'm using the calibrate_doCalibration() from the mega build. Benden's code isn't setup for AccelStepper().

calibrate_doCalibration() doesn't look like it's set up to be called from the interface(?), nor does it actually navigate to the home position.

My polargraph is finding both X_MIN and Y_MIN endstops for each motor but it not returning to a reasonable spot which suggests I don't fully appreciate what this code is trying to do. I believe the extra check to see if motorB is at the endstop is redundant, and I made a small change to move both motors so that the gondola moves straight across the top like benden's, because my drawbot is wider than high (and the default calibration code lets the gondola drop too far for my polargraph.

here's my current modifications: http://pastebin.com/mDVk3bd3 which has clearer debugging code IMHO, but still a work in progress.

-polarhb

Hi Sandy,

You commented on benden's work in this post: http://www.polargraph.co.uk/2012/05/homing/

I interpreted and implemented benden's endstops as follows.

The gondola carries springs that are on the incoming strings and connected to the servo's ground which goes to the Arduino ground.

Connected to each upper eyehook (on which the gondola string travels) is a single soldered wire. At the other end of the wire are two resistors soldered in the form of a "T" (so the incoming wire is the base of the "T"). One of the resistors is 100 ohms forming a pull-up going to a digital in on the Arduino. The other is a 10k ohm going to +5v on the Arduino. Normally this endstop reads high due to the pull-up, but if the spring on the Gondola hits the eyehook, it completes the circuit to ground, causing the endstop to read low.

The whole setup is duplicated for the other eyehook.

I could do a picture if that isn't clear.

Re calibration, when the process is finished (with my code) the gondola should return to a known point. But I haven't examined the code further (or even called polargraphcontrollers to see if the main code is using that position as the new starting position. The problem is that the when my motors release the gondola could be anywhere including often slackly laying too far down ( my polargraph is wider than high), so I need to do some final move to a reasonable starting spot .

Invoking it with a button would be a good idea. I'll wire it up. It'd be nice to calibrate without having to have the GUI active.

polarhb

my calibration is pretty close to working. but it's slightly off, and I think there's a possibility there's a conceptual rather than hardware or missed steps error.

my pseudocode:
release both motors
enable A (left)
home left until endstop X, call it zero.
enable A,B motors
travel right until endstop Y
call that zero for motorB.
now both motors know where they are.
figure out mathematically how long the hypoteneuse needs to be to put
the pen at (machineWidth/2,homeY), this is
d=sqrt(homeY^2+(machineWidth/2)^2)
move both motors to point d.

The ENDSTOP_X_MIN is the distance from where the endstop triggers (in my case, a spring on the string) to where the virtual pen tip would be. Same with ENDSTOP_Y_MIN (somewhat confusingly X,Y are the left and right motors and NOT cartesian coordinates).

.. and it almost works. but it's invariably about consistently/substantially below homeY (by as much as 20-50mm). I think the answer lies in benden's comment on re-homing back to left to take up 'slack'?

but I don't see why I would need to home left again or what role slack plays if both motors know where they are and their distance from the pen tip is known.

The pen is centering nicely even though it's off vertically which suggests that if it was missed steps they are identical left & right, which I think is unlikely. I corrected for the distance to the pivot point (the pen itself is slightly lower which we all agree does nothing but lower the drawing position from previous blog posts). Yet I still had to add a -7mm "fudge" distance to get it to come up to the right position, which obviously is machine dependent.

d=sqrt(homeY^2+(machineWidth/2)^2)-fudge

With the 'fudge', d is shorter so the hypotenuse gondola strings are shorter and the gondola moves to the correct position.

My auto-calibration now works and my drawings (at least from an 8.5x11 paper) are nice and square, distortion minimal. Since it now repeatably homes to this position, that suggests as well that it isn't missed steps.

I'd rest easier knowing where I'm off and fixing the math, which would obviously make the whole process machine-independent, but for now at least my machine calibrates nicely.

thanks for your help; i'm going to spend some time on it and see if I can get the math tight. I conquered several unusual reprap designs/issues; this should be doable!

here's the code i'm using today: http://pastebin.com/9FTHF3Er

-polarhb

That's a good idea. Magnet switch had occurred to me before, but now I can't think what the problem was with it. I was initially thinking of hall effect sensors rather than reed switches, but the polarity of the magnets mattered too much and I couldn't think of a way to ensure the S (or N) pole was always orientated towards the sensor as it went past. I guess if the magnet is strong enough, then it could be mounted in-line on the cord, and the switch could be tripped by one of the ends passing by, even if it was not pointed directly at the switch.

I think you're right. The hall effect sensors are very sensitive to polarity, but there's no reason why the reed switch should be. Skill, I will do some experiments.

Cheers!
sn