Posts made by nikscha

I would be interested in a variant for the Roto.

I also have a Cetus MK2, and I have the same problem.

I just switched from a Duet2 Wifi to a Mini5+, and suddenly the Y motor makes a nasty screetching noise. The other motors are fine, and before, when the Duet wifi was running things there was also no noise.

I've experimented with different current values, with microstepping and interpolation and with tuning stealthchop, but so far nothing helped. Any ideas?

@o_lampe You could retract/deploy the ball with an electromagnet. Altough I wouldn't use a ball but a rod with a spherical end. I don't think this kind of zprobe needs a "rolling" element.

@elmoret Nothing stopping you from using a 24V heater at 36V XD
You'd get 2.25 times more power out of it!
(and a fire hazard lol)

@oliof thank you, that's very useful to know!

@Adrian52 can you post your config?
I also had a look at the changelog between beta2 and beta3, but I don't see any change that might cause your problem. Maybe have a look yourself: https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-350beta3

@MihaiDesigns I can already see the expression on your face when you talk about this in an upcoming video ^^

Some time ago I also configured sensorless homing for XY on a coreXY. After after a while I had it dialed in quite nicely. Then the next day it didn't work at all (I haven't changed any settings). Turns out some gcode I ran adjusted the travel acceration, and with the higher acceleration the sensorless homing would give me false positives. So maybe reduce your accelerations for the duration of the homing sequence?

@dc42 I tried that but M400 introduces a weird stutter:

Same gcode, left one uses G4 before M569.4, right one uses M400

@Adrian52 what are the print-times for both firmwares? If 3.5.0-rc1 is lower then @o_lampe might be onto something. Be sure to check the print times in the webinterface, not in the slicer.

@dc42 I should have clarified this better: I'm not trying to put the extruder motor into torque mode but a different driver (U axis). The whole gcode snipped would look closer to this:

G1 X147.351 Y89.291 F9000      ;move to coordinate
M569.4 P21.0 T-0.3      ; apply negative torque on U axis
G1 E-1 F4200            ; retract while negative torque is applied
M569.4 P21.0 T0.5       ; apply positive torque on U axis
...continue printing with positive torque applied

At the moment I need to prefix every torque change with G4 to synchronise the change in torque and the retraction.

@nikscha I found a workaround for now, by inserting a G4 just before the M569.4.
Note that a supposedly equivalent M400 introduces stutters.

@dc42 I see, I expected the file to be "reloaded" after saving and then not being found afterwards because of the renaming. Thank you for the solution!

@nikscha

=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.5.0-rc.1 (2023-08-31 16:19:24) running on Duet 3 MB6HC v1.01 (SBC mode)
Board ID: 08DJM-9P63L-DJ3S0-7J1F8-3S86T-TBJZ8
Used output buffers: 1 of 40 (22 max)
=== RTOS ===
Static ram: 154852
Dynamic ram: 90516 of which 1452 recycled
Never used RAM 92980, free system stack 122 words
Tasks: SBC(2,ready,1.1%,422) HEAT(3,nWait,0.0%,323) Move(4,nWait,0.4%,214) CanReceiv(6,nWait,0.1%,771) CanSender(5,nWait,0.0%,328) CanClock(7,delaying,0.0%,349) TMC(4,nWait,8.5%,59) MAIN(2,running,89.8%,137) IDLE(0,ready,0.1%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 01:10:35 ago, cause: power up
Last software reset at 2023-10-16 15:38, reason: User, Expansion spinning, available RAM 92980, slot 0
Software reset code 0x6012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0043c000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 20.1, current 38.5, max 38.9
Supply voltage: min 24.0, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0
Heap OK, handles allocated/used 99/15, heap memory allocated/used/recyclable 2048/1572/1248, gc cycles 1
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, mspos 120, reads 42313, writes 51 timeouts 0
Driver 1: standstill, SG min 0, mspos 408, reads 42313, writes 51 timeouts 0
Driver 2: standstill, SG min n/a, mspos 8, reads 42348, writes 16 timeouts 0
Driver 3: standstill, SG min n/a, mspos 8, reads 42348, writes 16 timeouts 0
Driver 4: standstill, SG min n/a, mspos 8, reads 42353, writes 11 timeouts 0
Driver 5: standstill, SG min 0, mspos 856, reads 42321, writes 43 timeouts 0
Date/time: 2023-10-18 10:41:22
Slowest loop: 67.45ms; fastest: 0.05ms
=== Storage ===
Free file entries: 20
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 39, maxWait 701455ms, bed compensation in use: mesh, height map offset -0.016, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 29069, completed 29069, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 84], CDDA state -1
=== DDARing 1 ===
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 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.1
Heater 4 is on, I-accum = 0.2
=== GCodes ===
Movement locks held by null, 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 0, running macro
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2* is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x10000003
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 93461, received 237613, lost 0, boc 0
Longest wait 56ms for reply type 6041, peak Tx sync delay 536, free buffers 50 (min 49), ts 21178/21177/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 36389/36389
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x25a98
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.0-rc.1 (2023-09-01 07:16:31)
Daemon:
>> Doing macro daemon.g, started by system
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 1
Full transfers per second: 1.54, max time between full transfers: 83.9ms, max pin wait times: 67.7ms/8.5ms
Codes per second: 0.84
Maximum length of RX/TX data transfers: 5684/2152

Hi all,

my daemon.g looks like this:

while true          
    G4 P2000
    echo "test"

when remaning it to daemon1.g it keeps running:

changing daemon1.g to

while true             
    G4 P2000
    echo "test2"

yields

@usinjin Did you indent the code? It should be inside the while loop.

@janjoh Looks all normal to me. You have a revision 2.0 pcb, same as me. I don't think I can help you at this point. Maybe a case for waranty?

@janjoh I have a very similar setup ^^
I've been abusing the only smarteffector I ever bought and it's still working fine. I have numerour scratches on the pcb, some of the traces are even exposed. So I'd be surprised if it's a hardware problem. Maybe interference is causing problems? Maybe static?

What pcb revision is your current (and previous) smart effector?

Have you ever changed the sensitivity on the smart effector?

@usinjin
Do the following:

;daemon.g
while true
   G4 P1 
   "rest of the code"

This will run "rest of the code" about 3-6 times a second, depending on your code, NOT 1000 times a second as the G4 P1 might suggest. AFAIK the G4 P1 gives controll back to the main process. You can read more here https://docs.duet3d.com/User_manual/Reference/Gcode_meta_commands under the daemon.g section

@Pranayme yes that looks good to me. I noticed that your comment says board 40, did you make a mistake here when copying?
Also: do you use an external supply for the motor brake? If so, have you set the jumper correctly?

@Pranayme Ahh I missed that, thanks