[Dan]

The time to update the screen is so long that the machine misses the clicks of the dial turning. I don’t have a quick fix. It is a known issue that I hope to get to in the new year.

[Dan]

What version are you running, please?

I’m looking in ImageManipulator and I see there is a Turtle (which remembers is pen up or down) and basically the same thing is being done – if there are a lot of moves while the pen is up they are ignored and only the last move before pen down is written to the file. Maybe I added that after your post? If that’s the case I apologize, I get so confused these days…

As an aside, I feel that the way the program evolved has reached a local maximum. Each of the generator/converters produces gcode directly, which is then read back in for drawing/transmitting. This is not great:

– can’t load multiple drawings at once
– can’t scale or translate after the fact
– have to reload drawings if you change machine settings
– hard to export drawings for other apps
– slow to render
– can’t combine effects (filters) to do fancy new stuff.
– can’t easily clip drawings to remove those travel moves/simplify.
– can’t accurately estimate the time to draw for any given machine type.

The Turtle system is one step towards generating an internal buffer of vectors that can manipulated to achieve all the above goals.

[Dan]

Try adjusting the value LCD_TURN_PER_MENU to a lower value.

[Dan]

I don’t know why it would be skewed.

You are certain you are starting in the right spot?

Are the pulleys tight on the motor shafts?

Are the belts slipping on the pulleys?

Is there numerical error in the old firmware? (doubtful)

[Dan]

> Somewhere the encoder is counting wrong.

What do you mean?

the place to look is in lcd.cpp. look in LCD_read(), where the encoder changes the value lcd_turn.

[Dan]

The Arduino code is here: https://github.com/MarginallyClever/Makelangelo-firmware/

You will want to setup right:
In configure.h, where you set the machine to POLARGRAPH and the board type to BOARD_RAMPS.
In robot_polargraph.h, check that the machine version matches yours (MAKELANGELO_5?).

ramps.h defines the pins used by the stepper motors and the LCD panel.
You can change these numbers and upload the code to your robot to reprogram the machine.

Sorry if this is pedantic, I’m writing for everyone who comes after you that doesn’t know how to join us.

[Dan]

in lcd.h, change

#define LCD_TURN_PER_MENU (3) // was 5

To a lower number. try (1) or (2). <=0 will not work.

[Dan]

@Aliakber we don’t currently have a nice way to do that. It has been an open ticket for a long time: https://github.com/MarginallyClever/Makelangelo-software/issues/223

[Dan]

Please make this code a github pull request so that everyone can read it and your name goes into the development history. You deserve recognition for your work!

[Dan]

Hi! there is very old firmware for UNO available here:
https://github.com/MarginallyClever/Makelangelofirmwareams

I don’t currently support it. I abandoned it because the UNO+AMS combo is SO SLOW.

If you make progress getting it to work with the latest software, please send a pull request.

[Dan]

makelangelo 5 is only one setting, it might not accept size changes.

I’m not sure why the left and right belt sizes would be 100x larger. D11 (reset all M5 values) should set them both to ~1011.

[Dan]

Those two lines do not look correct. dimensions sent to the machine should all be in mm.
that’s 350m left and 927m down. How big is your machine?! :O

[Dan]

in robot_polargraph.h, find

#define NORMAL_MOTOR_STEPS 200 // 1.8 degrees per step
//#define NORMAL_MOTOR_STEPS 400 // 0.9 degrees per step

If your motor is turning too far, then you probably need it to look like above.

The other way around your motors would not move enough.

[Dan]

Hmm… I don’t have this lcd screen, which makes it hard to test. It’s not an officially supported model.

[Dan]

Does java have permission to open a serial connection to your robot? It may be your OS security settings.

[Dan]

You are doing everything right.

Makelangelo can draw any line. Makelangelo software does not yet have the know-how to fill in a dark area with lots of lines.

At this time I don’t have a recommended way to fill in closed areas. The eggbot plugin for inkscape might be able to add lines to your inkscape drawing but I’ve found it to be a bit iffy.

[Dan]

your calibration needs work. if you are certain the distance between motors is correct then your home position is probably too high.

[Dan]

show a picture so i see what you mean, please.

[Dan]

2. so when the servo moves, the machine reboots? That’s weird.

[Dan]

“BADCHECKSUM 12” means the 12th instruction (the line starting N12) was not received correctly. Checksums prevent corrupted messages that do weird things. It’s not too bad when the 3rd decimal place is lost. It’s awful when the entire decimal place is lost.

[Dan]

1. what about a long click?

2. “up over the paper”? what kind of loss – does the machine reboot or does a cable disconnect?

[Dan]

According to this thread https://forum.arduino.cc/index.php?topic=556921.new#new
Everything should be the same but one of the connector is physically rotated 180 degrees.
Does that make sense? It could just be you have a cable backwards.

[Dan]

No, no idea.

[Dan]

@Phi Le,

There is some firmware code for the Wemos D1 D2 but I cannot guarantee it will work. I would need these boards to test.
Software should work if firmware works.

[Dan]

> I have a problem with my properly working Makelangelo

What you have is a DIY polargraph, not a Makelangelo. We test all our machine before they ship.

3) one motor is turning backwards. With power off, reverse the wires for the right motor. if that’s the wrong one, the image will appear upside down and backwards. if it is the correct one the image will be right way up.

124) Get the latest version of the firmware from github:
https://github.com/MarginallyClever/Makelangelo-firmware/tree/dev
I’ve made improvements to the menus that should make the menus more responsive.

[Author]

Posts