@chrishamm yes, it is. great. thank you... now everything is fine

@Triet

M80

See the sub note in M81

@gloomyandy It happens after I print a tall print. I have a lot of crash avoidance logic in my gcode that uses the G60 coords to make sure the bed is at a safe height during less determinant situations.

@DTinNC you can try running the board in AP mode creating it's own WiFi.

@jay_s_uk Hi, thank you, I updated my config file, and if I encounter HardFault again I will definitely write back

@chrishamm I bumped it up to what I believe is the max, 115200, and it's still inconsistent.

@chrishamm said in DWC White Page only in CHROME:

@zemlin What WiFi server version are you using and do you have FTP/Telnet enabled as well?

The duet wifi server is 2.1.0 on all three machines.

FTP and Telnet are both disabled.

; Network M552 S1 ; enable network M586 P0 S1 ; enable HTTP M586 P1 S0 ; disable FTP M586 P2 S0 ; disable Telnet

@droftarts said in Possible object model error:

I'm sorry, but you'll have to ask @chrishamm why it works! I think it changes the data type to a string.

ok 😂

@santy none that I can think of for four extruders.

Ian

@SanderLPFRG It's listed as 'technically possible' in the restrictions section, here: https://docs.duet3d.com/User_manual/RepRapFirmware/CAN_limitations#semi-permanent-limitations. I'm not a programmer, so I don't know what firmware changes would be needed. One for @dc42.

I think the main reason for no analog support on toolboards is slow update. A digital signal is faster than an analog signal to compute and send over CAN, particularly when you need to control motors to stop eg when homing axes. An FSR board that outputs a digital signal might be an easier option, eg https://github.com/JohnSL/FSR_Endstop, then you can use probe type 8.

As far as I'm aware, the SZP sends a digital signal. The MCU on the board is dedicated to converting the eddy current reading, so there is less overhead.

Ian

@dc42 thanks it all worked.
Problem solved.

@Ant1 It sounds like the object model response is too long so RRF fails to send it over. A plugin can only request the object model from DCS, which keeps a copy of it for all other applications, so I don't think it's the dsf-python call that is responsible for that problem.

Please do update to the latest version (3.5.3) because I'm quite sure we had to implement a different query method for tools[] and move.axes[] for large configurations.

@davidjryan It's /usr/bin/launch-dwc that invokes Chromium which then displays DWC. There was a problem in the 3.5.2 bookworm build which could lead to issues opening Chromium but that should be fixed after an update to 3.5.3 or newer.

@dc42 said in v2.0 consistently increasing probe heights:

@oarjjj gave you verified that all the boards are now running 3.6.0-beta.1 ?

Any other ideas?

@Phaedrux Wow, I can't believe I missed that. Everything seems to be working perfectly now.

Thank you for all the help.

@oliof

G1 X20 Y505.0 F10000 ;G1 X420 F10000 ;G1 X20 F10000 G1 Y55 F40000 G1 Y505 F40000 G1 Y55 F80000 G1 Y505 F80000 G1 Y55 F120000 G1 Y505 F120000 G1 Y55 F160000 G1 Y505 F160000 G1 Y55 F180000 G1 Y505 F180000

I have modified the feedrate over time but has the same principle

@dc42 Legendary, thank you! I'll be watching for the next update and ready to test.

@dc42
hello
Do you have news
tks

@Fuzionline
hello
Do you have news
tks