@phaedrux Thank you! interesting info!

Turns out the home all has an offset of 2.5 set after z home. Removed that and it appears to work fine.

@robm

The flex cable is slowly moving inside the tubing. I realized that the nimble casing is not closing itself properly. Perhaps the casing deformed when I printed ASA with it.

@hardware-crash said in Anycubic Kossel plus - Bed Leveling errors with BLTouch:

I think i might have found a point that could have caused the problems with the BLTouch.
The mounting plate for the BLTouch (found on thingiverse), which is screwed to the fan collides with the push rods when it comes near to the towers of Y & Z axis. I commanded the effector to the positions directly under the Y & Z towers and the rods push quite hard against the BLTouch mount. Could this cause autocalibration to fail or wrong values ?

Yes, in a couple of different ways.

@dc42 many thanks, i think i get it now

It looks like the S4 on the final G30 command wasn't being seen - possibly due to a non-printable character somewhere in that line.

Ok..thanks

3mm

@dc42 No, there is no chamber heater configured... there IS a chamber heater, but it is completely independent (at the moment, I was thinking of later including control in the Duet), and is run by its own heater control.
I have M140 H-1 in config.g, so no instruction should be sent for bed/chamber anyway?

cheers!
andy
🙂

Conditional g code can be useful especially for config.g. For example you can configure it depends on 3d printer, laser or cnc mode.

@3mm said in Seems to be doing something : )):

I notice some releases at URL:
https://github.com/dc42/RepRapFirmware/tags
depict a 'verified' tag, while other's don't? What's the difference, are the un-'verified' beta or not-necessarially-stable test releases?

That is correct.

Here's the relevant documentation.

https://duet3d.dozuki.com/Wiki/Tuning_the_heater_temperature_control

@dc42 said in Help regarding my CoreXY:

1. To change to a right hand coordinate system, add parameter Y-1 to your M667 command, or swap the X and Y motor wires.

2. The jerky Z movement probably means that your Z acceleration in M201 and/or maximum Z speed in M203 is set too high.

HTH David

In the "Configuring RepRap Firmware for Core XY" doc it says:

"Important: make sure that you have chosen a right-hand axis system. That is, looking down on the printer the +Y direction should be 90 degrees anticlockwise from the +X direction. If instead it is 90 degrees clockwise, you have a left-hand axis system, which will give you mirror-image prints."

But there's no note on this setting. My CoreXY is right handed, and this forum reply was the answer I needed. Maybe the doc could be updated?

@phaedrux I'd love to see your results! You really shouldn't have to print more than a half inch to really see any issues(if you have any at all). Thank you!

I'll give that a go, thanks.

I feel like you're missing a step in the calibration. I would think your Z offset should be something other than zero. If you are doing all of the steps, then zero should be your nozzle touching the bed.

The numbers should be equal when the printer is idle. Do you have a sequence of operations that leaves them not equal?

After trying to machine some small Aluminum parts, I had problems even at 1200mm/min. In the end, after doing a lot of tests and studying the problem, the CAM processor is the main culprit. I use a lot of trochoidal milling as it produces much better results on a not-so-rigid machine. The CAM software produces some sudden direction changes in specific situations, so specific that many times they do not happen at all.

I have found a pattern that easily reproduces the problem. In the end it was the maximum jerk being too high! 900mm/min instantaneous speed change for an 10kg gantry is anything but normal. Maximum feedrate of the WorkBee is 2500mm/min!

Hello, new use here in the forums. I'm the author of the Filaswitch tool and pondering about how to fix this temperature problem. I've previously had a Marlin based board and with it, tool change after M104-command doesn't force the temperature to change to something that was set for that tool. So Marlin seems to behave differently in this regard.

In Filaswitch the temperature change is initiated before the actual tool change, just to make sure that nozzle is closer to correct temperature before new filament is fed to the nozzle. So for example we have active tool T0 (210C) and we are going to be switching to T1 (220C). The sequence would be:
T0
.
.
.
M104 S220 T0
(filament long retract g-code...)
T1
(filament long feed g-code...)

If I understand correctly, in Duet the tool change will result in the temperature being changed to whatever T1 is set to be.
So perhaps the fix would be:
T0
.
.
.
M104 S220 T0
M104 S220 T1
(filament long retract g-code...)
T1
(filament long feed g-code...)
.
.
.
M104 S210 T0
M104 S210 T1
(filament long retract g-code...)
T0
(filament long feed g-code...)

Support for G10 is a possibility, but will need more time as I need to understand all the changes the new command entails.

If you switch to the Console page there should be a message saying what sort of heater fault occurred. See https://duet3d.dozuki.com/Wiki/Spurious_heater_faults_and_how_to_avoid_them.