Offset problem with Makelangelo 2.5.2

[Valentin]

Hi,

I just bought my first Makelangelo (2.5.2) a week ago. I built it without any issues (great tutorial !). However, when I did the first tests, I had some problem with the software (7.3.2, built from sources because I could not make the official release to work).

First, the scale was not correct (130mm on the paper for a 100mm line). Changing the pulley size does not seem to change anything on the Makelangelo.. I only made it work on an older version of the software (Makeleangelo 5), where the settings seems to be taken into account.

I also have a small bowing effect but the board dimensions are correct (914.4mm by 914.4mm, as suggested in the tutorial). This may be the same problem as the pulley size (settings not sended/updated), but I did not really tested it.

I tried to draw some images : using pulse lines everything looked fined (except for the scale/bow effect), but when I used the crosshatch filter the drawing was totally shifted.
I did some basic tests :
here is the result of a simple Home > Top > Right > Home > Left > Bottom > Home > Bottom… test
Here the offset is around 1cm, but after many steps it increases more and more.

I use a 12V supply, I already changed it twice.. I don’t own any other stepper motor so I can’t try with another one.

Did I missed something ?
Thanks for your help !

[Dan]

Are you running the latest makelangelo-firmware?

My test rig here is a Makelangelo 2.5.2 and a Makelangelo 3.2, both with latest firmware and software.

From what you’ve written it sounds like you’ve done everything right. How much heavy are the counterweights?

[Valentin]

I used the last released of the firmware (https://github.com/MarginallyClever/Makelangelo-firmware/releases/tag/1.0.2).
I just tried with the code from the master branch, had to update the Arduino software to make it compile, but the problem is sill happening.

My counterweight are about 90/100g (plastic bottles with 2cm water). The pen holder is not weighted, I tried to add some weight yesterday but it didn’t changed anything.

I don’t really know what I can do now… If you need me to do some tests feel free to send me a gcode and I’ll send you the result back !

[Valentin]

After doing some more tests it appears that everything looks fine when it only do vertical and horizontal movements. When it does any diagonal movement it seems to shift more and more.

That’s why crosshatch filter produces glitchy images :
Horizontal pass works fine, then vertical pass is offset (about 1/2cm) but every vertical lines are aligned to each other. Then both horizontal pass are totally misaligned, as every line draw shift a little more.

[Valentin]

Then both horizontal pass are totally misaligned, as every line draw shift a little more.

whoops, I mean :
diagonal passes are totally misaligned*

[Valentin]

I did the same test two more times : Home > Top > Right > Home > Right > Bottom > Home > Bottom > Left > Home > Left > Top > Home

result 1

result 2

Looks like the offset is more or less constant between each draw.
But sometimes it looks like one of the motors slows down (see result 2 – bottom left to home line).

Then I swapped the motors and did the same test :
result with swapped motors

I still have no clue about what’s wrong in my setup and can’t draw any conclusion of these tests, but maybe it will help you to diagnose the problem…

Thanks again for your help

[Dan]

This is very strange, but you’re not alone. I’ve been working with DXF images that don’t draw correctly, when all other drawing styles seem to be fine. I can’t confirm yet if these are related issues, but they appeared on my radar at the same time.

100g/bottle is good, I’ve got the same.

[Valentin]

OK, so you think this is software related ? Or is it possible that the motors or the shield may be defective ?
Maybe I could try with an older firmware version ?

[Dan]

Try the dev version I have just published.

https://github.com/marginallyclever/makelangelo/tree/dev

[Valentin]

I assume you are talking about the dev version of the firmware code, right ? (here https://github.com/MarginallyClever/Makelangelo-firmware/tree/dev ?)

I quickly tried it because I don’t have much time now, didn’t re-calibrate or anything, but this is what I got with the same test :
result

Did I missed something ? Maybe I should also use the dev branch of Makelangelo software, but it looks like it has not been updated since January..

I’ll test it more in depth and keep you informed tomorrow when I’ll have more time 🙂

Thanks for your responsiveness.

[Valentin]

I did it a bit too quickly yesterday… please don’t take the result into account 🙂

So, I did the test again, still the same result : the same offset appears when doing diagonals, everything working fine when drawing horizontal & vertical lines.

I’ll try to dig a little more into the arduino code these days.

[Valentin]

Hi, some news :

I divided by two the speed of the motors (hard coded in the firmware, on setSpeed()), because setting the speed from the software does not seem to change anything (maybe I misunderstood how it works).

No more offset problem ! For the first time it passed the top-right-bottom-left test and came back to the home point without any issue 🙂

The motors are making much more noise, but I don’t think this is a problem.

I’m still having issues to calibrate the board : a 100mm vertical line measures 135mm on the paper, and a horizontal one 120mm… In my setting the pulley size is set to 12,7mm (I assume this is the size of the default pulleys from the kit ?) and decreasing it still does not works (the motors won’t turn, sometimes I got NaN exceptions).

But anyway, this is a significant step ! I’ll do more tests and keep you informed. Still have no clue why the default speed made the machine shift.

[Valentin]

Please, any news ? Can’t find a way to get the right scale on the paper, and the offset problem is still present, just less important (but any drawing of more than 5-10min is totally broke). Also tried with new motors, updated software & firmware, same problem…

[Dan]

I have a 2.5.2 assembled for sale in the kanban system. I will test it now and try to reproduce your results.

[Dan]

The news is that yes, there is something funny with 2.5.2’s latest firmware.

I’m sorry it’s taken so long to get to this. I’m looking into it more right now.

[Anonymous]

Hi – I think I’m seeing a variation of this same problem too.
I’m using a makelangelo 3.2 and I’m having a problem that any lines other than orthogonal ones seem to draw incorrectly. Orthogonal (pure X or pure Y) lines are drawn perfectly. For instance, the code below should loop around a rectangle twice and then draw diagonal lines between the corners; drawing the rectangle works fine, each loop around is perfectly registered with the last (you can’t even see the difference between the pen lines – magical!), but as soon as it draws diagonals the end point is mis-registered quite badly (by about 3 or 4 millimetres), and this mis-registration persists in subsequent drawing (though i suspect it could be undone by drawing a diagonal in the opposite direction – haven’t tried that yet).

; Calculated for motor width :1561.0
; height to mount bottle from floor :1022.5996525211551
M101 T110.5 B-110.5 L-78.05 R78.05 I1 J-1;
D1 L1.2732 R1.2732;
G92 X0 Y89.58657;
G90;
G00 F7000 A10;
G01 X-460 Y-20;
; loop 1
G01 X-460 Y840;
G01 X460 Y840;
G01 X460 Y-20;
G01 X-460 Y-20;
; loop 2
G01 X-460 Y840;
G01 X460 Y840;
G01 X460 Y-20;
G01 X-460 Y-20;
; loop 3 (with diagonals)
G01 X-460 Y840;
G01 X460 Y-20; // top left to bottom right
G01 X-460 Y-20; 
G01 X460 Y840; // bottom left to top right

(please ignore the unusual home position etc. in this code – it’s generated from my own software, but I don’t think any problems with that could be having this effect).

Given the precision that the code is able to draw X & Y lines i don’t think this is just a problem with the precision of motor control or floppiness in the mechanics. I suspect that the only reason this problem isn’t showing up more for other people might be that an opposite diagonal will counteract the issue (so it will mainly appear if you do single very long diagonals), and that two diagonal lines drawn next to each other will have the same problem so will probably still be parallel. Also, I think the fact that I’m drawing things at a much larger scale than normal is making the problem more obvious than it would be normally.

I’ll look through the firmware to see whether I can see any obvious cause, but is there a reliable version of the firmware I can roll back to?

thanks,
Josh

[Anonymous]

Yes, I can confirm that drawing a line in the opposite direction completely undoes the mis-registration and the system is perfectly registered again.

[Dan]

Huh!
Length of line affects amount of registration error?
Angle affects registration error?

This would explain why circle style works perfectly – if there’s any error it is cancelled out by doing a complete turn. It also explains DXF files are my least favorite – random lines in every direction.

[Anonymous]

Yes, I’m almost 100% that the length of line will affect the error. That test is using a line about a metre long so the error is several millimetres. This is probably an unusually long line for most drawings, so most drawings will be accumulating errors from lots of smaller lines, which will often cancel out. In effect, if you’re drawing lots of small lines you’re doing a sort of random walk of errors, so it’ll look as if the machine is just sloppy and inaccurate, when in fact it’s extremely precise.

I haven’t tested lots of different angles, but we could do that test. The error definitely does change with angle because it’s 0 for horizontal and vertical lines, and non-zero for 45 degree lines. I’m not sure how it behaves in between yet.

At the moment I’m suspecting that the culprit may be in the motor_line code. My instinct was that it might be something to do with the acceleration code, but I’ve tried running with different accelerations and it doesn’t seem to have a big effect.

[Dan]

I have looked for it in the past and no success yet.
I suspect there is a <= that should be < and it is causing an off-by-one error.

[Dan]

I wonder if this happens with firmware_ams. that would imply it’s an IK problem, not a stepping problem.

If you draw a triangle right 1m, down 1m, and back to home, you see the difference of a few mm, yes?

[Dan]

This is the first time I’ve had a test case that accurately reproduces the issue. Thank you, @jportway!

I modded the firmware to count the global total number of steps taken each direction.

> N4 G92 X0 Y89.58657   G0=0       G1=0      X0.00 Y89.59
> N8 G01 X-460 Y-20     G0=-57740  G1=138459 X-46.00 Y
> N11 G01 X-460 Y840    G0= 62715  G1=73643  X-46.00 Y84
> N13 G01 X460 Y840     G0=-73525  G1=-62597 X46.00 Y84.00
> N15 G01 X460 Y-20     G0=-138341 G1=57858  X46.00 Y-2
> N17 G01 X-460 Y-20    G0=-57740  G1=138459 X-46.00 Y
> N20 G01 X-460 Y840    G0= 62715  G1=73643  X-46.00 Y84
> N22 G01 X460 Y840     G0=-73525  G1=-62597 X46.00 Y84.00
> N24 G01 X460 Y-20     G0=-138341 G1=57858  X46.00 Y-2
> N26 G01 X-460 Y-20    G0=-57740  G1=138459 X-46.00 Y
> N29 G01 X-460 Y840    G0= 62715  G1=73643  X-46.00 Y84
> N31 G01 X460 Y-20     G0=-138445 G1=57884  X46.00 Y-2
> N33 G01 X-460 Y-20    G0=-57844  G1=138485 X-46.00 Y
> N35 G01 X460 Y840     G0=-73603  G1=-62675 X46.00 Y84.00

> N13 G01 X460 Y840     G0=-73525  G1=-62597 X46.00 Y84.00
> N22 G01 X460 Y840     G0=-73525  G1=-62597 X46.00 Y84.00
> N35 G01 X460 Y840     G0=-73603  G1=-62675 X46.00 Y84.00

n13, n22, and n35 are supposed to be identical but the global number of steps has changed.
I can now confirm and test for a very small counting error that is accumulating over time.
This is now my top priority.

[Anonymous]

Here’s a link to some photos of a test : https://goo.gl/photos/Qc2Rp2ettwzh38zU7
some thoughts :
Error increases as we go towards 45 degrees from 0 at 0 degrees to about 3mm at 45 degrees for a diagonal line about 93cm long.
at 45 degrees the line simply overshoots – ie. x&y errors are the same.
at other angles the X & Y errors are different

(ignore the wiggles on the small angle ones – the cable was catching on something, but it shouldn’t affect the results)

[Anonymous]

not sure why those image links didn’t work, but you can see the pictures if you follow the album link

[Anonymous]

Sorry – I made a mistake before; The angle that it actually seems to pass through the corner and overshoot isn’t 45 degrees, it’s about 37.6 degrees.

[Author]

Posts