Firmware uncertainties

Here is a list of things I am not sure how to test or set with any certainty. If you know of a test or a better setting please chime in. These are in terms of MPCNC and LR.

I will update this list (and the firmware) as this get finalized. Test branch trying to get this right for this madness.

  • acceleration, max accel, travel accel. I am now setting these to { 230, 230, 80, 230 }.

  • Junction deviation I am now setting this at 0.04 according to the equations this is slightly slower than we used to use before it existed.

  • ADAPTIVE_STEP_SMOOTHING, I have it on, do we need too, any harm in having it on? seems to make no difference so I am leaving it on.

  • minimum arc segments, and mm per segment. --I like .3mm for mm_per for small details corrections on the rest commented out.

  • Rambo driver current settings in the LCD is missing.

  • #define MIN_STEPS_PER_SEGMENT 6? So smallest possible move/segment is 6 * 1/100(steps per mm) = 0.06mm?


I need to get off my butt and finally look at these…

HAHAHAHA, I have set them to what I believe makes the most sense but I much prefer a real world test to prove it.

I started fresh and dug through all the settings so I just wanted to keep a list.

Arcs are pretty nasty, way more complicated that I imagined. Lots of notes in here, It looks like the troubles we have with arcs are actually overloading the CPU with the math of it. Small arcs do not take long enough to calculate the next move.


I think that explains why you can’t just put in super high resolution arcs, it will work but it slows way down to fill the buffer.

I am thinking we should just turn off arcs for the 8bit boards? S curve accels needed to be hand coded to be efficient enough to work on an 8 bit CPU. Unfortunately I think this is too far beyond my pay grade to help. So maybe only on the Archim’s and other 32 bit boards?

1 Like

Hmm I seem to recall the opposite. My little LED thingy showed the movement queue was not being depleted. I’ll see if I can run some of this stuff to ground this weekend and try to get some solid answers.

I do not understand the program enough, but if it is not CPU related I am looking to see if maybe the lack of Extruder numbers could choke it? I does Calculate XYZ and E, that could be fixable. Something like if e=null than skip E or something?

Need to also test it without CNC workspace enabled.

There is also a delay in there for the temps, I think. Maybe this is like the fan port laser error we had, hard coded fan delay?

Does the queue have a way to be depleted while it is computing arcs? It may be that it is stuck in a sin call, and consequently isn’t stepping.

those words

My head

Those words are over my head, ahahahah

There is so much going on I don’t understand I am going to brute force some things. I see options I can turn off so I will start there, also it has an option for cnc workspaces, maybe that needs to be on since we have it on, will it work if they are both off?

1 Like

I was just putting some doubt in Jamie’s conclusion.

Regarding accelerations, it seems pretty machine dependent. A larger build will need lower values, but I also think smaller is ok and safer. I personally like when it is so slow you can see it ramp up. But I think that’s just my preference.

Here is a thought experiment. If you find a perfect acceleration where above it will skip steps in an air movement, and below it won’t skip steps, how will that change in material? The force needed from the steppers needs to exceed the force for acceleration plus the force for milling. The force for milling is going to be proportional to the speed. The acceleration force is theoretically constant. So the max force is right before max milling speed.

You have no way of really knowing exactly what the mass of the gantry is, but you can estimate. You definitely don’t know the milling forces, but you can also estimate some reasonable values. Maybe from there, you decide what fraction less than the max air acceleration you will use to give a good buffer for milling?

And remember that novices need to get their first job working, and experts can change it if they want, so I would always set it a good portion lower than the optimal. We should probably add something to the docs for setting it higher.

1 Like

I remember I only increased it to get better prints (less blobby corners). I am less concerned with printing and more concerned will cutting so I think bringing these down a touch is good.

I think it is more of a too fast and you skip steps due to mass/weight. Too slow and slow milling could go bad from work hardening metals in a sharp corner. So I am shooting for the lower end I think.

In that same line of thinking I used your note from a few months ago to lower max speeds considerably in this new round of firmware, pros can change whatever they want. 50,50,20…might even go a lower (12-15) with the Z but I also lowered that accel a touch , too low and 3D carves take even longer though. I remember a point we tried to solve Z issues that way and it just made things too slow.

I just did some arc testing on the bench and it actually seems fine now. I need to drag a test machine back up to the office to really do it but I am seeing no slowing now.

The max Z speed should be honored as a whole for XYZ moves. I remember that not working right, but I thought they fixed it. Basically, a move from 0 to 100,100,1 Should be able to finish in 1 second if the max speeds are 100,100,1. Disregarding accelerations, and the F on it would need to be about 140.

Yeah I am pretty sure it works again. We had the accels way down at one point, like 5 so on a 3D or a bunch of clearance plane move sit was really noticeable.

I’ve updated from 412 to 414 and in the configuration I’m seeing Junction is now 0.1 instead of 0.01, so that should be a big help. I did a video before and after and I am still seeing sluggish behavior around arcs. I used the crown svg and Estlcam with a feed rate of 720 mm/min, aiming for the same 12 mm/sec as the official test gcode.

Here is before, version 412:

And after, version 414:

In both cases the movement queue was not being depleted so I don’t think it’s a CPU issue.

I ported over my personal preferences which I don’t think are relevant to this test, but I’ll list everything in case:

  • #define USE_ZMAX_PLUG
  • #define X_MIN_ENDSTOP_INVERTING false
  • #define Y_MIN_ENDSTOP_INVERTING false
  • #define Z_MIN_ENDSTOP_INVERTING false
  • #define Z_HOME_DIR 1
  • #define NUM_SERVOS 4
  • #define SERVO_DELAY { 300, 300, 300, 300 }

And in Configuration_adv.h:

  • #define G38_PROBE_TARGET
  • #define G38_PROBE_AWAY
  • #define JOYSTICK
  • #define JOYSTICK_DEBUG
  • #define MAX7219_DEBUG
  • #define MAX7219_CLK_PIN 42
  • #define MAX7219_DIN_PIN 63
  • #define MAX7219_LOAD_PIN 40

I’m going to try disabling S_CURVE_ACCELERATION and ADAPTIVE_STEP_SMOOTHING. If neither makes a difference then I’ll try increasing JUNCTION_DEVIATION to a “crazy” value and see what happens and then after that who knows. Maybe I’ll try classic jerk just to see. Maybe I’ll play with arc parameters and see what happens. Or see how much of a difference the acceleration values have.

1 Like

Crud. That is crazy that does not seem like arcs are an issue it makes all the small circles fine it seems like corners tighter than 90 are triggering that to choke it. but they both seem bad to me.

I will put my MP back together this afternoon and run it. I would say jump up to 415 (linked at the top) that gets us to 2.01 at least. I did the math on the junction deviation, there are two links in the firmware but maybe my test file doesn’t trigger it. But that seems to be the issue for sure. I will make a few test crowns.

Ok I’ll upgrade to 415. I had hesitated because I’m on RAMPS-like but I’ll give it a shot. Good news is that 415 contains a joystick fix that came after 412 and 414.

Also I found that disabling S_CURVE_ACCELERATION and ADAPTIVE_STEP_SMOOTHING didn’t make a difference, or not enough of a difference that I could tell.

Also here is the gcode I generated, if you want to try to reproduce the behavior exactly.
0102_crown_mine.gcode (I have a lift and pause at the beginning which is when I normally turn the tool on.)

1 Like

Fantastic! 415 solved the slow arcs. :partying_face::+1:

Along the way I noticed that the steppers are set back to A4988 in 415 with steps/mm to match. I set it back to DRV8825 with 200 steps per mm.

I also did M502 and M500 to reset any other settings just in case.

OctoPrint gives a warning about temperature protection when extruders is 0. I’ll probably submit a PR to upstream Marlin about this. (Done:

1 Like

YESSSS!!! Did you do it they way I have with with everything not specified other than 0.3mm segments? Do you agree with that number or can/should we go lower?

The Rambo has A49 driver timing so it does not get changed. (I did up the current to 75% though).

Freaking sweet!

I will work on the other boards later then. That is great news.

1 Like

I tried re-enabling

#define MIN_ARC_SEGMENTS   5
#define N_ARC_CORRECTION   25

expecting to see the problems, but the same crown was fine with no slow arcs. I was really struggling to understand this then I realized the difference in MIN_ARC_SEGMENTS, which was 24 for version 414 and 5 for version 415. I tried setting MIN_ARC_SEGMENTS to 24 in version 415 and the slow arcs appeared again.

I have not yet tried lowering MM_PER_ARC_SEGMENT but it is becoming apparent that the length and number of arc segments is key to the slow arcs problem. Unfortunately it seems there would be a tradeoff: if you wanted to have a pen to have a high feedrate for tracing a large-radius curve, then a small value for MM_PER_ARC_SEGMENT could flood the system with a high rate of short segments, but for a slow small-radius helical plunge you would want smaller MM_PER_ARC_SEGMENT to faithfully reproduce a circle instead of a polygon. Perhaps the ideal MM_PER_ARC_SEGMENT would depend on feedrate and it would be better specified as MS_PER_ARC_SEGMENT to keep a roughly constant rate of segments going.

I think I will try this: first change MM_PER_ARC_SEGMENT to lower values and see if I can get sluggish arcs. Then generate gcode with faster feedrates and see if it gets sluggish at the same point or if it gets sluggish with relatively longer MM_PER_ARC_SEGMENT. Maybe I might look at MS_PER_ARC_SEGMENT but no promises.