Posts made by 4lathe

Just wanted to say this was resolved. I don’t know why I hadn't tried this but I hit the Reset to Default button in DWC and it cleared up the problem.
I would tag this Solved but don't know how to.

Yes there are values. As I said when I revert to the old DWC interface it works fine. All the temp values are selectable in the pull downs.

@Phaedrux or anyone else experiencing this?

@Phaedrux I went to 3.1.1 and same thing. Tool is sekected, both bed and tool show active, but when I click on temp dialog to bring up list of temps to select from, it does nothing. Same for bed or hot end.
If I revert to old dwc, the temp dialog boxes work properly.

Moved my Railcore from 3.01 to 3.1 and DWC the same. The drop downs for temperature don't work. Nothing happens when I click on them. When I revert to old dwc using the button, it works properly. I went through the release notes but didn't see anything.
Any help much appreciated!

Here’s the bed.g

M561     ; clear any bed transform

; bed.g file for RepRapFirmware, generated by Escher3D calculator
; 10 points, 6 factors, probing radius: 80, probe offset (0, 0)
G30 P0 X0.00 Y80.00 Z-99999 H0
G30 P1 X69.28 Y40.00 Z-99999 H0
G30 P2 X69.28 Y-40.00 Z-99999 H0
G30 P3 X0.00 Y-80.00 Z-99999 H0
G30 P4 X-69.28 Y-40.00 Z-99999 H0
G30 P5 X-69.28 Y40.00 Z-99999 H0
G30 P6 X0.00 Y40.00 Z-99999 H0
G30 P7 X34.64 Y-20.00 Z-99999 H0
G30 P8 X-34.64 Y-20.00 Z-99999 H0
G30 P9 X0 Y0 Z-99999 S6

G1 X0 Y0 Z150 F6000 ; get the head out of the way of the bed

I do a g28 then usually 3 or 4 g32’s until they converge so it does have a z=0 ref point although now modified by the g32 adjustments to the bed plane. I didn't think I should use g28 Before the g29 as that would reintroduce endstop switch slop. I wasn’t sure whether doing the straight g30 Before the g29 would mess with the g32 calibration in some way or whether to go straight from g32’s to g29.
But you are saying
G28
G32
G30
G29
Is definitely the sequence?

I have a delta that uses endstop switches to home the carriages and fsr’s for bed probing. I have always used G32’s for bed calibration and thats worked fine. My pei on one of my mag sheets has been sanded so much that its sort of uneven so I took to using G29. So I first do G28, then several G32’s until before and after converge to .020.
Then comes the question. Should I do a G30 before doing the G29?
If I go straight to G29 after my G32’s converge, I often get a message about the mean difference being large and to rezero then redo G29.
What is the proper sequence when z=0 is really determined by a bed probe using fsr’s?
Thx in advance.

Thx folks. That was it. Lazy and stupid of me. Sorry

Bed Heater no longer Visible after Updating to 3.01-rc12

https://forum.duet3d.com/topic/16204/bed-heater-no-longer-visible-after-updating-to-3-01-rc12

I updated from ( I think rc6) to rc12 today. Did DWC to 2.1.7 and DuetCombined IAP as well.
The bed heater no longer is displayed in DWC or PanelDue, but M308 S0 yields,
m308 s0
Sensor 0 type Thermistor using pin bedtemp, reading 19.1, last error: sensor not ready, T:100000.0 B:3950.0 C:0.00e+0 R:4700.0 L:54 H:-9
This all worked fine before the upgrade.

Board: Duet 2 WiFi (2WiFi)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-RC12 (2020-05-06b1)
Duet WiFi Server Version: 1.23

Thx for any suggestions!

@dc42 just to wrap this up, I got the resistors. The values with the 1k and 2.2k were with .5degrees. I then redid the t,b,c values using the slice table but at a narrower range - 190 to 270. The results with the 2 meters are now 2.5 degrees low at 220. Good enough for the government. My printing is all close to that anyway.
Thx for the help!

Using Duet wifi and 3.01 rc2. I will get the resistor and start with checking that.

M308 S1 P"e0_temp" Y"thermistor" T500000 B4723 C1.196220e-7    ; Slice high temp thermistor from configurator
M308 S1 P"e0_temp" Y"thermistor" T500000 B4682 C1.143895e-7     ; Slice from DC42 thread with forum member

I know this has been covered before and I have tried both of these M308s with my Hemera and copper heat block. However in both cases the temperature I read on 2 different thermocouple meters( a fluke and another nist traceable meter) are 14 degrees below what dwc shows @220c. The thermocouple probes were under the silicone sock next to the nozzle. No portion of the leads leading to the probe were exposed. I have used these meters and technique on v6’s and never read more than 3-4 degrees cooler than dwc read.
Is there any way to just configure an offset? The difference @250 is 16 degrees so close to the same. Thx

Thank you so much! That was it.

@dc42 copied it to the sd card, restarted, m997 and same old 3.0 beta 12. Any other thoughts?

2/27/2020, 11:09:05 AM m122
=== Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.0beta12 running on Duet WiFi 1.02 or later Board ID: 08DGM-95BNL-MGPSJ-6J1D0-3SD6L-1JZZX Used output buffers: 3 of 24 (15 max) === RTOS === Static ram: 25812 Dynamic ram: 97284 of which 96 recycled Exception stack ram used: 256 Never used ram: 7624 Tasks: NETWORK(ready,1036) HEAT(blocked,1184) MAIN(running,3664) IDLE(ready,200) Owned mutexes: === Platform === Last reset 00:01:55 ago, cause: software Last software reset at 2020-02-26 19:23, reason: User, spinning module GCodes, available RAM 7360 bytes (slot 2) Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 0.0ms, max retries 0 MCU temperature: min 29.0, current 29.5, max 29.8 Supply voltage: min 24.2, current 24.3, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: standstill, SG min/max not available Driver 1: standstill, SG min/max not available Driver 2: standstill, SG min/max not available Driver 3: standstill, SG min/max not available Driver 4: standstill, SG min/max not available Date/time: 2020-02-27 11:09:03 Cache data hit count 399321780 Slowest loop: 2.27ms; fastest: 0.09ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Move === Hiccups: 0, FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms Bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 === AuxDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 Stack records: 2 allocated, 0 in use Movement lock held by null http is idle in state(s) 0 telnet is idle in state(s) 0 file is idle in state(s) 0 serial is idle in state(s) 0 aux is idle in state(s) 0 daemon is idle in state(s) 0 queue is idle in state(s) 0 autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 200.45ms; fastest: 0.08ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) HTTP sessions: 1 of 8 - WiFi - Network state is running WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 2 WiFi firmware version 1.23 WiFi MAC address 2c:3a:e8:0b:27:5b WiFi Vcc 3.39, reset reason Turned on by main processor WiFi flash size 4194304, free heap 24552 WiFi IP address 192.168.1.229 WiFi signal strength -66dBm, reconnections 0, sleep mode modem Socket states: 0 0 0 0 0 0 0 0

Can I just copy it to the sd card and reboot?

With all the machines and all the upgrades I’ve done over years, thats never been necessary. Why now?

I have updated all my machines to RC2 and all except the problem child have been upgraded regularly in the rrf3 path. I had one machine that was still on 3.0 beta12 and just tried to upgrade it 3 times. Says it completes properly asks to restart and does, but no go. It remains on beta12. Any hints much appreciated. I am on 2.0.7 dwc

Board: Duet WiFi 1.02 or later
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.0beta12 (2019-11-02b1)
Duet WiFi Server Version: 1.23

Just went and read the thingiverse page you referenced. Did you look atthe before and after photis in the tl smoother section? His theory was bowden tubes absorbed some of the extruder fluctuations that got highlighted with direct drive. Tl smoothers fixed it for him. Not that we need tl smoothers with the duet boards (well the maestro drivers are different from the duet wifi) but maybe theres something there?