@mikep91

I tried doing this but I am getting the error that no heaters is assigned

M308 S0 P"spi.cs1" Y"rtd-max31865"
M950 H0 C"bedheat" T0 ; create bed heater output on bedheat and map it to sensor 0
M307 H0 B1 S1.00 ; enable bang-bang mode for the bed heater and set PWM limit
M308 S1 P"spi.cs1" Y"rtd-max31865"
M950 H1 C"bedheat" T0 ; create bed heater output on bedheat and map it to sensor 0
M307 H1 B1 S1.00 ; enable bang-bang mode for the bed heater and set PWM limit
M143 H1 S500 ; set temperature limit for heater 1 to 500C
M143 H2 S500 ; set temperature limit for heater 2 to 500C
;M143 H3 S500 ; set temperature limit for heater 3 to 500C

@dc42 awesome, thank you!

@Drak said in Part Cooling Fan Setup:

M950 F0 C"fan3" Q200 ; create fan 0 on pin fan0 and set its frequency
M106 P0 S0 H-1 ; set fan 0 value. Thermostatic control is turned off

; Tools
M563 P0 D0 H0 F0 S"Main"

Try this better

@apak Thanks. I updated the M558 command. I also modified G31 to X0 y0 Z-0.25. This works but the only way I came to the -0.25 offset was I started a print and used babystepping to get to that offset that produced the best result. What I am trying to find out is how to create a calibration macro that will determine the correct offset and then update RRF G31 to use that offset without me having to manually change it. If you have any suggestions or resources I should look at that would be great. Thanks again.

@Herve_Smith by a "homing move" I mean any G0 or G1 command that stops when the corresponding endstop is triggered.

@MihaiDesigns no, you won't be able to manage 2m for the 10p cable.
For the 4p I would suggest using screened cable

@mfs12 Thanks for the heads up, I'll try the new version as soon as it's available. Thanks again.

@dc42 It was just a single axis I was trying to home. Sometimes it would home, do its bounce off, and then would appear to loose connection before doing the final slower homing move. When this happened it would appear to run the entire homing routine again for that axis.

I see your point about stepper motor wires, however I think this is different because it seems to be signal integrity problem rather than a broken connection, which isn't something I've ever had issues with on stepper motors. Also, since you can daisy-chain CAN boards, an issue with a single wire could also knock out lots of motors and sensors rather than a single component.

Thank you for raising the event types. I had not spotted that CAN disconnections were included. Looking at it now it says (RRF 3.5.0-beta.4 and later only) though, not RRF 3.4.0. Which one is it? I'm not against upgrading to the beta firmware if that's what it takes, however we are finding that the disconnections often last a lot less than 5s though, so I don't know if it's applicable to this scenario.

@MihaiDesigns See https://docs.duet3d.com/User_manual/Connecting_hardware/Temperature_connecting_PT100#wiring-the-pt100-temperature-sensor

PT100 temperature sensors can be wired in either a 2-wire or 4-wire configuration. 3-wire PT100 sensors are also available, but these will need to be wired as a 2-wire, or an extra wire added to be wired in 4-wire.

I think to wire it as a 2-wire, take both the wires from the side that has two wires, and wire them to the same terminal, ie side with one wire, wire goes to terminal 2, side with two wires, both got to terminal 3. Or I guess you can cut one of the wires from the side with two wires, and wire it as a 2-wire. If you can test this, I'll add a 3-wire tab to the documentation.

Ian

the io1 and io0 order needs to match the physical wiring connection, not just the motor order in m584.

@NeoDue

duhhhhh .... sorry about that, I thought I had discovered something .... alas, all I discovered that I can't read 😞

https://docs.duet3d.com/en/User_manual/Troubleshooting/Duet_wont_respond

Best to start here and let us know how far you get.

@Maestro

Thank you for taking the time to check this over. I'm most grateful.

Here's where I'm at currently with the bed, where the Earth cables for the bed frame and 3mm safety plate are loose. The cable running around the inner perimeter of the heat mat is the lead coming from the heater, to the TCO. I had thought about cutting this down, but then thought to just stick it in-place.
Hn6aHqHlQWCicklyCbeZSw.jpg

iHHt9jfWTuC2A84s6I5yhg.jpg

I've also got some of that aluminium foil/closed cell foam of various thicknesses that I can also add, to sandwich between the heater and safety sheet if want.

Thank you again for you time and input.

Dizzwold.

@droftarts New to 3.5 I think....

@Arminas Check the technical data sheet or ask the motor manufacturer if it's not included.

I don't have experience with closeLoop steppers, but from what I gathered, it requires a powerful MCU to reach same speed levels as openLoop.
Which IMHO is funny, because the main reason why I'd use CL steppers is to increase speed.

I'd like to build a Delta based on my differential belt drive. It allows us to double up the effector speed, but without running the steppers at twice the revs.
At the same time, I can choose any reduction ratio when I need higher precision.
All that would run on a Duet2 with driver-expansion

@ageis said in Duet bed not receiving power:

M950 H0 C"bedheat" T0

Which pin do you want to use instead?

Find the pin you want to use and look up it's name here: https://docs.duet3d.com/en/Duet3D_hardware/Duet_2_family/Duet_2_WiFi_Ethernet_Hardware_Overview#pin-names

Then replace "bedheat" with that pin name.

@SanderLPFRG Make sure you have specified the correct sensor orientation. This is critical so the Duet knows which accelerometer axes match your printer axes.

Check the documentation here:
How to set the orientation

and here:
https://docs.duet3d.com/User_manual/Reference/Gcodes#m955-configure-accelerometer

@izeman I've added a note to the documentation: https://docs.duet3d.com/en/User_manual/Connecting_hardware/Display_12864#overview

As of September 2023, BTT firmware still MOSTLY works with RRF. Heating, movement, monitoring prints etc works, however accessing the Duet filesystem does not. There may be other quirks that break RRF support as the firmware develops. Duet3D is not responsible for the BigTreeTech firmware; please contact BTT to get these fixed. See this thread on the forum for more information.

You could raise an issue on Github, though it looks like BTT isn't doing much of the development work. A similar issue here https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/issues/2569 seems to have gone unanswered, except for a link to this explanation, which might explain why you can't access the file menu https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/issues/2572#issuecomment-1217818116

With remote printing engaged, the TFT has no idea of the host managing the print (it can be OctoPrint or any other unknown client) so the only safe rule that can be followed by the TFT is simply to act as passthrough between remote host and mainboard (the TFT is simply providing the communication channel with the mainboard). Furthermore, the TFT does not support response forwarding for request originated by the TFT (e.g. M601). Even if the TFT supported the response forwarding, the TFT couldn't make any assumption about the handling provided by the remote host receiving the response (e.g. the remote host could discard the notification and continue the print).

For those reasons and for the concept of remote printing (something fully controlled by the remote client), the TFT's role is limited to display stats info and nothing more.

Ian

Zarrsito created this issue in bigtreetech/BIGTREETECH-TouchScreenFirmware closed [Q] BTT E3 RRF V1.1 & TFT35 E3 3.0.1 Issue or wrong config? #2569 Rneil-ca created this issue in bigtreetech/BIGTREETECH-TouchScreenFirmware closed [FR] Send Pause and Stop Command While Remote Printing #2572