@Phaedrux It's the cable that came with the accelerometer.
Posts made by tomasf
-
RE: Losing connection while trying to record motion profile
-
RE: Losing connection while trying to record motion profile
Here's M122 after a reset if that could help:
=== Diagnostics === RepRapFirmware for Duet 3 Mini 5+ version 3.4.6 (2023-07-21 14:09:13) running on Duet 3 Mini5plus WiFi (SBC mode) Board ID: MPKT6-F396U-D65J0-40KM8-3A03Z-R0UUN Used output buffers: 1 of 40 (12 max) === RTOS === Static ram: 103712 Dynamic ram: 99580 of which 24 recycled Never used RAM 38396, free system stack 206 words Tasks: ACCEL(notifyWait,0.0%,346) SBC(ready,1.3%,434) HEAT(notifyWait,0.0%,358) Move(notifyWait,0.0%,363) CanReceiv(notifyWait,0.0%,941) CanSender(notifyWait,0.0%,335) CanClock(delaying,0.0%,342) TMC(notifyWait,0.0%,124) MAIN(running,97.4%,557) IDLE(ready,0.5%,30) AIN(delaying,0.8%,273), total 100.0% Owned mutexes: HTTP(MAIN) === Platform === Last reset 00:00:54 ago, cause: software Last software reset at 2023-10-12 17:23, reason: HeatTaskStuck, GCodes spinning, available RAM 38252, slot 1 Software reset code 0x4143 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0000080f BFAR 0xe000ed38 SP 0x200134b0 Task ACCE Freestk 4294936825 ok Stack: 2001948c 20012e5c 200014e8 e000e000 000000a5 00091d55 000905a6 6100f000 00000001 e000e000 00091d55 20019074 000000c8 20019088 0008ac65 bd0ae633 00000005 3e638e37 20019074 00000005 00000006 200135a0 0008ae6d 20019074 20023ad8 20023a50 00027ac6 Error status: 0x00 MCU revision 3, ADC conversions started 54608, completed 54608, timed out 0, errs 0 Step timer max interval 1489 MCU temperature: min 28.8, current 29.1, max 29.8 Supply voltage: min 1.3, current 1.3, max 1.4, under voltage events: 0, over voltage events: 0, power good: no Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0 Events: 0 queued, 0 completed Driver 0: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0 Driver 1: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0 Driver 2: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0 Driver 3: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0 Driver 4: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0 Driver 5: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0 Driver 6: ok, SG min n/a, read errors 0, write errors 0, ifcnt 0, reads 0, writes 0, timeouts 0, DMA errors 0, CC errors 0 Date/time: 2023-10-12 17:24:35 Cache data hit count 129047879 Slowest loop: 3.63ms; fastest: 0.08ms === 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 0, maxWait 0ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], 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 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0 Heater 1 is on, I-accum = 0.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 489, received 0, lost 0, boc 0 Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 18 (min 18), ts 273/0/0 Tx timeouts 0,0,272,0,0,215 last cancelled message type 4514 dest 127 === SBC interface === Transfer state: 5, failed transfers: 0, checksum errors: 0 RX/TX seq numbers: 11189/2147 SPI underruns 0, overruns 0 State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x0f178 Buffer RX/TX: 0/0-0, open files: 0 === Duet Control Server === Duet Control Server v3.4.6 Code buffer space: 4096 Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0 Full transfers per second: 33.05, max time between full transfers: 95.2ms, max pin wait times: 34.0ms/2.5ms Codes per second: 0.49 Maximum length of RX/TX data transfers: 3716/960
-
RE: Losing connection while trying to record motion profile
I tried downgrading to RRF 3.4.6 to see if a stable version improved things, but it didn't help.
-
Losing connection while trying to record motion profile
I just installed the Duet3D accelerometer board, connected it to my Mini 5 and set it up with
M955 P0 I64 C"spi.cs2+spi.cs1"
. So far so good, but when I try to Record Motion Profile, it moves to the correct Z height, stops, and after a couple of seconds, the board resets and I getWarning: Lost connection to Duet (Timeout while waiting for transfer ready pin)
followed byConnection to Duet established
andWarning: SPI connection has been reset
.The very first time I tried it, I did get results back (but with
The selected motion profile contains overflows. It may not be accurate.
), but every time since then, I get the reset.SBC mode. RRF 3.5.0-rc.1.
Any ideas? -
RE: Erratic driver behavior with Duet 3 Mini 5+
@T3P3Tony Thank you for that info!
I tried to get good photos of the area, but the lighting isn't ideal and U9 is really tiny.
I did however spray some some canned air around the area and the main processor as well as dab some blue tack around to catch debris. I'm not yet sure if that actually helped or if it's just a temporary fluke, but the steppers now work fine, the drivers report OK with no read/write errors.
I'm now successfully printing! Let's hope it continues working. Thank you for the help!
-
RE: Erratic driver behavior with Duet 3 Mini 5+
@jay_s_uk Good idea! Both fuses seem fine, though. Near zero resistance.
-
Erratic driver behavior with Duet 3 Mini 5+
I've been using my delta printer powered by a Duet 3 Mini 5+ for a year and a half. I made two successful prints yesterday, but today it suddenly wouldn't work.
Homing didn't work – motors didn't move and I eventually got "Error: G0/G1: insufficient axes homed". I tried rebooting things and upgrading the firmware, but nothing seemed to help. Then I noticed that all drivers in M122 were listed as "not present", which doesn't seem good.
I browsed this forum for a while trying to find similar issues when I heard the typical sound of energized stepper motors. After a few seconds, one of the motors seemed to move slightly spontaneously. M122 now reported drivers 1, 2 and 3 as "ok". After a short while, drivers 0 and 4 were now "ok" and 1–3 were "standstill".
The motors were now making louder noises than usual. I tried turning ATX power off and on, and I was now back to all drivers being "not present".
I haven't made any changes to my electronics or anything for months, so it was surprising to see this happen so suddenly. I don't see anything indicating failure on the board; no little burn marks on chip packages or anything like that.
Any ideas about what could be wrong? Anything I could try for troubleshooting purposes? Has my board destroyed itself? I've attached three M122 responses with the different driver states.
Thank you!
M122-nonepresent.txt
M122-threepresent.txt
M122-fivepresent.txt -
RE: Mini 5+ Wifi connection unstable
I've always had unstable Wi-Fi with Duet, ever since my first Duet Wifi, regardless of where I put the printer relative to the router and with different channels, router brands, etc. Then I switched to using an SBC and let the Raspberry Pi handle the Wi-Fi connection and it's been rock solid ever since.
-
RE: smarteffector sensivity - unable to change it
@garyd9 Oops. Yes, you're right.
-
RE: smarteffector sensivity - unable to change it
@c310 The second part of the S parameter is supposed to be 255 minus the value. Try
M672 S131:124
. -
Webcam image without reload
I'm trying to setup my camera in DWC, but I'm having some issues.
The camera feed is a multipart/x-mixed-replace stream ("Motion JPEG"), so it doesn't need to be reloaded. I seem to remember earlier versions of DWC accepting 0 as the update interval to accomplish this, but that doesn't seem to work in 3.2.2. A zero value isn't accepted and saved, and reloading the page brings back the old value. I've tried to enter a really large interval, which it does seem to accept, but for some reason, it starts reloading every five seconds after a while anyway.
Also, the webcam URL I enter always seems to have a random (?) number appended at the end. With the "Do not append extra HTTP qualifier when reloading images" option turned off, it's a query parameter. Turned on, it's appended with an underscore. Can I turn this off completely? I just want to use the exact URL I entered.
Thanks!
-
RE: ATX power on Duet 3 mini 5+
@dc42 The pulldown resistor solved it. Brilliant, thank you.
-
ATX power on Duet 3 mini 5+
I just upgraded from Duet Wifi with RRF 2 to Duet 3 mini 5+ with RRF 3.2.2 and SBC. It's an awesome system, and I especially like the object model. I have a few questions about ATX power:
-
On Duet Wifi, PS_ON was off (high) by default, so the board started with power off. On the 3mini, it seems to be on by default (low)? If I put an M81 into config.g, the power is briefly on and then turns off.
I'm using a pull-up resistor to make sure that a floating state is interpreted as off, so that shouldn't be the problem. Am I doing something wrong or is this the intended behavior? -
The
state.atxPower
entry in the object model seems to always be set tofalse
, even when power has been turned on. The web UI reflects this; if I turn on power and reload the page, the switch is shown as off again. Is this a bug or something I've misconfigured?
Thanks!
-
-
RE: Inverting PS_ON levels
I had the same problem and solved it with a simple 7400 NAND gate chip: https://forum.duet3d.com/topic/412/inverting-ps_on
-
RE: Missing spindles in M408 response?
Hey, if I pass a T value to M453, it actually works now. That's nice, but not exactly obvious, especially since the T parameter isn't even documented (afaik).
Oh well, I'm happy for now. Thanks for your help!
-
RE: Missing spindles in M408 response?
@dc42 said in Missing spindles in M408 response?:
Please can you upgrade to 2.03beta2 and try again.
@dc42 Okay, done. It's still the same. PWM output works, but no "spindles" entry in M403 response.
{"status":"O","coords":{"axesHomed":[0,0,0],"xyz":[0.000,0.000,0.000],"machine":[0.000,0.000,0.000],"extr":[0.0]},"speeds":{"requested":0.0,"top":0.0},"currentTool":-1,"params":{"atxPower":0,"fanPercent":[0,100,0,0,0,0,0,0,0],"speedFactor":100.0,"extrFactors":[100.0],"babystep":0.000},"sensors":{"probeValue":205,"fanRPM":0},"temps":{"current":[2000.0,2000.0,2000.0,2000.0,2000.0,2000.0,2000.0,2000.0],"state":[0,0,0,0,0,0,0,0],"tools":{"active":[[0.0]],"standby":[[0.0]]},"extra":[{"name":"*MCU","temp":41.2}]},"time":196.0}
-
RE: Missing spindles in M408 response?
Any troubleshooting tips for this? Since the PWM output works, it seems to me that it should be set up properly and M408 should include the spindle data.
I'd like to poll M408 and get the RPM from there (and set my VFD frequency over Modbus accordingly) instead of relying on PWM. I got an Arduino to measure the PWM with interrupts, but it wasn't as precise as I'd like.
-
RE: Missing spindles in M408 response?
@dc42 said in Missing spindles in M408 response?:
Which firmware version are you using?
2.02(RTOS) (2018-12-24b1)
-
Missing spindles in M408 response?
I'm experimenting with controlling a spindle from Duet. I've switched the machine to CNC mode with
M453 P22 R24000 F100
, and the PWM output works as it should when I sendM3
commands. Cool.However, I'm not seeing spindle info in the reply from
M408
. The source code indicates that there should be a "spindles" entry in the JSON data, but I'm not seeing it.M450
confirms that the mode isPrinterMode:CNC
.The other condition the firmware checks for is that the spindle tool number isn't
-1
. This is difficult for me to verify, but it doesn't work even if I explicitly pass a T parameter toM453
.What am I missing? How do I get spindles included in M408?
FWIW, here's my config.g (no actual steppers or anything are actually connected, so this is mostly from RRF Config Tool):
; General preferences G90 ; Send absolute coordinates... M83 ; ...but relative extruder moves ; Network M550 P"My CNC" ; Set machine name M552 S1 ; Enable network M586 P0 S1 ; Enable HTTP M586 P1 S0 ; Disable FTP M586 P2 S0 ; Disable Telnet ; Drives M569 P0 S1 ; Drive 0 goes forwards M569 P1 S1 ; Drive 1 goes forwards M569 P2 S1 ; Drive 2 goes forwards M569 P3 S1 ; Drive 3 goes forwards M350 X16 Y16 Z16 E16 I1 ; Configure microstepping with interpolation M92 X80.00 Y80.00 Z4000.00 E420.00 ; Set steps per mm M566 X900.00 Y900.00 Z12.00 E120.00 ; Set maximum instantaneous speed changes (mm/min) M203 X6000.00 Y6000.00 Z180.00 E1200.00 ; Set maximum speeds (mm/min) M201 X500.00 Y500.00 Z20.00 E250.00 ; Set accelerations (mm/s^2) M906 X800.00 Y800.00 Z800.00 E800.00 I30 ; Set motor currents (mA) and motor idle factor in per cent M84 S30 ; Set idle timeout ; Axis Limits M208 X0 Y0 Z0 S1 ; Set axis minima M208 X230 Y210 Z200 S0 ; Set axis maxima ; Endstops M574 X1 Y1 S1 ; Set active high endstops ; Z-Probe M574 Z1 S2 ; Set endstops controlled by probe M558 P1 H5 F120 T6000 ; Set Z probe type to unmodulated and the dive height + speeds G31 P500 X0 Y0 Z2.5 ; Set Z probe trigger value, offset and trigger height M557 X15:195 Y15:195 S20 ; Define mesh grid ; Heaters M140 H-1 ; Disable heated bed ; Tools M563 P0 D0 H ; Define tool 0 G10 P0 X0 Y0 Z0 ; Set tool 0 axis offsets G10 P0 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C ; CNC M106 P2 I-1 M453 P22 R24000 F100
And here's the output from
M408 S2
:{ "status":"O", "coords":{ "axesHomed":[ 0, 0, 0 ], "xyz":[ 0.000, 0.000, 0.000 ], "machine":[ 0.000, 0.000, 0.000 ], "extr":[ 0.0 ] }, "speeds":{ "requested":0.0, "top":0.0 }, "currentTool":-1, "params":{ "atxPower":0, "fanPercent":[ 0, 100, 0, 0, 0, 0, 0, 0, 0 ], "speedFactor":100.0, "extrFactors":[ 100.0 ], "babystep":0.000 }, "sensors":{ "probeValue":205, "fanRPM":0 }, "temps":{ "current":[ 2000.0, 2000.0, 2000.0, 2000.0, 2000.0, 2000.0, 2000.0, 2000.0 ], "state":[ 0, 0, 0, 0, 0, 0, 0, 0 ], "tools":{ "active":[ [ 0.0 ] ], "standby":[ [ 0.0 ] ] }, "extra":[ { "name":"*MCU", "temp":41.2 } ] }, "time":1697.0 }
-
RE: Simulations take too long
I agree. The feature is nice, but I rarely use it because it's so slow. I would gladly trade a bit of precision in the calculated time for a nice speedup.