Marlin: [1.1.8] Special Christmas Delta Destruction edition... + fix

[LVD-AC]

Delta printer gets almost destroyed by a simple move.

1.1.8 out of the box with the Flsun autocal config files
changes made : set DELTA_HEIGHT to 260 (my printer height) and disabled DELTA_AUTO_CALIBRATION

Printer no longer moves correctly; basic moves with the control panel in Repetier (or Pronterface) in the X and Y direction result in the Z-carriage to move way below the effector and move back up to its destination. Same thing with G1 commands. G1 X1 moves the Z-axis by about 300mm down and back up again????

Beware of standing close to your printer when trying to repeat this in order to hit the emergency button since this behaviour can seriously damage your printer. I for one am not willing to destroy my printer by testing bugfix-1.1.0 and bugfix-2.0.0 as well.

Was 1.1.8 even tested on one single delta before it was rushed out on Xmas day?

[mylife4aiurr]

I've installed v1.1.8 on my 3ku Delta. No issues execpt getting new skew correction feature working.
Heaters worked
LCD worked
Homing and moves correct direction worked
SD card reader worked
Delta auto calibration worked
Unifed bed leveling worked
Mesh editing worked
Printed a model

Sounds like direction of motors is different from your old firmware?

[LVD-AC]

Old FW was 1.1.6. In 1.1.7 homing works and G1 Zx.xx works as well (although very slow); so I don't think it's the direction of the motors. @mylife4aiurr What config files did you use?

[mylife4aiurr]

I used generic delta as template from examples, copied over to Marlin directory
Configuration.h
Configuration_adv.h
Then transfered my working settings from 1.1.6/1.1.7

No custom config for my 3ku Delta

[mylife4aiurr]

I'd double check, triple check. Sounds like some setting is not same as old firmware.

[LVD-AC]

Just did the same thing: started from the generic configs and adapted the strictest minimum of settings to my printer. Same result: a XY move of 0.1mm acts normal but 1mm or more puts the z-tower into auto destruct mode. Same thing when moving from the LCD panel: z-carriage drops down by about 300mm, yxz-carriages perform the move, z-carriage moves up again by the same amount.

[LVD-AC]

Using the 1.1.8 configs in 1.1.7 works fine, but the other way around is still problematic; so IMO it is not a config issue.

[mylife4aiurr]

V1.1.8 is not 2 days old. But it works on my Delta.

There were some changes made to jerk settings, reading the release notes. So check that too, perhaps u need lower values then previously. Other than that, idk

[LVD-AC]

I'll stick with 1.1.7 then

[rmcolbert]

I have the same issue w/ 1.1.8 with my 2 deltas (same config). When I move to a free XY height and then move X or Y in any direction, it appears to try and take the effector to X_MAX or Y_MAX before bringing it back to the specified location. The odd thing is that the delta autoconfig (manual in my case) works properly. I'm going to try building 1.1.8 from the generic delta config and only adjust the delta specific parameters and leave everything else default and see what happens.

[alex2603]

I have the exact same problem when moving to a XY coordinate, the Z tower goes 90 degrees, then the two other do their move, the Z tower goes to its intended position. I have a Kossel XL and I upgraded from an pretty older firmware version (dates as far as 2014), I'm going to try V1.1.7 with the same config

[LVD-AC]

Any suggestions @thinkyhead ?

[GuillermoElectrico]

I have the same problem, but also the autoconfig does not work either, it goes out of the bed outside in the second measurement. Same configuration in 1.1.7 without problem.

[rmcolbert]

This is going to sound obvious but the issue is somewhere in Marlin_main.cpp. I've backported all 1.1.8 files to 1.1.7 except Marlin_main.cpp and it works as expected. I'm going to start looking through the diff between the two and try to track down where it is going crazy.

[rmcolbert]

In Marlin_main.cpp, function prepare_kinematic_move_to @ line 13205

In 1.1.7, this is added to the planner buffer:
planner.buffer_line(delta[A_AXIS], delta[B_AXIS], delta[C_AXIS], raw[E_AXIS], _feedrate_mm_s, active_extruder);

In 1.1.8, the 3rd param is raw[Z_AXIS] instead of delta[C_AXIS].
planner.buffer_line(delta[A_AXIS], delta[B_AXIS], raw[Z_AXIS], raw[E_AXIS], _feedrate_mm_s, active_extruder);

This same change is in the planner line @ 13202 for SCARA printers but since I don't have a SCARA device, I don't know if that is right or wrong ... or any other potential impact of this change.

[LVD-AC]

That's the little bugger that causes all the trouble; I just changed the 1 instance and it works like expected now. No more z-axis destruction moves.

[LVD-AC]

Not sure about scara printers either, so I left it as it was; someone else needs to check and make a pull request for this so it can be incorporated in the special "new years eve" re-release of 1.1.8 ;)

[MoshiBin]

This issue affected me as well. I've spent a couple of hours trying to tweak my delta defines and reflashing to no avail... Ended up switching to @LVD-AC's fork which includes this fix and did not encounter this bug anymore.

[mylife4aiurr]

Strange, wonder why my Delta wasnt effected

[LVD-AC]

@mylife4aiurr Strange indeed the bug affects all segments in a move on ALL delta's but the last segment which is correctly directed to the destination. (that's is why it returns to it's original position after going wild). Are you sure you're running 1.1.8 ?

Then transfered my working settings from 1.1.6/1.1.7

[mylife4aiurr]

Positive. With v1.1.7 - I was using linear_advance. Try to compile v1.1.8 with linear advance and it will error saying linear advance is not supported on Delta's

[emilio1625]

I'm having this issue, is it the same as this issue, or should i open a new one ? goo.gl/ZuPK1N

[emilio1625]

@rmcolbert suggestion fixed this issue for me, but shoudn't this movement be stopped if i have enabled the software endstops?

[mylife4aiurr]

Ok ok. I didnt get this error, until now.

I was able to use delta auto configuration. - no problem
Used Unified bed leveling - no problem.
Used Mesh validation - sometimes as extruder reached edge of print bed. G33 failed. Printer becomes unresponsive and trys to home. When it comes into contact with end stops it ignores them. I have to issue M112 or pull plug. But didnt think it was related to this issue. It prints out 95% of the pattern, so im able edit the bad points after I reset the printer.
Even printed a small 20mm calibration cube.

What triggered the problem I think you guys are having is trying to print a bed leveling disc that took up whole diameter of print bed.
https://www.thingiverse.com/thing:2204193
When I tried printing that model full 180mm with 3mm skirt, printer bug'd out.

So gonna try fix. Still puzzled as to why you guys experienced issue right away, while I had to print a model to see it. Hope same issue.

[mylife4aiurr]

Applied fix to firmware, re-uploaded to printer. I didnt start from scratch (M502, M500, M501)
Glad because it takes a while doing auto delta config, UBL, mesh validation. Printed same model as above, no strange behavior. Thanks @rmcolbert

[LVD-AC]

Marlin_main.cpp in bugfix-1.1.x (#8851) and motion.cpp in bugfix-2.0.x (#8865) are affected as well by this bug.

[frank-von-thienen]

I made the little change in Marlin_main.cpp and it works fine.

[mcmatrix]

@frank-von-thienen In Marlin_main.cpp, for those lines you just changed raw[Z_AXIS] -> delta[C_AXIS] and that was enought, no other fix needed?

[LVD-AC]

Just the one line concerning delta's: line 13194

      #if ENABLED(SCARA_FEEDRATE_SCALING)
...
      #else
        planner.buffer_line(delta[A_AXIS], delta[B_AXIS], delta[C_AXIS], raw[E_AXIS], _feedrate_mm_s, active_extruder);
      #endif

[stephenvibes]

Thanks LVD-AC,
I'd tried 1.1.8 with similar near-disastrous results. Straight away, z-axis was fine, but x/y shot off before returning.
Your fix works perfectly! Many thanks.

[LVD-AC]

Thanks but it was @rmcolbert who pinpointed the bug/fix.