Marlin Surface scanning on a Delta 3D printer - help

jeffeb3 · March 25, 2022, 12:43pm

Marlin is open source and supports delta. It wouldn’t hurt to look at their implementation. Or duet/RepRap?

My first impression is that you need to break up the lines into tiny segments too. But maybe the math is simpler. It feels like the difference in an analytical integral vs. riemann sum.

Edit: that is just what they do:

github.com

MarlinFirmware/Marlin/blob/2.0.x/Marlin/src/module/motion.cpp#L980


      
           * the bedlevel.line_to_destination_segmented method replaces this.
           *
           * For Auto Bed Leveling (Bilinear) with SEGMENT_LEVELED_MOVES
           * this is replaced by segmented_line_to_destination below.
           */
          inline bool line_to_destination_kinematic() {
          
            // Get the top feedrate of the move in the XY plane
            const float scaled_fr_mm_s = MMS_SCALED(feedrate_mm_s);
          
            const xyze_float_t diff = destination - current_position;
          
            // If the move is only in Z/E don't split up the move
            if (!diff.x && !diff.y) {
              planner.buffer_line(destination, scaled_fr_mm_s);
              return false; // caller will update current_position
            }
          
            // Fail if attempting move outside printable radius
            if (!position_is_reachable(destination)) return true;

Paciente8159 · March 25, 2022, 2:30pm

@jeffeb3 Thank’s for the precious tip. That confirms my hypotheses. Of course I already had looked inside Marlin…actually part of the delta code (the forward kinematic) was from Marlin, with some minor adaptations, but I did not found this bit.
In the case of µCNC this is fairly easy to implement since the a motion line segmentation strategy is already implemented because of the internal 16-bit bresenham algorithm option that uses 16bit integer math (instead of 32bit) in the ISR step generation to reduce the ISR run time code in about 20~30%.

github.com

Paciente8159/uCNC/blob/6a8d092d98b41ca643a601fca35df9ee7e8abd99/uCNC/src/core/motion_control.c#L254

      
        
            {
                line_segments += (max_steps >> MAX_STEPS_PER_LINE_BITS);
                float m_inv = 1.0f / (float)line_segments;
                for (uint8_t i = AXIS_COUNT; i != 0;)
                {
                    i--;
                    motion_segment[i] *= m_inv;
                }
            }
            
            
while (line_segments--)
            {
                while (planner_buffer_is_full())
                {
                    if (!cnc_dotasks())
                    {
                        block_data->feed = feed;
                        return STATUS_CRITICAL_FAIL;
                    }
                }

I actually already have implemented this for the delta but have not uploaded the code yet since I’m also restructuring other things in the code to speed up things for all kinematics.

Marlin implements a division per time unit. My implementation is per distance unit.

Paciente8159 · March 25, 2022, 9:57pm

Good news!! I think I found the underlying issues that caused the arc motions. Most of them were caused by optimizations that work well for linear kinematic machines like cartesian but not so great for delta.

I’m working on the code adaptations. I let you know when it’s ready for a spin.

bastardazzo · March 25, 2022, 10:57pm

Always good to hear some goos news, cant wait!

Paciente8159 · March 25, 2022, 11:36pm

I’ve re-branched bastardazzo from the main branch and the modified config file for your machine.

Try it out and let me now how it go. Let’s see if the motions are more straight this time. Don’t forget to check settings before taking off. They should be untouched but it’s always good to check.

bastardazzo · March 27, 2022, 4:32am

Updated the firmware, trying without homing first. No G91
G0Z10 goes up, but its almost like its stuttering, i thought i messed up at first hahah, i assume its the arc division.

G0X80 send the effector down about 5mm, the movement seems rather linear, but it is very slow compared to before. Segments seem to be 1mm.

Went back to 0 and sent a G0X-80, and it looked like it didnt go off plane…hmm, and indeed, the on a G0X0 to a G0X-80, either way, the difference in height it almost negligible, id say about .5mm and it could very well be due to my janky printbed which is a piece of foamboard atm.

It is very slow as i said but it works!!! On the X- at least hahah
Checked X+ once more and indeed its 5mm

0,0 to G0Y80: 5mm down
0,0 to G0Y-80: 1mm up

G0Y-80 to G0Y80: from 1mm up it goes to about Z0 when its halfway through and -5mm at G0Y80

G0X-80 to G0X80 from 0mm up it remains planar until Z0, then it begins to go to towards the final -5mm at G0X80

G0X-80 to G0X0Y-80 was planar as far as i can tell!!! no more curve and no more of them compounding like it did before (both 1mm up compared to Z0 though)

Time to go to bed for me now, let me know if you want me to run more tests like the last one on this firmware version

Paciente8159 · March 27, 2022, 2:43pm

Thanks for the tests.

Just one question. Did you homed the machine first? If not try homing and then move the effector down via G0 commands.

Yes it’s from the line segmentation. It speeds up then hits a bottleneck and drops, then manages to speed up a bit and down again. There are still some configuration we can try to minimize the effect but I would like to see this go in a straight line for once

EDIT: I did some testing on the bottleneck effect on µCNC. The problem is that the planner can’t keep up with the step interpolator when line segments are too short. Fortunately this is super easy to fix. Just increasing the planner buffer seems to solve this. Adding #define PLANNER_BUFFER_SIZE 30 to cnc_config.h file does this. I will modify this in future releases of µCNC.

bastardazzo · April 8, 2022, 4:13am

Back on it, its been a while!

Turned the machine on to test it with a homing first and very oddly the machine would unlock but not home or excecute any movements… I didnt touch the machine all these days, checked the wiring and all seems good. Restarted it and all of that but no luck.

Reuploading the last version of bastardazzo branch (not 1.4.0-beta2) to see if it changes anything.

Ok i think that the arc division makes homing extremely slow, but it works like before for the rest id say so no problem.

Homed the machine, dropped it to G0Z10, it did not produce the X tower error and it has the correct settings!!

Ran some movements on X and Y and…
Its about as planar as it can get.
Amazing, I cant thank you enough for this.

Trying with #define PLANNER_BUFFER_SIZE 30
Clean compine (the third time, as always)

Homing is so ridiculously slooooow, smth like 5mm a minute

current settings

After the homing I ran a G0Z150 and the movements is still segmented like before id say

here is where i put it (starting to think i just added a comment but what it refers to isnt in uCNC yet hahah and thats what you mean by will modify it)

EDIT1:
Uploading the lastest master branch of uCNC, USART_UDRE_vect and USART_RX_vect orange warning on the compile

When uploaded the RAMPS light is orange, even after a restart, never seen that before, couldnt really find anything online so ill wait for your answer before going any further.

Reuploaded the latest bastardazzo and it blinks green again ::

Paciente8159 · April 8, 2022, 6:37am

Woke up and read this… You just made my Day . Many Many thanks.

Now for the rest of the answers

I’ve kept my self busy. Added basic trinamic driver support, a subset of canned cycle gcode support, expanded IO, completed support for RAMBO board an a couple of other things.

One of the things I’ve finally managed to get fixed was this annoying bug that was kind of hard to diagnose. This affected motion every time a sequence of coolinear short segments were executed, resulting in random absurd speed slowness (sometimes at the start of the line, sometimes in the middle other times it never even showed up). It turns out this was due to a floating point cumulative imprecision that caused a value to be outside of it’s range. This was transversal to all kinematics. One of the files I use to test µCNC that is in the tests\gcode folder (called stress-test.ngc) allowed me to push the firmware to it’s limits and cause that effect.

Now you can use the master branch (not beta2). The master as in it’s current state:

Or use the bastardazzo branch.
I’ve applied a couple of patches to this one including the one I mentioned above.

Now about the speed aliasing in the delta. Yes the ATMEGA is having a hard time chewing this one, but let’s try to improve this a bit.

Here are a few things that can be done:
If you use the master branch the #define PLANNER_BUFFER_SIZE 30 is no longer needed.
If you use the bastardazzo branch keep it there anywhere inside the cnc_config file. You can increase it to 40. It won’t do harm and you have enough RAM.

Now the other patch I made in the bastardazzo branch (and is also present in the master) is the ability to adjust the size of the line segments in the delta.
Again in the cnc_config file add another line with #define DELTA_MOTION_SEGMENT_SIZE 1.0f

The current default value is 1. Try setting this to 2 like this #define DELTA_MOTION_SEGMENT_SIZE 2.0f. If this does not affects the motion (making it less planar) try increasing it again. I still have to do some math to try and get this calculated automatically to give the best compromise.

Unfortunately you will have to compile and upload every time you want to try a new value. Remember this is the delta motion segmentation…setting it too high will make your delta run in a non planar way…too low and speed will be affected. I’ve tested this on an Arduino M0 and the extra CPU power is able to handle the 1mm segments quite well…

When you get this value set there are a couple of extra settings to make the motion more consistent and these are:

Enable 16bit bresenham algorithm by uncommenting #define BRESENHAM_16BIT (line 264 or something like that). Although marked as experimental I truly this is stable an worth a spin.
Reduce your acceleration values (to something like 5mm/s^2 or less). This will make the delta accelerate and decelerate more slowly making the top speed more maintainable.

I don’t get these issues on my side. master compiles fine and works as expected.

Paciente8159 · April 8, 2022, 10:49am

Now about the communication issue on the Mega board.
As I said I also believe this is an issue of the atmega16U2 on the Arduino Mega board.
To make it run like it should (and support the 100ms polling that OpenCNCPilot uses by default), just get a simple USB to RS232 converter and plug it directly (if it comes with adapter resistors in series…they usually do but better be sure) in the Arduino’s pins RX0 and TX0.

I use one of these directly:

You then plug these pins in pins D0 and D1 of your Ramps AUX1 connector

This will make the RAMPS a much more pleasant experience with the OpenCNCPilot.

bastardazzo · April 8, 2022, 1:55pm

Ill be trying the new branches tonight, as well as all the setting iterations you mentioned!
About the cable, this one would work right? The price is outrageous in comparison to what you sent but this way ill be able to work on it over the weekend!

Paciente8159 · April 8, 2022, 2:03pm

Yup that will do the trick. But it doesn’t have to be that cable. ANY USB to RS232 converter will do (if you have one laying around give it a go). A CH340 chip or any other dedicated chip will do the trick. For example my Arduino UNO clone comes with a CH340 and it works just fine.

bastardazzo · April 8, 2022, 2:18pm

Wait, cant figure out if there is some chip inside that usb housing or if the RS232 only refers to the endings being duponts instead of a USB B for example, cause if there is no chip/extra component in there and its just a open ended serial cable i can make it myself. If not ill have to buy one as I dont have any

Paciente8159 · April 8, 2022, 2:55pm

It’s there:

A genuine PL2303TA chip module is housed in USB 2.0 type A male terminal for wider compatibility and supports reliable data transfer rates

By the way. I’ll be adding a platformIO ini file to the project, (maybe this evening) so it can be compiled and uploaded via Visual Studio Code and platformIO.

EDIT: I just realized an optimization just begging to be implemented to which the delta will benefit most. This will save additional CPU cycles and hopefully have an impact on the performance. I’ll let you know when it’s ready.

EDIT 2: I just implemented it (it’s actually a small code modification. It took me less then 2 minutes) and the preliminary results are staggering. I’m going to run some more tests but if this modification holds I guess delta won’t be a problem for the 8-bit ATMEGA anymore

Paciente8159 · April 8, 2022, 10:29pm

And it’s done.

I’ve patched the optimization (and fixed a minor bug in the way) in the master branch and bastardazzo (the bastardazzo I did not test).
Master branch also as the platformIO.ini file to allow compile and upload firmware via this way.

Hope the tests perform well.

bastardazzo · April 8, 2022, 10:33pm

Fastest coder in the business, I haven’t even gotten off work and you revised and fixed it hahah

Paciente8159 · April 8, 2022, 10:51pm

I’m not fast. The changes were actually not that many.
I’ll try to explain the optimization.

The motion control line function does several things. One of them is figure out if it has to segment the line into smaller sections before sending it to the planner to calculate the speed profile and accelerations.

The planner does this by checking the new motion against the previous motion adjusting the junction speed depending on the angle between them.

In the case of the delta it breaks every single line into smaller segments (by default 1mm). But in this case there is no need to calculate angles between these line segments because they are all part of the same line (coolinear).

This skips a bunch of cpu cycles and since the delta has to do this alot this has a huge impact on performance.

I would now say… Forget about that DELTA_MOTION_SEGMENT_SIZE setting and all that. Just try these new patches and see how it handles things now. If it still struggles then adjust the DELTA_MOTION_SEGMENT_SIZE and 16bit bresenham and all that.

bastardazzo · April 9, 2022, 4:05pm

This one would work correct? Chip seems to be the same etc

Paciente8159 · April 9, 2022, 5:00pm

Yes I believe it will. The difference in that one (HX) is that the chip has been discontinued and the TA is the new one but they are the same. Has I said I think any dedicated USB-Rs232 chip Will do the trick.

EDIT: By the way I’m compiling and testing for the platforms I have with me to test. Count on releasing RC version today.

bastardazzo · April 10, 2022, 7:23pm

Im trying to find how to exactly wire the PL2023 cable on the boards but im a bit confused, cant find colour coded pinouts.
Also cant tell if I have adapter resistors in series for certain. Ive located the pins , but on the Mega I cant access them, a but confused.