Topics created by Hornetrider

@hornetrider Please post your full config.g and RepRapFirmware version (send M115).

My guess right now is that the x-axis driver on the board or the wiring to the motor might have an issue.

To test, you could swap X and Y motor wiring and see if the problem swaps to the Y axis. You will need to update the driver assignments in config.g: assuming your M584 is something like M584 X0 Y1 Z2 E3, swap the assigned driver for X and Y, ie M584 X1 Y0 Z2 E3.

Is there a way to run a diagnostic procedure to find any issues?

For diagnostics, run a print until you get some loss of steps, then send M122, and post the response.

In case the driver should be the problem, is there a possibility to use the E1 driver instead for the X-Axis?

If the E1 driver is free, then yes. Again assuming your M584 is something like M584 X0 Y1 Z2 E3, change the assigned driver for X, ie M584 X4 Y0 Z2 E3 and move the X motor wiring to the E1 driver connection.

Ian

@dc42
So no change in wifi connection handling?

@Phaedrux
thx. It works fine with the example.
Should have known that there is documentation arround 🙂

The default CAN transmission rate for Duet 3 is 1Mbit/sec. We plan to use 4Mbit/sec for the higher data rate when we turn on bit rate switching.

thx for clarifying.

Klipper also has a TUNING_TOWER command. Perhaps a tuning_tower gcode could be implemented.

MXXX P’MYYY P<Val>’ Lmin Ffactor Bband
Where MYYY P### is emitted for each layer. Might require some slicer conventions to indicate layer start. Could also just emit this when Z changes, unfortunately including z hops...

Klipper doc:
TUNING_TOWER COMMAND=<command> PARAMETER=<name> START=<value> FACTOR=<value> [BAND=<value>]: A tool for tuning a parameter on each Z height during a print. The tool will run the given COMMAND with the given PARAMETER assigned to the value using the formula value = start + factor * z_height. If BAND is provided then the adjustment will only be made every BAND millimeters of z height - in that case the formula used is value = start + factor * ((floor(z_height / band) + .5) * band).

@Danal said in Duet 3 Standalone RRF3 Package?:

@Hornetrider said in Duet 3 Standalone RRF3 Package?:

@Danal

used this files right before my last post...
Still got the error and then tried it by renaming the IAP, and then something worked..kind of..

Yeah, depending on what release you are coming FROM, there may be some renaming involved.

There should be no need to do any renaming. But you should have both the old and new IAP files present. They have different names deliberately because they are not compatible.

In standalone mode, to upgrade from any published version of RRF3 for Duet 3 RRF prior to 3.0RC1, file Duet3iap_sd_MB6HC.bin must be present in /sys.

To upgrade or downgrade from any published version of RRF3 for Duet 3 RRF at or after 3.0RC1, file Duet3_SDiap_MB6HC.bin must be present in /sys.

If you have used M505 to put the system files in a subdirectory of /sys, when you upload the IAP or firmware files you make sure that you are viewing /sys in DWC, because firmware files (unlike config.g, homing files etc.) must always go in /sys regardless of the M505 setting.

The requirements for upgrading/downgrading via an attached RPi are similar except that the IAP files are Duet3iap_sbc_MB6HC.bin (when upgrading from older firmware) and Duet3_SBCiap_MB6HC.bin (when upgrading/downgrading from 3.0RC1 or later). These files are normally installed by apt-get-upgrade.

In my experience, yes. I'd still hook up the tach signal, but you can't trust the RPM reading when controlling the speed. However if I recall correctly it'll still be usable as a running/not running feedback, at least with the fans I tested.

Thanks T3P3Tony and Danal

I will check it out.

And the Distribution board here:

https://github.com/Duet3D/Duet3-Tool-Distribution-Board/tree/master/Tool Distribution v0.5

I'm not sure all the priorities, etc. but if the macro file is empty surely it shouldn't pause? Try throwing a M25 in the Filament-change.g file to see if it pauses properly when the sensor is triggered.

@hornetrider no currently - worth adding it as a topic in the firmware wishlist category.

its all open source ..

https://github.com/T3P3/FilamentMonitors/tree/master/Filament_Monitor_Laser_v1.7
and
https://github.com/dc42/RepRapFirmware

i believe

@dc42 U3 is gone. There is a crater. I have contacted my dealer to find a solution

@dc42

Thanks for the hint.
I have checked with a spare BLTouch (older one with metal pin) and found that something with the cables was not good.
Re-Cabled the signal line (white/black) with a brand new cable et voila, it's working again.

I think I will have to re-do all the cabling to assure functionality....but for now it's working.

Thanks for the support.

@lael
PLAOffset:
; M-MAX (printer's name, I have two)
M291 P"PLA Offset" S0 T5 ; Show which one called
G31 P500 X25 Y45 Z1 ; set threshold and offsets - z offset is last one - increase to get closer to the bed
M207 S1.5 F6000 R0 Z0.03 ; firmware retraction

Firmware retraction may need changing for different filaments, so far they don't. I have another one for PETG, it needs a different Z offset. I call this in the start gcode in PrusaSlicer. Editing a macro is faster than rebooting the Duet.

UPDATE

Fault found.

As the temp signal was always spiking below the set-point I wasn't sure about the source. But a new 2000 spike brought me back on track...
In the end the cable from board to thermistor had a failure. Just connected a new on the fly and the signal was rock solid again.

I also connected the frame of the printer to Earth, this already lowered the spikes but it also brought me the 2000er.. 🙂

So, in the end I also installed the BLTouch that I had in stock, now the mesh is also free of spikes...

Thank you all for your support.

Fans can be named too (sere the M106 link above), but I don't know whether named fans are displayed in DWC2 when they are thermostatically controlled.