Topics created by FelixH

@droftarts ok, so a 5v voltage regulator. Makes total sense that the board doesn't work if it is broken. I will try to get a replacement and hope for the best

thanks!

for the life of me, I cannot understand what is going on here.

After having a look at the thread I posted, I got my printer homing perfectly every single time. I was so happy. here is my homey.g file:

; homey.g ; called to home the Y axis M913 Y70 ; drop motor current to 70% G4 P100 ; wait 100ms M915 Y S-3 R0 F0 ; set Y sensitivity, do nothing when stall, unfiltered G4 P100 ; wait 100ms M400 ; wait for current moves to finish G91 ; set relative movements G1 H2 Z5 F1200 ; lift Z ; tune drivers ; relative positioning G1 H2 Y0.4 F3000 ; power up motors to ensure they are not stalled G4 P100 ; wait 100ms M400 ; wait for current moves to finish ; home Y G1 H1 Y5 F1200 ; move slowly away G1 H1 Y-300 F6000 ; move to Y axis endstop and stop there (first pass) ; eren 3600 G1 Y5 F1200 ; go back a few mm G1 H1 Y-10 F6000 ; move to Y axis endstop once more (second pass) ; eren 3000 G1 Y10 F1200 ; go back a few mm M400 ; wait for current moves to finish M913 Y100 ; restore motor current to 100% G4 P100 ; wait 100ms G1 H2 Z-5 F1200 ; reset Z G90 ; reset absolute movements

Now, I came yesterday from my winter break. Today I wanted to try a new method of steps calibration I though out. I moved the printer over the bench so I can have better access to it (the calibration involves having a pen attached to the extruder, a piece of paper and so on).

I start up the printer and I home it. The Y homing starts failing miserably again in the same fashion it did before.

I cannot understand how come it worked perfectly before, I change absolutely nothing at all and starts failing again. It did work perfectly. Nice homing, nice prints, reliable... and all of the sudden it stopped working again.

Any insights?

@gloomyandy yeah, got you! As I already checked, by setting the tolerance to 0.004 it did already the trick.

thanks a lot!

@FelixH Examples in the wiki are here: https://docs.duet3d.com/en/User_manual/Connecting_hardware/Z_probe_auto_levelling#examples
But they are basically the same as the one you found and @fcwilt has posted.

An alternative way of coding a repeating cycle until the number of iterations or specific accuracy is achieved could be (thanks to @Sindarius ) :

while true G30 P0 X25 Y105 Z-99999 ; probe near a leadscrew, half way along Y axis G30 P1 X240 Y105 Z-99999 S2 ; probe near a leadscrew and calibrate 2 motors if abs(move.calibration.initial.mean) < 0.01 || iterations > 3 break

Ian

@droftarts I took the values from the Tornado`s original Firmware (Marlin). The Bed on the Tornado is quite huge (300x300, 4 mm Aluminum). I am guessing this is why there is a difference

@phaedrux from the time I started with 3D printers, I used to find really difficult to adjust the nozzle Z-Height by moving the Z-Endstop up and down. That's the main reason I tended to do it that way. I am not saying it is not possible, but I am unable to physically move one endstop on an Al-Profile by 0.x mm. Even if I loosen it up, and move it, say, 0.2mm, by the time I tighten it again, the forces upon the screw have already moved it...

anyway... I've made some progress yesterday and today. The main problem was that actually one of the wires on one motor was not crimped correctly. After that, I only had to adjust the code I was given. After modifying the endstops configuration and axis configuration, I had to modify the homeall.g and the homey.g files, which I attach here for future reference:

homeall.g

G91 ; relative positioning G21 ; Set units to mm G1 H1 Z{move.axes[2].max*2} F900 ; move quickly to Z axis endstop and stop there (first pass) G1 H1 X{move.axes[0].max*2} F2400 ; move quickly to X axis endstops and stop there (first pass) G1 H1 Y{move.axes[1].max*2} F2400 ; move quickly to Y axis endstops and stop there (first pass) M584 P4 ; set 4 axis CNC M669 K0 X1:0:0:0 Y0:1:0:0 U0:0:0:1 Z0:0:1:0 ; enable speed for U axis G92 X{move.axes[0].max} Y{move.axes[1].max} U{move.axes[3].max} Z{move.axes[2].max} ; Set Home Position G1 X-3 Y-5 U-5 F2400 ; go back a few mm in Y and U G1 Z-3 F900 ; go back a few mm in Z G1 H1 Y{move.axes[1].max*2} U{move.axes[3].max*2}F300 ; move slowly both Y and U axis enstops and stop there (second pass) G1 Y-0.23 F150 ; fully align gantry IMPORTANT move only in negative direction (select Y or U and change accordingly) G92 Y{move.axes[1].max} U{move.axes[3].max} ; set Y and U home Position M584 P3 ; set 3 axis CNC M669 K0 X1:0:0:0 Y0:1:0:1 Z0:0:1:0 ; enable Y speed for U axis G1 H1 X{move.axes[0].max*2} F300 ; move slowly to X axis endstops once more (second pass) G1 H1 Z{move.axes[2].max*2} F300 ; move slowly to Z axis endstop once more (second pass) G92 X{move.axes[0].max} Y{move.axes[1].max} Z{move.axes[2].max}; Set Home Position G90 ; absolute positioning

homey.g

G91 ; relative positioning G21 ; Set units to mm G1 H1 Z{move.axes[2].max*2} F900 ; move quickly to Z axis endstop and stop there (first pass) G1 H1 Y{move.axes[1].max*2} F2400 ; move quickly to Y axis endstops and stop there (first pass) M584 P4 ; set 4 axis CNC M669 K0 X1:0:0:0 Y0:1:0:0 U0:0:0:1 Z0:0:1:0 ; enable speed for U axis G92 Y{move.axes[1].max} U{move.axes[3].max} Z{move.axes[2].max} ; Set Home Position G1 Y-5 U-5 F2400 ; go back a few mm in Y and U G1 Z-3 F900 ; go back a few mm in Z G1 H1 Y{move.axes[1].max*2} U{move.axes[3].max*2}F300 ; move slowly both Y and U axis enstops and stop there (second pass) G1 Y-0.23 F150 ; fully align gantry IMPORTANT move only in negative direction (select Y or U and change accordingly) G92 Y{move.axes[1].max} U{move.axes[3].max} ; set Y and U home Position M584 P3 ; set 3 axis CNC M669 K0 X1:0:0:0 Y0:1:0:1 Z0:0:1:0 ; enable Y speed for U axis G1 H1 Z{move.axes[2].max*2} F300 ; move slowly to Z axis endstop once more (second pass) G92 Y{move.axes[1].max} Z{move.axes[2].max}; Set Home Position G90 ; absolute positioning

the problem I found is that after reassigning the axis with the M584 and M669 commands, the homing is lost. Even if I want to split the combined Y into Y and U for the autosquaring, when the M584 followed by the M669 command is executed, all the homing are lost, even X and Z.

Now, as I was collecting the info for the update, I remembered that on my 3D printers I am able to set an offset for the Z probe with the G31 command. I was wondering if I could use this G31 command to set offsets for the Y and U axis. That way, I guess I could skip the moving of one of the axis "manually" ?? or am I missing something here?

Thanks a lot!

@phaedrux you get me!

I just posted a simple solution to fire the laser without moving here

@phaedrux sure thing:

M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.3 (2021-06-15 21:44:54) running on Duet WiFi 1.02 or later Board ID: 08DGM-917DA-G4MS8-6JKDA-3SJ6T-T8VH8 Used output buffers: 3 of 24 (17 max) === RTOS === Static ram: 23876 Dynamic ram: 75280 of which 0 recycled Never used RAM 12404, free system stack 172 words Tasks: NETWORK(ready,13.6%,237) LASER(notifyWait,0.0%,70) HEAT(delaying,0.0%,386) Move(notifyWait,0.1%,364) MAIN(running,86.3%,519) IDLE(ready,0.0%,29), total 100.0% Owned mutexes: WiFi(NETWORK) === Platform === Last reset 00:53:43 ago, cause: power up Last software reset at 2021-12-04 17:24, reason: User, GCodes spinning, available RAM 12604, slot 1 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0 Step timer max interval 0 MCU temperature: min 20.5, current 23.2, max 24.4 Supply voltage: min 24.1, current 24.3, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes Heap OK, handles allocated/used 99/1, heap memory allocated/used/recyclable 2048/24/0, gc cycles 0 Driver 0: position 0, standstill, SG min/max not available Driver 1: position 0, standstill, SG min/max not available Driver 2: position 0, standstill, SG min/max not available Driver 3: position 0, standstill, SG min/max not available Driver 4: position 0, standstill, SG min/max not available Driver 5: position 0 Driver 6: position 0 Driver 7: position 0 Driver 8: position 0 Driver 9: position 0 Driver 10: position 0 Driver 11: position 0 Date/time: 2021-12-04 18:43:48 Cache data hit count 4294967295 Slowest loop: 30.98ms; fastest: 0.17ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest read time 1.2ms, write time 15.9ms, max retries 0 === Move === DMs created 83, maxWait 0ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 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 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 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 71.59ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 1 of 8 - WiFi - Network state is active WiFi module is connected to access point Failed messages: pending 0, notready 0, noresp 0 WiFi firmware version 1.26 WiFi MAC address bc:dd:c2:9a:4a:85 WiFi Vcc 3.31, reset reason Turned on by main processor WiFi flash size 4194304, free heap 25112 WiFi IP address 192.168.1.212 WiFi signal strength -60dBm, mode 802.11n, reconnections 0, sleep mode modem Clock register 00002002 Socket states: 0 0 0 0 0 0 0 0

@phaedrux well... I promised I would report back...

Screenshot 2021-08-08 at 21-52-07 Steel.png

Thanks a lot! At the end of the day it was just the simple "level it the old fashioned way before..."

Can't thank you enough, it was bothering me for a while...

@phaedrux ... I guess I should start reading the release notes from now on... thanks!

THIS is a Cura configuration for a SeeMeCNC dual extruder "Y" setup.

Maybe it will help you get Cura configured.

@o_lampe said in Request Cartesian with cyclops system: 2 extruders and 1 hotend:

Just out of curiosity, now that the drive mapping is added, would it still be necessary to have separate jerk-, acceleration-, etc- setting for the second extruder?
Is it even possible to have different settings?

Yes. Extruders are considered as independent axis and should have all settings defined for each extruder and those settings can be different.

For other axis like XYZ you only need a single value for that axis. You must use identical motors for axis with multiple motors and you cannot have different settings for each motor.

See the notes here: https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M584_Set_drive_mapping

@Phaedrux said in Move command not executed from PanelDue + Pendant:

And firmware version on the Duet?

RRF2, this one I got it right, I'm sure... 😊

So, the printer has undergone several Y-homings since I changed the speed and has suffered 0 fails, so I would say the issue is solved. Thanks again!

@FelixH said in Z trigger height:

This is exactly what puzzles me every time. The pop up on the Panel Due shows a minus value an yet, it’s the opposite...

I know it can be confusing.

When the probe is triggered the trigger height setting (assume 2 mm) says to the firmware "hey the nozzle is now 2mm above the bed". The firmware says to itself "ok so to move the nozzle to Z=0 I must move closer to the bed by 2mm"

When you adjust baby stepping to a negative value you are saying to the firmware "hey you need to move closer to the bed".

And as you can see to move closer to the bed requires a larger trigger height.

Frederick

@Phaedrux Thanks a lot, you were right on the money.

On the homey.g file the command M574 was declared as

M574 Y S3

without any argument on the Y (Y1 or Y2). And that seemed to be causing the problem.

I commented it out and everything is back to normal. I wonder why did it work previously.

Thanks a lot again!

If you're actually worried about things getting too hot, simply run the fan any time the power is on- i.e. connect it to the power supply. If the noise concerns you, use a fan that is rated for higher voltage than your system (line or DC). I have a 127mm 208VAC fan blowing against the Duet board whenever the power is on. We have 117VAC line voltage here, so the fan turns slowly and quietly but moves more than enough air to keep things cool. 24VDC fans will usually start and run reliably, slowly, and quietly on 12VDC, or you can install a buck or boost converter with the fan to tweak the voltage to it a little as needed. Converters that can drive fans are very small and dirt-cheap.

well, if anyone is following this thread, I just want to mention that it has been solved.

The issue was the name of the macro together with the firmware version of the Paneldue. I changed the name of the macro to be just text and it worked fine. And just for the sake of it, I updated the firmware to the latest version. Everything works just fine now.

@dc42 said in Duet 3 WiFi:

@nriviera said in Duet 3 WiFi:

Is there a plan for a cheaper option with a CAN bus? I think the biggest draw card for the Duet3 is then can bus with more people making tool changers of late but don't need to run large steppers.

We are already planning a Duet 3 main board with outputs for external stepper drivers (probably between 6 and 😎 instead of having six drivers on board. It is aimed at those building large machines using step-servo drives.

Looks like an alternative to the Mach 3/4 environment, right?