Topics created by kazolar

@dc42 my voltage is 24.5 -- doesn't vary, my power runs are short and using 16awg wire, the PSU I have been using is rock solid rated at 600w, using no more than 200w, so that is not an issue.
A little update, I've installed the new board in SBC mode and upon migrating config, some entries which were fine in standalone (screen console and dwc never had them as problems) showed up as errors now
M350 -- I had defined Y16:16 U16:16 -- it didn't like that -- I suspect that has to do with M906 definition prior -- it appears that version 3.6 is not as forgiving for these type of entries -- though why is it an error in SBC mode and seemingly ok in standalone.
Also one of my homing routines had a line like this
G1 V 700 F6000 H1 --
on standalone that was OK, in fact it ran and homed the axis perfectly fine -- in SBC mode it didn't like the space between V and 700.
I'm now leaning away from a dead/dying driver (since 2 drivers randomly dying and after m906 change at least one of them seemed to be fine, and more toward some randomness to how config is read and accepted -- SBC mode with 1.02 main board my not so perfect config was forced to be fixed, standalone -- screen console never had any errors about these entries.

@kazolar for touch mode it's the same as for any other probe type, use the A parameter in the M558 command that configures the probe. There isn't a facility to do multiple scans in scanning mode.

@kazolar said in Odd bed mesh:

Wondering if there are plans to true zero like beacon/cartographer do to auto calibrate my understanding all they're doing is measure variations in eddy currents until they stop changing meaning nozzle touched the bed.

From the 3.6.0-beta.3 release notes:

[Duet 3] Experimental support for using supported scanning inductive Z probes (i.e. Duet3D Scanning Z Probe and TOOL1RR tool board) in touch mode is available. This support is enabled using the new M558.3 command. See https://docs.duet3d.com/en/User_manual/Tuning/scanning_z_probe_calibration#using-the-szp-in-touch-mode-to-set-z-height. Use it with caution!

@kazolar if it draws less than 600mA even on startup/max revs then it will be fine

@dc42 hopefully you know what changes made it work now.

I don't think there's anything to worry about. If and when MCU temp probe calibration becomes available for expansions it would be an easy fix.

@dc42 I figured out I don't need to define individual axis anyway, just combine the end stops. No need for extra axis -- would be good if M119 would report the state of each end stop pin in the combined M574 definition. No good way to be sure you have the right end stop configured with the right stepper.

I did this
M584 Y0.5:0.0 U0.4:0.1 X0.2 V0.3 W2.2 A1.2 E1.0:1.1:2.0:2.1 Z3.2:3.1:4.2:4.1
M574 Y1 S1 P"io3.in+io1.in"
M574 U2 S1 P"io6.in+io4.in"
M574 X1 S1 P"io8.in"
M574 V2 S1 P"io2.in"
M574 W2 S1 P"2.io0.in"
M574 A1 S1 P"1.io0.in"
M574 Z1 S1 P"3.io0.in+3.io1.in+4.io5.in+4.io4.in"

that works fine and no extra axis definitions.

@kazolar Ref cooling the control boards, what I did on my old Duet Ethernet +Duex 5 setup was to attach thermistors to a couple of the driver chips with a small blob of epoxy adhesive, and use these to thermostatically ramp cooling fans (IE, fan speed increased with driver chip temperature). With my Duet3 setup, I've found that additional board cooling isn't necessary despite some of the motors being NEMA 23s @2.4 Amps. But my boards are all vertically mounted and "open" rather than enclosed so your mileage may vary.

@bberger i think I found the issue. Part mechanical, part software. One of the upgrades I did was move the extruder really close to the hotend -- so the bowden tube is now maybe 25 mm tall, so my previous .02 pressure advance was basically messing up and not extruding where it should be. I tried .01 -- seems better, at least it's not - not extruding, where it should be. The other bit was my extruder sherpa mini which I rebuilt, started had a problem in the MJF glass nylon parts -- replaced with printed ABS body, and like night and day, not perfect, not yet -- I think the stepper got a bit damaged in the process, so needs to be swapped to, and I'll swap all the internal bmg gears to be safe, i think the nylon gear got a bit worn out, but looks like it there was an issue of binding maybe in repeated retractions, and the gears would slip, so the big nylon gear needs to go -- seems the mjf body is not stiff enough or some other property. Pretty sure after I replace all the extruder parts, it will be printing perfectly.

@kazolar said in DWC 3.2 Layer Chart broken:

Duet 2 Ethernet 2.05.
DWC 3.2

Firmware 2.05 and DWC 3.2? If that's the case and you want to stick with RRF2, you should stick with DWC 2.0.7.

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

@dc42 I think M585 does it -- I just tried it -- and it looks like it set my offset correctly. Will make a rigid mount for my button and do more tests.

You may have to wait for this then.

https://forum.duet3d.com/topic/18289/emergency-stop-without-m112?_=1598135041994

I have a microsoldering station, and I looked at all the solder joints under high magnification, and touched up all the affected diode pins with a micro soldering tip -- and got 1 1/2 drivers to function -- 1/2 is one that was totally dead is now half dead, it didn't move at all before, but now moves but stutters so assuming is I only fixed 1 phase, so there are more cold solder joints. 1 which was previously dead I did not revive -- cleaned everything with alcohol, can see on one that there is bear copper next to the diode, and I can't flow solder there without fully removing the diode and starting fresh ...I've already contacted filastruder. Discussing with them regarding doing an advanced replacement -- which unfortunately is not free -- since it would require a 3% credit card refund charge.

@dc42 ok, so, normal condition for the triplicate print is the 4th tool is inactive and is parked and obviously triggering an endstop, the heat up actually starts right after the probing completes and several optical end stops are triggered at that point. I have an option to run gcode that backs them all off the trigger point, I'll do that next time, but unlike the i2c emi issue, this one is really hard to hit, it happens ones every 5-10 days.

@kazolar said in Duet 2 underruns high loop times stuttering:

@dc42 ok -- I fixed my 2.05.1 -- now it's running on that version. I'll look at 3.0x for i2c count for debug -- see if I can add that in there -- I just don't know what are good or bad numbers -- what's considered high?

You should get a small number of i2C transactions recorded whenever an endstop or GPIO input on the DueX changes state. That's all. There are additional i2C transactions when DueX fan speeds change, but those are not counted in the stats.

@dc42 had a reset with most recent 2.05
Happened during homing of the gantry axes. Seems this started happening when I started using

M42 P7 S255 and G4 as part of the homing routine

Here is my home gantry -- I need to use the G4 commands to make sure the homing switches which M42 command toggle are enabled correctly.

M42 P7 S255
G4 S1
G91
G1 V700 W700 A-700 Y-700 U700 X-700 F2500 S1
G1 Y3 U-3 X3 V-3 W-3 A3 F300 S2
G1 Y-20 U20 X-20 V20 W20 A-20 F50 S1
M579 U1
G90
G4 S3
M42 P7 S0

=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.05 running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DGM-9T6BU-FG3S0-7JTD4-3S06K-1A4ZD
Used output buffers: 3 of 24 (10 max)
=== RTOS ===
Static ram: 25708
Dynamic ram: 96296 of which 0 recycled
Exception stack ram used: 320
Never used ram: 8748
Tasks: NETWORK(ready,748) HEAT(blocked,1236) DUEX(suspended,168) MAIN(running,3756) IDLE(ready,156)
Owned mutexes:
=== Platform ===
Last reset 00:00:27 ago, cause: software
Last software reset at 2019-12-22 23:37, reason: Stuck in spin loop, spinning module GCodes, available RAM 8372 bytes (slot 3)
Software reset code 0x4043 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x2000323c Task 0x454c4449
Stack: 00445ac9 00444abc 61000000 a5a5a5a5 00445ac9 a5a5a5a5 a5a5a5a5 20003264 20003104 00000002 200048ec 02c344a8 20001780 20004cf4 20003264 20004cec 00000004 20001794 200030dc 20003264 200030d4 00000001 200032bc
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 23.3, current 23.9, max 24.0
Supply voltage: min 24.7, current 24.7, max 24.9, 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
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2019-12-22 23:38:17
Cache data hit count 52619560
Slowest loop: 8.09ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 160, MinFreeDm: 160, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
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: 1 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: 6.76ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplex

thanks for confirming that.

@NitroFreak I have a relative lift of 0.6mm in the freeX.g command, then then park the old tool to it's appropriate corner, then in the postX.g script the selected tool is wiped and then slicer gcode moves it to the appropriate xy location, then to its appropriate z position, this allows the tool travels to occur without colliding with the print and without contamination. At some point the firmware was changed to restore the z position prematurely. Which I don't want to do...hence I commented it out in the source code and built a new binary, I did a few calibration tests and it works much better, no nasty contamination stringing.