Posts made by jltx

Does the tool board come with uncrimped pins or do I need to source those myself? e3d told me the leads on the Roto extruder are 1m long so I would need to remove 90% of the wire and reposition the connectors to use this tool board mounted locally.

Does the roto toolboard come with scanning z probe coils? I don’t see where to get those separately.

@sebkritikel Awesome news! Thank you.

I read that reprapfw input shaping does not support mixing steppers between main board and stepper remote on can bus. The tool boards that control an extruder are on can bus. I need input shaping to control axis and extruder steppers together. So how does this work? Did I read that wrong (I hope)?

@dc42 I did check the console and it had no errors reported. But I’m not clear that it captures anything when my laptop is asleep. I feel like it skips over anything incoming while asleep.

Is there a mode I can set the treats M0 like M1? I can’t ever think when I’d use M0. I never have before. More likely I think is your theory on SD read error (though I don’t know what that would happen either, just more likely). But wouldn’t that get captured in M122? Also the failure mode there should be a pause by firmware to allow for restart, e.g don’t turn off bed heater or motors and send warning. I was lucky that I happened to catch it. I was about to go to bed and it would have been ruined the next morning.

@dc42 no errors in console. I have a 12864 display. If an errant M0 were somehow emitted would that status screen show 100% complete?

@jltx @dc42 is this a known failure mode? can firmware detect and report? I'm hesitant to start any long prints now.

@bot I don’t know how to read that log either. Driver 5 is also only one with a timeout, so may be a real issue.

Driver 4 is unused which might explain the read error there.

I forgot I took a screenshot at failure. Notice it thinks it is 100% complete, though Z is 25 when final should be 66 for this print. The heaters are off but have active temps. I have not seen that before.

I noticed my printer was awfully quiet and when I checked I found it had just stopped with the head parked in the middle of doing some infill. The heaters had shut off and were cooling. The 12864 had some conflicting info where it showed the heaters still on but they were not, but otherwise showed printer was in a non-printing state. I checked DWC and found no errors. The status page said job completed but clearly it was not. I dumped a M122 shown below.

Luckily I was able to use M114 and G92 in a hacked gcode to recover the last 7 hours of the print. But I’m disturbed that it just ended early without errors. I just simulated the original file and it completed without error. The line it stopped on during the print was in a stretch of uninteresting G1 commands. Any other areas to investigate?

1/3/2022, 11:13:36 PM: M122: === Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.4.0beta7 (2021-12-16 12:22:56) running on Duet 3 Mini5plus WiFi (SBC mode)
Board ID: RNXYU-8296U-D65J0-40KMW-2503Z-ZP7HW
Used output buffers: 1 of 40 (12 max)
=== RTOS ===
Static ram: 103460
Dynamic ram: 104412 of which 0 recycled
Never used RAM 30144, free system stack 118 words
Tasks: SBC(ready,138.9%,480) HEAT(notifyWait,1.3%,342) Move(notifyWait,87.1%,273) CanReceiv(notifyWait,0.0%,942) CanSender(notifyWait,0.0%,358) CanClock(delaying,0.4%,331) TMC(notifyWait,37.6%,105) MAIN(running,121.3%,484) IDLE(ready,0.2%,29) AIN(delaying,25.3%,264), total 412.1%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 29:39:08 ago, cause: software
Last software reset at 2022-01-02 23:34, reason: User, none spinning, available RAM 30824, slot 2
Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00487000 BFAR 0xe000ed38 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
MCU revision 3, ADC conversions started 106756829, completed 106756829, timed out 0, errs 0
Step timer max interval 1479
MCU temperature: min 20.8, current 22.1, max 32.2
Supply voltage: min 23.7, current 23.9, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/84/84, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: pos 31583, standstill, SG min 0, read errors 0, write errors 1, ifcnt 105, reads 2294, writes 14, timeouts 0, DMA errors 0, CC errors 0
Driver 1: pos 10279, standstill, SG min 0, read errors 0, write errors 1, ifcnt 188, reads 2287, writes 21, timeouts 0, DMA errors 0, CC errors 0
Driver 2: pos 20360, standstill, SG min 0, read errors 0, write errors 1, ifcnt 188, reads 2287, writes 21, timeouts 0, DMA errors 0, CC errors 0
Driver 3: pos 0, standstill, SG min 0, read errors 0, write errors 1, ifcnt 188, reads 2286, writes 21, timeouts 0, DMA errors 0, CC errors 0
Driver 4: pos 0, standstill, SG min 0, read errors 1, write errors 1, ifcnt 59, reads 2298, writes 9, timeouts 0, DMA errors 0, CC errors 0
Driver 5: pos 0, standstill, SG min 0, read errors 0, write errors 1, ifcnt 188, reads 2286, writes 21, timeouts 1, DMA errors 0, CC errors 0, failedOp 0x6c
Driver 6: pos 0, standstill, SG min 0, read errors 0, write errors 1, ifcnt 188, reads 2286, writes 21, timeouts 0, DMA errors 0, CC errors 0
Date/time: 2022-01-04 05:13:35
Cache data hit count 4294967295
Slowest loop: 1057.14ms; fastest: 0.09ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 0.0MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 35, maxWait 31364ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 5538039, completed 5538039, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 2], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1, chamber heaters 3 -1, ordering errs 0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File* is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue* is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== CAN ===
Messages queued 960761, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 17 (min 17), ts 533744/0/0
Tx timeouts 0,29,533743,0,0,426986 last cancelled message type 4514 dest 127
=== SBC interface ===
Transfer state: 4, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 31931/31931
SPI underruns 0, overruns 0
State: 5, disconnects: 1, timeouts: 1, IAP RAM available 0x0f918
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.4-b7
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 41.80, max time between full transfers: 48.2ms, max pin wait times: 32.3ms/10.7ms
Codes per second: 0.00
Maximum length of RX/TX data transfers: 3528/132

@fcwilt
That's clever. I'll have a think about that.

@phaedrux said in mesh results inconsistent with leveling:

Does that mean the probing is done cold?

No, you can probe whenever you want. I really don't know why that designed it that way.

@zapta I looked at klicky but I don’t think I have enough room. Unless the magnetic sled can discriminate only a few mm for pick up I will lose part of my rear bed trying to avoid accidental mounting.

@phaedrux i believe they use a hybrid setup because the inductive probes are very sensitive to temperature. If I were to ignore the endstop and try to just use the probe I would have no way to actually set Z=0, at least no confidence that I was anywhere close at a given temp. The endstop can move a little too with thermal expansion but it seems pretty small by comparison.

@gloomyandy @fcwilt I’m still not clear on the purpose of the Z=0. Maybe the confusion is I have a Voron with a mechanical Z end stop that is used to set the tool Z relative to bed. The inductive probe is only used to level the bed and probe a mesh for bed correction. All of that is relative. Do I need this extra step of Z=0? What exact command would that be? Since I’m not currently doing that, what bad things might happen? I appreciate the help.

@fcwilt said in mesh results inconsistent with leveling:

@jltx said in mesh results inconsistent with leveling:

@gloomyandy I got bootstrapped from someone else’s config and they did not have that. So no good reason. Are you saying doing a G30 S-2 at one of the leveling points?

I tried to do 5 points and unfortunately my bed is so whacked it cannot find a solution within 0.02.

There is a process called Setting the Z=0 Datum. This involves moving the probe to a fixed XY location, like the center of the bed, and then executing a single G30.

This process needs to be done:

• after leveling the bed with G32
• before creating a height map with G29 S0
• before locating that height map with G29 S1

OK. I did not see that documented in https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors
I have been printing just fine without doing that. But I will update my macro. Thanks.

Bed leveling can be done multiple times as needed. Using the condition code features of firmware 3.3 and later you can put code into bed.g that will run the leveling process until specified degree of levelness is obtained.

right, I do exactly this. See my bed.g posted above.

Frederick

@gloomyandy I got bootstrapped from someone else’s config and they did not have that. So no good reason. Are you saying doing a G30 S-2 at one of the leveling points?

I tried to do 5 points and unfortunately my bed is so whacked it cannot find a solution within 0.02.

@gloomyandy Is it important to re-zero the Z to the level point? I assumed this would all be compensated correctly. My Z endstop is not a Z=0 so I adjust for that in my G31. If I run a G30 and this changes where Z=0 is on every run due to temp variation, etc. won't that screw up my offset? I need to mull on that.

So over sampling the bed in leveling is ok? The algorithm with do a good job averaging? I can try that. I think I will avoid the far left edge since it is such an outlier.

@jltx crap. I forgot I had moved my leveling points outboard a bit to get closer to the pivot points and this moved them a few mm off from my mesh points. But I thought I can't be off >0.1mm Z in just a few mm, so I took a higher resolution mesh and see that I have a horribly distorted bed. So the actual level points are much closer together in Z but if you move in just a bit you will get a large Z variation. However, the (now) precise leveling points are still not within the tolerance that leveling established. I'm seeing 0.013 delta (much better than 0.1) which is higher than the 0.001 coming out of leveling. But it doesn't rally matter when the bed is so bad. I'm not sure what happened to the plate. It used to be very flat and I treated it very gently during the rebuild.

@jltx Hold on, I'm investigating something...