CoreXY pen plotter jerky movement 8bit vs 32bit?

Hey all,

So I've been working on my pen plotter for a while now and managed to get most kinks out of the way. Some weird issues with the plotter suddenly hanging were due to a faulty servo motor causing an internal short and shutting down the Ramps board every time it ran some code.

Now, I am making really nice work with it lately and been programming lots of generative artworks in Processing. The thing is, lately I'm working with nice smooth curves that generate a lot of handles so my Ramps 1.4 gets overrun with lines of GCODE. I'm really curious if the 8-bit CPU may be a bottleneck causing jitter and scribbly/wiggly lines?

In this video you can see an example of the machine speeding up and slowing down randomly. It looks as if the Ramps board has trouble working through all the data and it chokes up from time to time (actually most of the time). Sometimes it has a bright moment and just slides across. But when it jitters it also creates very clearly visible scribbly lines. This is absolutely unwanted!

[www.youtube.com] (after the 40-second mark it speeds up and slows down)

I have an SKR v1.3 board laying around for my Delta that I'm fixing up, bought a cheap second hand one that I want to get back into working condition. However, if someone recognizes the problem I'm having as an 8-bit vs 32-bit problem, I will have to use the SKR 32-bit board for the pen plotter for the time being.

So, I hope anyone knows what's going on. Oh, just to be clear: I'm already printing from an SD card because I read somewhere that USB is also a real bottleneck when it comes down to printing high-resolution files with both a Delta and CoreXY.

Edited 1 time(s). Last edit at 10/09/2019 05:42PM by Ohmarinus.

---

http://www.marinusdebeer.nl/

This looks like buffer empty issues to me.

The gcodes being sent takes so little time to execute that processor empties its command buffer and has to wait for more data over serial or from sdcard

you could try and increase the buffer size.

A different firmware such as klipper might help here also [www.klipper3d.org]

A SKR 1.3 should also help as it has a higher speed SD card interface. (and much faster usb)

Edited 7 time(s). Last edit at 10/09/2019 11:49PM by Dust.

It is well known that trying to send gcode via USB is an unreliable process, especially with 8 bit controllers, due to buffering issues. People have been having that problem with 3D printers for years. Plot from SD card.

---

Ultra MegaMax Dominator 3D printer: [drmrehorst.blogspot.com]

As you are already printing from SD card, I think the problem is that you are only printing curves, which are made up of lots of short line segments, and your current electronics and firmware combination can't keep up with the rate at which it needs to execute Gcode commands. Can you adjust the Gcode generator to generate longer line segments? If not, then 32-bit.electronics may help, depending on what electronics it is and whether the bottleneck is general processing, floating point processing, or the SD card interface. Your SKR board doesn't have hardware floating point or a fast SD card interface, but its general increase in speed should help.

Edited 1 time(s). Last edit at 10/10/2019 02:38AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thanks for the feedback, I have tried out the SKR 1.3 board with no success. So I think the file must be indeed curve-heavy as dc42 suggests.

The issue is that in this certain script it's very hard to make the curve length longer.

For those interested, this is the GCODE file:
double_pend_v4_cV_circ_0001.gcode

Maybe by seeing the lines in the gcode file, you know what's going on here dc42

All in all it was a fun (and time consuming) exercise to get Atom, PlatformIO and SKR 1.3 running on a Mac with Marlin. So I'm confident about continuing the Delta project with the SKR 1.3

update
I managed to create an addition to my script that only registers one out of three points, resulting in a file with much less data while still retaining the same curve shape. I tried doing one out of six but that definitely started to misshape the curves. Will try to print again later today!

Edited 1 time(s). Last edit at 10/10/2019 10:56AM by Ohmarinus.

---

http://www.marinusdebeer.nl/

You could try optimising your gcode

no need for all those z1.00 on the g2 or g3..., just wasting controllers time processing that part of the gcode line

Quote
Dust
You could try optimising your gcode

no need for all those z1.00 on the g2 or g3..., just wasting controllers time processing that part of the gcode line

Okay, I'll also rip the part out where it generates the Z1.00 parts! Thanks for the tip. I had not expected that this would cause such severe issues, but I guess every little 'bit' counts

---

http://www.marinusdebeer.nl/

I don't know if removing all the Z1 will help at all... Its just something to try.

also consider using relative positions

ie after the initial set point go relative mode and then you only need to send the difference in position should be much smaller gcode file to process

Quote
Dust
I don't know if removing all the Z1 will help at all... Its just something to try.

also consider using relative positions

ie after the initial set point go relative mode and then you only need to send the difference in position should be much smaller gcode file to process

Removing the Z-lines saved me 81 bytes on a 12.321 byte file

It was another nice practice though. I think, together with the machine now having to only read 1/4th of the amount of code, it will probably work a lot better. Will update in a couple of hours, now it's time to hit the gym!

---

http://www.marinusdebeer.nl/

i looked at gcode.
and if the i- j- archs are important, can you change the code to just use the line segments? it looks like i,j normally are offsets for an arch. they would not be processed by reprap gcodes as defined.
since i,j are not understood they would generate an error, and possibly cause commands to process at slowest speed possible. also F for feedrate is not defined per line. this also would have machine run at slowest rate
i don't know for sure how your machine processes feedrate for g02, as i'm aware it will process as a G0 first two char, which is a safe slow feed rate still. g0 is normally a fast move, but not as fast as accelerated move.


here is reprap gcode [reprap.org]
here is what i,j do it is a reference on arches
[www.cnccookbook.com]


from reading all this it is possible that the i,j are not processes as commands and are confusing the buffer causing it to assume slowest rate machine can run at,
and that the i,j are offsets and when an arc crosses 0, the offsets for some curves are ignored, causing a ripple at output.

its a humble guess.

prob best to use a plotter tool that creates line segments instead of arch code. my guess is removing the i,j commands will speed it up but not remove the ripple effect. the ripple effect is offset if i,j codes are processed.
my guess is also if you used a finer pin you would see the entire draw has small ripples

so you could use grbl firmware which supports i,j commands, or use a tool chain that creates your code without arc commands.

Edited 3 time(s). Last edit at 10/12/2019 09:48PM by jamesdanielv.

G02 and G03 are supported in most firmwares. The idea is to define a curve WITHOUT needing millions of single step line segments.
See [reprap.org]

The page you linked to seem to be incomplete and is specifically for 32bit controller running "RepRap Firmware" (RRF)

The person who maintains RRF would never allow the firmware to not have a features other firmwares have.
and in their own logs I see
"Version 1.17d
=============

New features:
- G2 and G3 arc movement commands are implemented.
"

If you plug the example gcode into [ncviewer.com] you can see what it is trying to do.

Edited 1 time(s). Last edit at 10/12/2019 10:51PM by Dust.

sigh.. one of those types that isn't really asking for help;
but still here we go...

in this case, you might want to try running line segments versus arc segments and see the performance differences.

if using in marlin firmware you might need to enable it to have it read arc commands.

gcode is not specific to 8 bit or 32 bit. that just seems silly.

but firmware and certain features enabled in specific firmwares does enable support for arc moves. it more than likely is not enabled by default. some firmwares dont even support it at all.

from my understanding the issue was performance of arc on 8bit versus 32bit controllers, and how to get better performance. not on how many line segments exist.

millions of lines of code for arcs seems like pushing beyond any machines resolution detail. i doubt anyone would code that many instructions purposely in an arc move unless it is some marketing group wearing deep boots.

i doubt that the issues are from how many commands are in buffer, or how much text is in the commands per line. it might improve performance but i doubt it would be noticeable.

it seems you are fairly certain on your direction.
32 bit might be the way to go in your particular and specific situation with the specific rules you have put in place to have it work in your case.
performance would be better for arc in the calculations for the math improvements of 32 bit controllers as well as higher clock speeds.
so this would mean better control of arc on those controllers. so 8 bit currently seems underpowered for your specific tasks,
but they can easily be worked around by those that do line segments of fine detail from an sd card within reasonable limits of 0.1mm to 0.01mm depending on tech.

i wish you luck

Edited 5 time(s). Last edit at 10/13/2019 02:39PM by jamesdanielv.

The issue is that MarlinFW chokes on the G02 and G03 commands. Especially when they follow each other. It's not a hardware issue and not an issue with my file. I have narrowed it down to Marlin itself being the culprit.

What firmware does work fine with these G02 and G03 commands and still is able to control a servo in the same way as in Marlin?

My requirements are:
LCD support
SD support
G02 and G03 support
Servo support with M280 P0 S50 (for example)

I like the idea of Klipper as suggested by Dust, but their site only lists a way of installing it for a Raspberry Pi, so I'm kinda lost how it should work for Ramps 1.4 - wait I think I get it, you ALWAYS need a Pi when using Klipper? I do not see how this would improve my machine if I have to buy yet another extra board to run it

Edited 3 time(s). Last edit at 10/15/2019 12:02PM by Ohmarinus.

---

http://www.marinusdebeer.nl/

I am not sure if you are still monitoring this but Klipper uses both an Arduino setup - e.g. RAMPS, and a Raspberry Pi. The Raspberry Pi does the heavy lifting - presumably including G02 and G03, the Arduino is just on light duties.
There is a YouTube video at [www.youtube.com] with a rundown of setting up just the above setup. I am playing with this as a project I am working on has ground to a halt with both Repetier and Marlin. While the configuration is a bit arcane, it does seem to be a small touch more transparent than either Repetier (too automated and insufficient control) or Marlin (needs good Python chops and I am strictly assembler)

Mike

Looks like you just haven't got the right board+firmware combination. I've just run the test file you posted on October 10 on my Duet WiFi powered delta printer. No pauses (except where you have used M400 commands in the GCode file) even running it at four times the speed you set in the GCode file. After printing, the diagnostics confirmed that there were no underruns in the move queue. Video to follow.

Unlike all the other common controller boards on the market today, the Duet WiFi uses a high speed SD card interface, and the processor has built-in floating point maths. That's been the case since we launched it in 2016, and other available 3D printer control boards still haven't caught up.

EDIT: video now at [youtu.be].

Edited 2 time(s). Last edit at 10/22/2019 07:41AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hello : Ohmarinus

I wanted to tell you that I built a MPCNC using a Arduino Mega 2560 and a Ramps 1.6 board. My first test was to print the image below.



All lines are as in the original Corel Draw sketch. In fact you can barely tell which is the original and the MPCNC Copy.
In the image you can see I started the print too far over and left the sheet of paper that it was printing on hower.

You can clear see the Pen tie wrapped into the holder in the lower left hand corner.

Edited 2 time(s). Last edit at 10/22/2019 08:18AM by Roberts_Clif.

---

Computer Programmer / Electronics Technician