@droftarts
Good Evening Ian,
Didnt get the chance to revert back to 3.3 due to time constraints,and also a bit hesitant at this point due to when 3.3 firmware was installed there were issues with homing (as stated above, changing homing scripts did nothing), running a bed mesh would stop and error after probing 5 points (was unable to resolve this issue) so the bed was manually leveled and checked every few print runs.

Did not get the chance to switch the 1XD boards around (time constraints).

The new Y axis motor is exactly the same as the original "stock" creatbot motor and all dip switches and tuning parameters were copied over and besides the aforementioned issues, everything worked fine.

As stated above, the machine had not been switched on or run since the last time when the circles issue was raised here in the forum. This time round, the only change was that the rpi4 has run an update and the gcode file that was used last time and saved on the sd card was run after the update to which not only did the print come out differently (the offset/skew is better/tighter) but the machine itself i.e the motors especially sounded as if they were heavily labouring, very jerky/deep vibration sort of sound on all movements. And this is where the testing ceased as the only thing that changed was the rpi4 updating and thus raised more questions of why is the circles "skew" now better than previous but still skewed none the less.

Cheers,

Albert

It's work!!

New USB-Cable and at the USB was another Device. Perhaps both Device was in trouble?

What a sh.. so many hour for nothing..

Please create a Command-line that set the Speed to "low" speed, for support more and older Hardware.

Thank You..

Thank both of you;

@droftarts good call about the iap4e.bin, this fixed my problem.
It seems a bit counterintuitive that to upgrade to 3.0, the iap.bin from 2.05.1 is needed, and the same goes for the update from 3.0 to 3.3 - this might be worth mentioning in the firmware update section in the docs where the different jumps in firmware version are described. It does mention to not just rename a file (😇) but it says that each version comes with the matching file, which seems a bit twisted.

best regards, Niklas

@Alucardi This is the first part of your homeall.g:

; homeall.g ; called to home all axes ; ; generated by RepRapFirmware Configuration Tool v3.2.1 on Sun Jan 17 2021 22:57:15 GMT+0100 (centraleuropeisk normaltid) M400 ; finishes all current moves and and thus clears the buffer M913 X60 Y60 ; drop motor current to 33% M569 P0.0 D3 V60 ; reduce V to ensure stealthChop is enabled M569 P0.1 D3 V60 ; reduce V to ensure stealthChop is enabled M915 P0 S1 R0 F0 H400 ; sensitivity X, don’t take action, don’t filter -4 M915 P1 S1 R0 F0 H400 ; sensitivity Y, don’t take action, don’t filter -4 M400 ; finishes all current moves and and thus clears the buffer ...

and this is the first part of your homex.g (homey.g is largely the same):

; homex.g ; called to home the X axis ; ; generated by RepRapFirmware Configuration Tool v3.2.1 on Sun Jan 17 2021 22:57:15 GMT+0100 (centraleuropeisk normaltid) M400 ; finishes all current moves and and thus clears the buffer M913 X1 Y1 ; drop motor current to 50% M569 P0.0 P0.1 D3 V1 ; reduce V to ensure stealthChop is enabled M915 P0.0 P0.1 S30 R0 F0 ; sensitivity, don’t take action, don’t filter M400 ; finishes all current moves and and thus clears the buffer ...

The main problem is that you are setting the currents to 1% with M913 in homex.g. Also, your M569 and M915 lines for each motor in homex.g need to be on separate lines, ie you can't do M569 P0.0 P0.1 .... You also have different settings for these in homex.g and homey.g compared to homeall.g.
Basically, if homeall.g is working correctly, copy those lines from homeall.g into the other homing macros, then test.

Ian

@Alucardi There's a few macros around on the forum to do this. M500 P31 saves the current Z probe offset to config-override.g, so you just need to add the current Z offset and the baby stepping, apply that as the new probe offset, then save it with M500 P31. See
https://forum.duet3d.com/topic/18100/script-to-make-babysteps-permanent (read the whole thread)
Alternative way to do it:
https://forum.duet3d.com/post/249949

Ian

@dc42 Thanks for confirming this.

@Stout

Thanks for all your constructive positive inputs.

Meh. Just wanted to generate some understanding for developers and the decisions they have to take.

so why throw it away? Beacuse it's 12 years old?

Beware! Remember the venerable Newton I mentioned above? Or look at @droftarts’ suggestions. BTW: until now, I replaced more than 10 batteries of iPhones and iPads instead of trashing them. The monitor of my M2 is a 12 year old iMac (modded), I run a G5 „cheese grater“ for elaborated HDD recovery, and my Duet lives in a G4 casing.

The thing is: Apple cuts support for older machines, so we are on our own with how to keep them alive and useful. Some of us then install Linux, some jailbreak their iOS devices in order to install unsupported software.

@dtmcnamara it took me several minutes to flash 100 pages or so on duet 2 upgrading the firmware,perhaps that is different

Multithreading is a bit overkill for driving only a servo. Have you thought of using macros instead?
You can postprocess your printfile by replacing the retract/unretract lines (G10 and G11) with G10.1 and G11.1 respectively. Now you write two macros called G10.1 and G11.1 in which you set the required servo positions (and also trigger the real retract/unretract macros)

@droftarts darn the xb6 is what I have to,lol

@TAS_3D thank you very much,the same problem here. I spent a few weeks on mine and as soon as I started to get things working I had to start work again. I'm going to spend some time with it today,thanks for the instructions.

@kungpaoshizi Duet 2 can use all new features of RRF3. Whether or not it's worth it to you to upgrade depends on what you're looking to do. If you are running happily as is and don't need any of the new features, you're fine to hold tight.

@matthew-81 There's a page for CoreXY setup here: https://docs.duet3d.com/User_manual/Machine_configuration/Configuration_coreXY
If you have the correct codes in your config.g to turn on CoreXY mode, see the section on 'Testing motor movement' to get the motors working in the correct direction.

Also, post your config.g, response to M115 (for firmware version), and send M98 P"config.g" in the console and post the response to that (it will show any errors in config.g).

Ian

@chrishamm said in cant connect to https://pkg.duet3d.com for update:

@SputnikOC3d It's just a stub at this point. First of all, you need to enable root plugin support in /opt/dsf/conf/config.json by changing RootPluginSupport from false to true. Then restart the SBC or just DCS by running sudo systemctl restart duetcontrolserver from a Linux terminal. Once done, you need to download the latest .deb packages from the stable/unstable package feeds (see the command line here for a list of the packages you need), compress them as dsf-update.zip, and upload it on the Files -> System page. After 2mins or so, DWC should report that the installation was successful. I don't think this way of updating is supported before v3.4, though.

Awesome - thank you ... running 3.4+ iirc - Need to fire up the beast and see where shes at ... Thanks again.

@yuval prusaslicer "just works" with the multi tool configuration that reprapfirmware does.

the first tool is T0, the second is T1. the tool definition and tool offsets are enough for things to sort themselves out.

The tpre#/tpost# macros make sure a toolhead is prepared before/after activation. tfree# makes sure a tool is properly prepared for not being used, for example by moving it out of the way.

The confusion about G1 Xnn / G1 Unn comes from the ambiguity of whether X means the machine axis or the tool position along a coordinate system.

To make a bit of a diversion, in a delta printer or a corexy system "G1 Xnn" moves the active toolhead to position nn. In both cases there is no single otor that directly drives something along the X axis, but two or three motors need to cooperate for this move.

Now, when you want to address a motor in these motion systems directly, you can apply the H2 parameter to drive them, but this will cause a motion that does not map to the coordinate system. In a delta the printhead will make some diagonal move on the Z plane, in a corexy, it will make a 45 degree mode

In an IDEX system, G1 Unn moves will work even if the second print head is not the active tool because the axis assignment is unambiguous. But if you command T1 a G1 Xnn will move the seconf tool head. the H2 parameter mentioned above may work to move the first toolhead even if the second is active. (I cant currently test this, so please take with a grain of salt).

So, when choosing the second tool, the first tool (if active) is deselected, tfree0.g is runn, then tpre1.g, then tpost1.g. After that, any G1 Xnn move applies to the second toolhead, applying the defined offset, to move it within the coordinatr system, until T0 or T-1 is run.

Running T-1 is special because it deselects any active tool without selecting a new one. Good to do this at the end of a print to make sure the machine is in a well known state and all tools are parjed where they are depending on their tfree# macro

I hope that clarifies things a bit. Please refer to
https://docs.duet3d.com/en/User_manual/Machine_configuration/Configuration_IDEX as well as the M563 and G10 documentation for official word. If you have more questions, please ask.

@dc42
Ok here we go

; bed.g v3.1 ; Called as response to G32, as part of a full mesh probing (M98 P"bed.g" B) or at the start of a print (M98 P"bed.g" A) ; Used to tram the bed ;---/ ; -/--/--/--/--/--/--/--/--/--/--/--/--/-a-/--/--/-- ; THIS MACRO ONLY WORKS WITH RRF 3.5.0b1 AND LATER!! ;--/--/--/--/--/--/--/--/--/--/--/--/--/--/--/--/-- ;-/ ; ====================--------------------------------------------------------- ; Question code ; ==================== if !exists(global.bed_trammed) set global bed_trammed = false var tram = "PLACEHOLDER" if exists(param.A)||exists(param.B) if global.bed_trammed = false set var.tram = true else set var.tram = false ; Ask to make sure you want to tram the bed or not if !exists(param.A)||exists(param.B) if global.bed_trammed M291 S4 R"Bed tramming" P"The bed is allready trammed, want to tram it again?" K{"YES","CANCEL",} else M291 S4 R"Bed tramming" P"Are you sure you want to tram the bed?" K{"YES","CANCEL",} if input = 0 set var.tram = true elif input = 1 set var.tram = false if var.tram = true ; ====================--------------------------------------------------------- ; Prep phase ; ==================== ; Report whats going on M291 R"Bed tramming" P"Please wait..." T10 ; Tramming bed message ; ====================--------------------------------------------------------- ; Lower Z axis ; ==================== ; Lower Z relative to current position if needed if !move.axes[2].homed ; If Z ain't homed G91 ; Relative positioning G1 Z{global.Nozzle_CL} F9000 H1 ; Lower Z(bed) relative to current position G90 ; Absolute positioning elif move.axes[2].userPosition < {global.Nozzle_CL} ; If Z is homed and less than global.Nozzle_CL G1 Z{global.Nozzle_CL} F9000 ; Move to Z global.Nozzle_CL ; ====================--------------------------------------------------------- ; Homing check ; ==================== ; Make sure all axes are homed, and home Z again anyways if !move.axes[0].homed || !move.axes[1].homed ; If X & Y axes aren't homed ; Home X & Y axis M98 P"/sys/homex.g" Z A ; Home X axis, pass param.Z since we allready lowered Z & A to indicate this is part of a homing sequence M98 P"/sys/homey.g" Z C ; Home Y axis, pass param.Z since we allready lowered Z & C since XY currents/speeds are also ok ; ==================== ; Home Z axis ; ==================== if !exists(param.A) M98 P"/sys/homez.g" Z A ; Home Z axis, pass param.Z since we allready lowered Z & A to indicate this is part of a homing sequence ; ====================--------------------------------------------------------- ; Tramming code ; ==================== M561 ; Clear any bed transform M290 R0 S0 ; Reset baby stepping M84 E0 ; Disable extruder stepper ; Lower XY currents if fileexists("/sys/lib/current/xy_current_low.g") M98 P"/sys/lib/current/xy_current_low.g" C60 ; Set low XY currents else M913 X40 Y40 ; Set X Y motors to 40% of their max current ; Lower Z currents if fileexists("/sys/lib/current/z_current_low.g") M98 P"/sys/lib/current/z_current_low.g" ; Set low Z currents else M913 Z60 ; Set Z motors to 50% of their max current ; LED status if exists(global.sb_leds) set global.sb_leds = "tramming" ; Save the default probe settings var dH = sensors.probes[0].diveHeight var spd0 = sensors.probes[0].speeds[0] var spd1 = sensors.probes[0].speeds[1] var maxP = sensors.probes[0].maxProbeCount ; Coarse tramming pass M558 K0 H10 F800 A1 ; Increase the depth range & speed, gets the bed mostly trammed immediately M98 P"/sys/bed_probe_points.g" ; Probe the bed ; Fine tramming pass while true ; Probe near lead screws - M558 K0 H{var.dH} F{var.spd0, var.spd1} A{var.maxP} ; Reset default probe settings M98 P"/sys/bed_probe_points.g" ; Probe the bed ; Check results - exit loop if results are good if move.calibration.initial.deviation < 0.005 ; If probing result is less than 0.005mm set global.bed_trammed = true ; Set global state break ; Stop probing ; Check pass limit - abort if pass limit reached if iterations = 5 ; If probed more than 5 times M291 P"Bed tramming aborted!" R"Pass Limit Reached!" ; Abort probing, something wrong set global.bed_trammed = false ; Set global state abort "Bed tramming aborted! - Pass Limit Reached!" ; Abort probing, something wrong ; ====================--------------------------------------------------------- ; Finish up ; ==================== ; Uncomment the following lines to lower Z(bed) after probing G90 ; Absolute positioning G1 Z{global.Nozzle_CL} F2400 ; Move to Z global.Nozzle_CL ; Home Z one last time now that the bed is trammed ; LED status if exists(global.sb_leds) set global.sb_leds = "homing" M98 P"/sys/lib/goto/bed_center.g" ; Move to bed center G30 K0 Z-99999 ; Probe the center of the bed M400 ; Wait for moves to finish ; Full currents if fileexists("/sys/lib/current/xy_current_high.g") M98 P"/sys/lib/current/xy_current_high.g" ; Set high XY currents else M913 X100 Y100 ; Set X Y motors to var.100% of their max current if fileexists("/sys/lib/current/z_current_high.g") M98 P"/sys/lib/current/z_current_high.g" ; Set high Z currents else M913 Z100 ; Set Z motors to var.100% of their max current ; Uncomment the following lines to lower Z(bed) after probing G90 ; Absolute positioning G1 Z5 F2400 ; Move to Z 10 M291 R"Bed tramming" P"Done" T5 ; Bed tramming done message ; If using Voron TAP, report that probing is completed if exists(global.TAPPING) set global.TAPPING = false M402 P0 ; Return the hotend to the temperature it had before probing ; LED status if exists(global.sb_leds) set global.sb_leds = "ready"

And the two variants of bed_probe_points.g

; bed_probe_points.g ; called to define probing points when traming the bed if !exists(param.A) M98 P"/sys/lib/goto/bed_center.g" ; Move to bed center G30 K0 P0 X5 Y345 Z-99999 ; Probe left rear bed corner G30 K0 P1 X345 Y345 Z-99999 ; Probe right rear bed corner G30 K0 P2 X345 Y5 Z-99999 ; Probe right front bed corner G30 K0 P3 X5 Y5 Z-99999 S3 ; Probe left front bed corner and calibrate 3 motors ; bed_probe_points.g ; called to define probing points when traming the bed if !exists(param.A) M98 P"/sys/lib/goto/bed_center.g" ; Move to bed center G30 K0 P0 X175 Y345 Z-99999 ; Probe bed rear center G30 K0 P1 X345 Y5 Z-99999 ; Probe right front bed corner G30 K0 P2 X5 Y5 Z-99999 S3 ; Probe left front bed corner and calibrate 3 motors

@rl_at_berk RRF uses FreeRTOS for task creation and threading. I suggest you read the FreeRTOS documentation. RRF mosty doesn;t call FreeRTOS directly, instead file RTOSIface/RTOSIface.h in the RRFLibraries project contains the declarations of the functions used by RRF for task creation etc.

The TaskCriticalSectionLocker object merely suspends task switching during its lifetime.

@rl_at_berk good to know👍
BTW, END_STOP_PINS are define in Duet_Pins.h line 67 ( for 9 axis )

@jay_s_uk
Okaay
Thanks

@RL_berk I uninstalled and reinstalled. Worked fine after that.