[Dan]

Following instructions here I was able to install Java 8 and run Makelangelo.

https://www.digitalocean.com/community/tutorials/how-to-install-java-with-apt-on-ubuntu-18-04

I used the command line and ran the following:

/usr/lib/jvm/java-8-openjdk-i386/jre/bin/java -jar Makelangelo-7.20.1-with-dependencies.jar

You may find that the path name is “java-8-openjdk-amd64” instead of “java-8-openjdk-i386”. It depends on the processor in your computer.

Does that help?

[Dan]

to be clear, I don’t HAVE to save to a file first.

There is a temp file created when the image is generated, and it’s the exact same as one you would save to somewhere more permanent.

[Dan]

If I save the gcode of a drawing to a file and open that file in a text editor then I can surf to any line number.
Now say I’m drawing a picture and in the middle USB gets disconnected or something.
I can use “start at line #” to begin the drawing at that line in the file.

[Dan]

The instructable firmware instructions are probably out of date. Try this:

https://mcr.dozuki.com/Guide/How+to+update+Makelangelo+firmware/4?lang=en

[Dan]

Eh… Fair warning, I have never run the app on linux.
From the error message it seems that OpenGL is failing for reasons that aren’t clear to me.
You are running X11… Do you have the opengl drivers installed for your device?

I googled “Inconsistency detected by ld.so: dl-lookup.c: 111: check_match: Assertion `version->filename == NULL || ! _dl_name_match_p (version->filename, map)’ failed!”
and found a thread where someone is saying they have problems with JDK11, too.
Maybe try Java 8? https://www.minecraftforum.net/forums/support/java-edition-support/2931149-cant-launch-on-ubuntu-18-10

[Dan]

you’d need a way to cancel whatever existing motion is in action and then setup a new one. this would still cause a brief pause while it recalculates.

If you had all new code maybe you could set up some kind of PID and a target position and always work towards whatever the target is. A radical approach I haven’t thought too hard about.

I think the swing in your end effector would reduced if the cables all met at a single point rather than the edges of the cube. another way is a gyroscope on the effector to reduce swinging.

[Dan]

It’s possible I got the original wrong, or that z- is up? That would be odd.

I’m delighted you got it working!
Feel free to send a pull request with you change(s) and that’ll get your name in the github logs. Credit where it’s due.

[Dan]

The axis limits should be in mm. Impressive you can run at F500 and A1000 with 1/4 micro stepping. I’ve never tried it.

I would also expect HX0Y0Z0. Something might be going wrong in the firmware? I’ve only built two skycams before, and that was long ago.

If you start in the bottom center at the origin and say G0 Z10000 (1m up), does it go 1m up? does it go more or less? does it go sideways at all? you may also be able to test with shorter movements if it feels more safe to start small.

[Dan]

Yes, pitch is the drum circumference.

The robot has a belief about the we position, right? The smallest difference between the actual and believed position creates a big warping effect on movement. It’s a problem with all polargraphs, zarplotter, and skycams.

So with subdivision ON it runs smoother? Mission accomplished! 😎

[Dan]

I have updated the firmware dev branch to reflect the changes.

[Dan]

That’s… odd.

Let’s say you want the tool to move from A to B. The software used to calculate the belt lengths at B and then naively turn towards that goal. Because this is a hanging plotter the movement created is an arcing motion. To minimize this effect I added SUBDIVIDE_LINES, which breaks long moves into short ones …~5mm each, by default. You make the subdivisions bigger if the precision is still acceptable. SEGMENT_PER_CM_LINE (0.5) would be one every 2cm.

Turning off the feature will mean less calculations from the firmware but also reduce fidelity.

Maybe I should turn this into SEGMENT_MAX_LENGTH_CM so it doesn’t become a crazy fraction?

Can I see a video of the new behavior?

[Dan]

Joyer, I would recommend an Arduino Mega. We build our machines with the RUMBA board which is a mega + ramps shield merged into a single PCB.

[Dan]

I don’t make many sales, so I have time to support everyone who asks.

I also don’t have one of every robot or an automated way to test every robot. I see now that the acceleration and feedrate defaults for skycam are way out of date.
The system USED to be motor-steps/s and now they are mm/s.

I just went through the header files and updated all default speed values. Please update your version to the latest from the development branch: https://github.com/MarginallyClever/Makelangelo-firmware/tree/dev

Also please let me know if the LCD panel is more responsive for you. I’ve been working on making it ess painful.

[Dan]

maybe this tutorial will help: https://mcr.dozuki.com/Guide/How+to+update+Makelangelo+firmware/4?lang=en
Remember to change configure.h before you upload the code.

[Dan]

https://github.com/MarginallyClever/Makelangelo-firmware/releases/

Get the latest onto your machine. then follow the previously mentioned steps.

[Dan]

The noise is very troubling, but I see lower hanging fruit here:

Winding cable around a drum is trouble. cable never winds the same way twice. The amount of cable pulled changes as the drum fills and empties. You’ll never know how much cable you are actually moving in a single step. Also the drum diameter effectively weakens your motor. Better to have a very small toothed or friction pull from the motor of consistent diameter, and then some other mechanism that manages loose cable behind the motor.

I have four motors running here on a zarplotter and they’re more quiet. Have you adjusted the current to each motor for the rated torque? are you sending lots of very short line commands? If I overwhelm the system with tons of short line commands the parser is slower than the stepper control. new lines cannot be queued and optimized before the queue runs empty. net effect, the machine starts and stops in a stuttering motion.

I would also try lowering your top speed. with the newest firmware try a maximum feedrate of 90mm/s and max acceleration of 200mm/s

[Dan]

Hi VanDerSloth!

I’ve never adjusted CLOCK_MAX_STEP_FREQUENCY, ever. If you are using a RUMBA or a mega 2560 then you should *not* change it, as it is used to calculate timing frequency of the Interrupt Service Routine (ISR) that fires step commands to the motors.

Can you show video of the problem? then I’d understand the sound and motion you are experiencing.

I wonder if this is at all related to the fun I’m having with the Zarplotter…

[Dan]

T is the distance from the tool aka end effector (EE) to corner A.

[Dan]

Arduino mega 2560 + RAMPs shield should work.

Open the Makelangelo firmware with Arduino App.
Navigate to configure.h
change #define MOTHERBOARD BOARD_RUMBA to #define MOTHERBOARD BOARD_RAMPS
An LCD panel is expected. You may have to add

#undef HAS_LCD
#undef HAS_SD

if you do not have the LCD panel.
Then use the app to compile & upload the code to your mega.

[Dan]

“when I open software, it’s not worked.”

Can you be more specific? The version I give you is the same you downloaded.

[Dan]

So you need a “center/don’t center” and maybe a “resize/don’t resize” option? I’m looking for the best way to implement this.

[Dan]

I have not personally done it so I can’t say for sure.

[Dan]

> Now I have a new problem, the engines get very hot when they are at rest, that is, when one motor moves,

On a4988 stepper drivers there is a voltage adjustment dial. Turning the dial down will reduce the heat in your motors. if you use the same motors as us then you want a reference voltage of 0.7v. the reference voltage can be checked by using a multimeter on the dial and the bottom right (gnd) pin. Do not turn the dial when the power is on! It can damage the driver.

[Dan]

I made an update to the dev branch. the values are defined in robot_traditionalxy.h, adjust them there and everything should continue as normal.

[Dan]

I’m excited someone tries the traditional XY mode. Please post pictures and keep us updated.

In robot_traditionalxy.cpp method IK() you will see

motorStepArray[0] = lround(x / THREAD_PER_STEP);
motorStepArray[1] = lround(y / THREAD_PER_STEP);

the THREAD_PER_STEP is really the difference between mm and steps-per-mm for each axis. For your solution you will want to change it a bit like this:

motorStepArray[0] = lround(x / STEPS_PER_MM_X );
motorStepArray[1] = lround(y / STEPS_PER_MM_Y );

and then define each new value based on your gear reduction, microstepping, and so on.

[Author]

Posts