[Dan]

does your raspbian run java? Please list your steps. I haven’t tried running of a Pi yet.

I was thinking of skipping straight to a NodeMCU.

[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?

[Dan]

Please

– move AFMotorDrawbot, Adafruit-PWM-Servo-Driver-Library-master, and Adafruit-Motor-Shield-V2-Library-master from your libraries folder to your desktop.
– restart arduino
– recompile the sketch
– if no error, move Adafruit-PWM-Servo-Driver-Library-master back into the libraries folder and try again.
– if no error, move Adafruit-Motor-Shield-V2-Library-master back into the libraries folder and try again.

This way you will find which one is the problem. You should not need AFMotorDrawbot in the libraries folder since Arduino 1.6.7

[Dan]

What I need is a test case that doesn’t take 20 minutes. It’s very hard to isolate and fix this issue.

[Dan]

https://github.com/MarginallyClever/Makelangelo/issues/165

I’ve created a bug report, and I’m looking into it. I tried the only rounding method I know of in the code, but it didn’t make a difference. I can confirm the bug is repeatable and consistent.

[Dan]

Very strange. I would think the increasing number of steps would increase the errors. that means it’s not error/step, it’s very likely the rounding error you suggested.

DXF files make more pen-up moves than the other drawings. Maybe related? I don’t know why, moving with pen up is exactly the same as moving with pen down.

[Dan]

Hrm. I believe you.

I don’t believe it’s DXF related. the DXF loader turns the DXF file into Gcode, and from then on it’s treated like all other drawings. The problem should be happening to all drawings.

I need a simplified test case that demonstrates the problem. A 20 minute drawing is too long, and it’s hard to see where the error begins. Would you have some Gcode that does that?

[Dan]

You’ve done something to your setup. I can’t tell what from your explanation.
Try to start again fresh. I believe you have an arduino/library that you don’t need, and it’s breaking things.
maybe it’s an old version of the Adafruit motor shield library *from adafruit*, which should also be updated. (It’s not used by our code but the names are similar and it could cause a problem.)

[Dan]

in #8954 I said there were changes made for 1.6.7. Your post above says you’re using Arduino 1.6.5. Please update your Arduino and try again.

[Dan]

View this post on Instagram

#r2d2 from #starwars on a #makelangelo 3.2 from Marginally Clever Robots. 7889 lines in 16m48s

A post shared by Marginally Clever Robots (@imakerobots) on Feb 16, 2016 at 2:46pm PST

I think I put too much water in the bottles, it’s pulling the pen up a little bit over time.

[Dan]

Neither. In fact, you don’t need to copy anything to the arduino/library folder any more.

firmware_ams.ino is the file you should open and upload.

If you are following our recipe for building a Makelangelo then the only thing you need to change is the MOTHERBOARD.

If your steppers are not moving, you probably have crossed wires. The coils in the stepper will fight each other and you will get a vibration, at best, and nothing, at worst.

[Dan]

Arduino 1.6.7 made changes that broke the code. Please read the latest makelangelo-firmware to see the changes we added that fix this problem. The github diff will be especially useful.

https://github.com/MarginallyClever/Makelangelo-firmware/commit/778525a3bb7a479545018a91e8279dc08f29d094

[Dan]

View this post on Instagram

Identically labelled parts from the same supplier. Both say 20 teeth. One has 18. #wtf #supplychain #alwaysdoublecheck

A post shared by Marginally Clever Robots (@imakerobots) on Feb 16, 2016 at 12:53pm PST

Oh, wow. Now I have to recount every tooth on every pulley in stock. Time to make a one-off robot to count them for me?

[Dan]

I finally tried the DXF. The code is fine afaik.

Belt is skipping off the pulleys here, but I’m using an older model motor mount at the moment.
Tomorrow I’ll assemble some of the newer mounts and try again.

[Dan]

The maximum feed rate for AFMS boards is less than 1/3 the top speed of the RUMBA boards. That was a big part of why we made the v3.

The Arduino talk to the shield, which then sends stepper commands. To get straight lines it’s

Arduino > I2C language > shield > motor

every step. Converting to and from i2c is the bottleneck. The RUMBA is

RUMBA > motor

every step, and the speed it can talk at is faster (because the clock is faster).

There are ways to say “take N steps” instead of just one step, but then the code for AFMS becomes something different. I try to not break things that already work, so I haven’t explored this option.

I am eager to hear how anyone else has improved their top speed.

[Dan]

No need. Ask for Dan, Steve, or Kevin.

[Dan]

Hi!

Saturday mornings at the Vancouver Hack Space (1715 Cook Street) are the 3D printer group. They build, fine tune, discuss, and print. The perfect place to get all your answers at once. Many are Marginally Clever customers, and we support them with products and technical help.

Officially they are there 11:00-13:00. This morning I am there from 09:30, in case you want to come early.

See you there?

[Dan]

I’ve just pushed github commit 778525a3bb7a479545018a91e8279dc08f29d094 to https://github.com/marginallyclever/makelangelo-firmware

It compiles without error. Does it run OK for you? I don’t have a AFMS2 setup to run right this second.

It looks like now 1.6.7 will read the libraries from the install folder. That means no more installing a library to get Makelangelo to run. Easier!

[Dan]

Please post the entire error message.

[Dan]

That would depend a great deal on the weight of the people and the force they apply when dancing. I imagine a waffle of material with lights in the holes, and then a clear dance surface on top of that. Perhaps a single thick sheet of material with pockets cut in the bottom side for wires and lights.

I don’t have enough material since to definitively answer this question…but i wish I did! It’s a great question.

[Dan]

PWMServoDriver is new to me.

Please check that the start windows batch file contains the right name for the .jar file.

[Dan]

I think I found it. Pause() lifts the pen if it is down. unpause() puts the pen back if it needs to. In some cases unpause() was called when pause() was never called. The “was the pen down when we started pause?” test is now wrong, because we never paused, and the pen would lower. This happened every time Halt() was called – right after gcode is loaded, and right after a drawing is finished.

So it’s a minor fix, and will be in the next release.

Now I try your R2D2 DXF.

[Dan]

I ran this test repeatedly and did not get any deviation.

View this post on Instagram

Do this 50 times for a repeated accuracy test.

A post shared by Marginally Clever Robots (@imakerobots) on Feb 4, 2016 at 12:18pm PST

After 10 back and forth’s I still had only one dot on the board. If there was drift it would have been anything but.

[Dan]

Please try this gcode and send me a picture of the results. It should draw a series of dots that demonstrate the drift. Does it happen if you go to the top left instead of the top right?

G90;
G0 Z50;
G4 P50;
G0 Z90;
G4 P50;
G00 X100 Y100;
G00 X0 Y0;
G0 Z50;
G4 P50;
G0 Z90;
G4 P50;
G00 X100 Y100;
G00 X0 Y0;
G0 Z50;
G4 P50;
G0 Z90;
G4 P50;
G00 X100 Y100;
G00 X0 Y0;
G0 Z50;
G4 P50;
G0 Z90;
G4 P50;
G00 X100 Y100;
G00 X0 Y0;
G0 Z50;
G4 P50;
G0 Z90;
G4 P50;
G00 X100 Y100;
G00 X0 Y0;
G0 Z50;
G4 P50;
G0 Z90;
G4 P50;

Edit: changed P1 to P50 because it’s milliseconds, not seconds.

[Dan]

The most relevant code would be in these two places:

The bit that turns pulley diameter into ammount-of-belt-move-per-step:
https://github.com/MarginallyClever/Makelangelo-firmware/blob/master/firmware_ams/firmware_ams.ino#L227

The bit that turns (x,y) into (belt lengths left, belt length right):
https://github.com/MarginallyClever/Makelangelo-firmware/blob/master/firmware_ams/firmware_ams.ino#L309

They are identical in both the AMS firmware and the RUMBA firmware. Nothing obvious jumps out at me (like a nasty rounding error). Those blocks of code have not changed in a loooong time.

My guess is that the newer compiler that comes with Arduino GENUINO is doing something funny.

[Author]

Posts