Marlin: Strange moves on Delta

Created on 2 Aug 2016  路  20Comments  路  Source: MarlinFirmware/Marlin

I just installed the RCbugfix downloaded yesterday.
I needed to take down the number of segments to 150 (was 200) to get some acceptable movements.

The machine is shaking and rattling on the table with my parameters for speed, jerk and acceleration the same as i used in 1.1-RC2.

To me it looks like the acceleration is not working.
Also noticed during homing with G28 that after the homing all three sliders are moved down.
Normally i start my job with:

G28
G1 Z10 F5000

Then the normal sliced code starts.
I was used to seeing (after preheating):

  • Home
  • Move down to 10 mm
  • Wait a while to stabilize temperature
  • Start printing

Now it is:

  • Home
  • Move down a little
  • With a bang for the speed change move down to 10mm
  • Without a wait moves down to the print position and starts printing.

Moves are very jerky and my towers are swinging around.

Potential ? Discussion More Data Testing

All 20 comments

At the moment G28 ends at a hight where it's warranted you can use the complete DELTA_PRINTABLE_RADIUS without hitting a max-endstop. In between we pimped up the moves for probing the bed to leave this upper dangerous volume before moving in xy- direction.

You could try to remove

  #if ENABLED(DELTA)
    // move to a height where we can use the full xy-area
    do_blocking_move_to_z(delta_clip_start_height);
  #endif

from gcode_G28() in MarlinMain.cpp

If you then can perform a G28 directly followed by a G29, without strange effects, we can remove this move permanently again.

If you prefer the one or the other is matter of taste. Normally you don't need to home if you have printed that high and have a part on the bed. On the other side it seems to be useful to be able to move in xy-direction directly after homing.

We just fixed an issue with delta speed in the last day or so. Can you download today's RCBugFix and see if we managed to fix this issue as a part of that? I recommend also that you do M502 followed by M500 to reset to default settings before doing any testing.

@Blue-Marlin
To me it looks like a useless move.
I do not use bed levelling so could not test the G28 G29 sequence for you.
Maybe add an extra switch to the condition?
(if delta and bed levelling)

@thinkyhead
Downloaded the latest bug fix and there is no improvement.
Not using the EEprom but cleared it any way.

For testing divided starting speeds and acceleration by 10.
This way acceleration is visible and the firmware is following it correctly.

To be sure I disconnected from the repetier-server and connected directly with repetier host 1.6.2.
The printer still stutters and the worst behaviour is in the first layers.

First 5 layers are solid and first layer is at 20mm/s, after that it steps up to 55mm/s
After that it is only wall printing with a perimeter speed of 40 and outer perimeter at 15.
The higher the build gets the smoother the moves are.

I use a megatronics 3.1 at 115200 baud-rate.
No bed levelling, no EEprom, no SD and no display.

Height dependent?
What's your model?

If your model would be like a top down truncated cone vase, i could suggest the segment length grows with the height for some slicers. In that case i'd try to slice longer segments.

If the segments are too short, there is no chance to fill the planner buffer. At least some moves in the planner buffer are required for smooth printing.

It is a square housing for some electronics board.
It is even growing a little bigger when it is going higher.
Normal production model that i am printing for 3 years now day in day out.
On 1.1-RC2 no problems. (besides other issues)
CDIhuis_Groen_V3.zip

@ads61 When in our development history do you see this problem emerge? Does it start with RC3, RC4, or some later version? Does it coincide with our addition of additional M665 options?

@Blue-Marlin We'll have to take a more comprehensive look at recent changes to our planning code and our delta handling and see what might be leading to such anomalies. Also, could this be serial-port related?

Tomorrow is a busy day for me and the printer has to do its job.

@thinkyhead
Just jumped from RC2 to Bugfix
It is a clean delta printer with no extra options and i even do not know of the existence of M665.
It only has to print a simple part over and over again and just tried the new code to help you with some feedback.

After that i will work my way up through the various RC's to find the point were the problems start and keep you updated about the progress.

tonarrow
That are exactly the structures i was talking about. Narrow at the bottom - wider at the top.
When sliced a lot of them is shorter than dropsegments. That means they are received, queued, parsed, partly calculated, unified with the next segment and thrown away.
In Slic3r you could experiment with 'Print Settings/Advanced/Resolution' ~[0.01 - 0.05] instead of default 0.

Also, could this be serial-port related?

@thinkyhead
#define EMERGENCY_PARSER has a small negative effect.
#define TX_BUFFER_SIZE 32 should have a small positive effect.
Theoretically.

Normal production model that i am printing for 3 years now

Have you re-sliced it lately? Previous versions of Marlin should exhibit the same kinds of issues when dealing with very small segments. If you find that your current .gcode file works well with RC2 but poorly with RCBugFix then we should look at the changes in the planner and stepper code. There have been attempts at optimization in these parts of the code, and they seem to work well, but we haven't tested all the edge-cases, such as this one.

@thinkyhead
It is sliced at least every time i place a new rol of filament and not 3 years ago.
The current gcode is 3 days old.
It is printed fine in RC2 and having problems with Bugfix

@Blue-Marlin
Switched to a calibration box with a 100 x 100 mm footprint and vertical walls. No improvement
'Print Settings/Advanced/Resolution' ~[0.01 - 0.05] instead of default 0. No improvement.

Raised the baudrate to 250000. - No improvement.

Switched to RC7:
No improvement.
Although the wait for temperature above the bed is better as in RCBugfix (It now really waits)
Also noticed that the PWM for the extruder fan is working and in RCBugfix not.
I use a value of 175 for max pwm because my fans are to good.

I am ready to go down to RC6 but if i remember correct there was a RC version where DELTA homing was broken. Not sure which RC this was.

I'm not sure why your extruder fan isn't spinning. Did you set FAN_KICKSTART_TIME in Configuration.h to make sure the fan has enough power to start spinning before it drops down to the lower speed?

Try playing with the dropsegments setting in Configuration_adv.h. Try setting it to 1, and then try setting it to 10. See if either of these makes an impact.

The dropsegments is in configuration_adv.h and not in configuration.h.
current value = 5 and used during all tests so i see no reason to change it.

I never wrote that the fan is not running.
The fan is running at max in RCBugfix and not at the programmed value.
(Resulting in to much cooling)

Interesting that the fan is only running at max speed. In your experiments did you find that M106 has no effect, or does M106 with different speeds show a strange curve?

I'm glad to hear you have already eliminated dropsegments as having any contribution. Thus we don't need to look at that code at all.

Tested RC6 but it did not work on a Delta.
(problems with homing)

Continued testing with RC7 and narrowed down the problem to the setting:

#define SLOWDOWN

If i disable this movements are back to normal.

Ah, I see the comment with this option explains:

// If defined the movements slow down when the look ahead buffer is only half full
// (don't use SLOWDOWN with DELTA because DELTA generates hundreds of segments per second)
//#define SLOWDOWN

鈥ut this option is easily missed. We should just disable it for DELTA automatically. So I'll add to Conditionals_post.h:

/**
 * DELTA should ignore Z_SAFE_HOMING and SLOWDOWN
 */
#if ENABLED(DELTA)
  #undef Z_SAFE_HOMING
  #undef SLOWDOWN
#endif
Was this page helpful?
0 / 5 - 0 ratings