Topics created by drmaestro

@drmaestro did you rerun heater tuning after installing the new heater? If so, you can get rid of the overshoot by reducing the A or R parameter in the M307 command for that heater. Try a 10% reduction.

The problem has a distinctly "hysteresis" feel about it. That is to say, that travelling in one direction does not result in the same path as movement in the other direction. Belt tension would be an easy culprit for this problem, but as such, it's the first one to be resolved.

Here's what I suggest. Isolate travel direction as the problem - Print a simple thin walled square (50x50 should do), go CW for 10-20 layers, then CCW for 10-20 layers. If hysteresis is the problem you should get the same bands appearing with direction change. I imagine you'll need to generate this code manually to control the travel direction.

If this occurs, you'll need to look for anything that gives you some uncontrolled movement - it could be as subtle as flexibility in the hot end, or a pulley (or many pulleys in the case of a CoreXY) that move slightly on their shaft. Remember you're looking for problems that add up to a total of a fraction of a line width - so perhaps 0.1mm or less.

Best of luck.

For the BLtouch in the config tool you need to choose the pins for it in the I/O page and then in the endstop page make sure you choose bltouch there.

@phaedrux

Shhh, don't tell my fans that

@drmaestro

I am running my 2 fans on the hotend in parallel

@drmaestro said in Replacing a Duet WiFi with a new one:

Does this sequence work as a way to clone the old Duet and copy to the new Duet? Does it work?

There the odd edge case, like the board not having been updated with DWC/IAP before cloning. But in general it should work - while I haven't specifically tried cloning a running Duet I've used the second half to get a new board up and running with 2.05.1.

You can skip the FTP part and just copy files from the old sd card to your computer and then to the new sd card. (Or even just move the old sd card to the new board, download the matching reprap firmware and flash it with bossac (my approac was primarily aimed at zapta who wanted to clone an existing (and presumably running) board.

The only real "trick" is to use bossa(c) to flash rrf to the board ensuring no problems due to missing or renamed files between what version the new board is delivered with and what you had running on the old. Followed by updating the wifi module and setting the wifi key; the rest is contained within the SD card.

@drmaestro said in Burnt heated bed connector:

Here, I took a picture:

oh, that't not gonna scrape off..

(Lacking other info I assumed it was a Maestro board from the nickname - that board has the two positives adjacent each other and an easy bridge to make)

on the other hand, you could run the Bed+ to the Vin+ terminal, or directly to the power supply if the Bed- connector and mosfet is still good. (and get some ferrules or terminals on the high current wires if at all possible)

@drmaestro said in Bug or security feature?:

If the Z height at this moment is lower than the deployment height, then you go into the error state I've mentioned and it can't be corrected by resetting BLTouch and also you can't solve it by any gcode because no g code is being used at that moment.

The gcode I posted is exactly for this situation. Placed at the end of config.g for power on, and at the start of homeall/homez it's able to clear any error state. And if your homing file has a G1 H2 Z command to raise the Z by at least the trigger height of the BLTouch you're good to go.

@dc42 said in Does bed.g serve a purpose on a cartesian printer?:

Instead you specify the limits to be probed, and either the spacing between points or the number of points.

Yes, that's how G29 works. You yourself made an example of how to do it point by point for delta. Why would the same thing not work for cartesian?

given you have clearance I'd consider using a cam package to make the g-code it will handle fixtures and safe z heights. overkill perhaps, but also easy

@drmaestro said in Occasional G0/G1: insufficient axes homed error:

@deckingman Your crystal ball is right 😄 The homey.g file had a shorter move (the Y size is 220 but the command was 195). After the print ends the Y axis goes all the way to the end, so when restarting, 195 mm falls short. Changing it to 220 correctecd the problem.

Thanks

And for my next trick, post a picture of your hand and I'll tell your fortune. ☺

On a more serious not, glad that's fixed for you.

Those would probably work to allow you to manually control the fan speed while using the always on connector.

A simple latching switch could work too.

I would suggest reading through the update notes for the releases between 2.02 and 2.05.1 (ignoring the 3.0 releases for now) to see if there is anything that would apply to you.

https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md

I would also suggest that version 2.05 would be a good first step. There were some bug fixes and things that may apply to you. Upgrading to try it would be as simple as uploading the zip file as is. https://github.com/dc42/RepRapFirmware/releases/download/2.05/Duet2Firmware-2.05.zip

Once that has been updated you could update the two files from 2.05.1 that you would require.

https://github.com/dc42/RepRapFirmware/releases/download/2.05.1/DuetWebControl-SD-2.0.7.zip

and

https://github.com/dc42/RepRapFirmware/releases/download/2.05.1/Duet2CombinedFirmware.bin

The main difference you'd notice is the web control interface has been updated.

Hi,

An update: Changing the thermistor took care of the problem (for now at least). I still have 1 or 2 degree fluctuations but they are not spikes and I didn't run PID tuning with the new thermistor yet, so that's probably to be expected.

Thanks for the contributions...

Thanks. In either case, the solution seems to be changing the thermistor then....