Ok - with RC7 actually installed it appears to be working fine. I've got 10 minutes into a print that was failing after 5.
Thank you for the awesome support as always and apologies for being a stupid user !
Keep safe.
(I'll close the issue on Github when I finish at work).
David
How weird. I didn't check that the update took before I posted - sorry- from the apt-get update on the console it looked like it had.... I was indeed still on RC6. I'll report back once I test it.
Hi @chrishamm - I'll report it on github when I get home but I just tested RC7 and confirm the same error.
Kind Regards,
David
"Error: Internal Error in Spin at ../src/Linux/LinuxInterface.cpp(54)"
As it says. Using a Duet 3 and expansion board. Latest RC is throwing that error generally about 5 minutes into a print.
Have tried a few prints that have never been an issue before so I assume it's an issue with the RC.
Any suggestions?
Keep safe all
David
This has been driving me crazy for months - can confirm console output is restored for G32 (and others for me) with with 2.1.1
Thank you.
I'm glad it's not just me. This started as soon as I moved to Duet 3 h/w. If I press the level button on the panel due - then I get the expected output in both console and web interface via the pop up.
If I run G32 via the web console then the printer does run the macro as expected but I don't get any output.
Did anyone find a solution to this?
So that worked very easily - thank you @dc42 - for anyone else wanting to do the same - I used this in config.g.
M584 X0.0 Y0.1 Z0.2:1.0:1.1:1.2 E0.3 ; set drive mapping with dummy driver on mainboard (0.2)
M906 X1400 Y1400 Z100 E800 I60 ; set to low power
M584 X0.0 Y0.1 Z1.0:1.1:1.2 E0.3 ; set drive mapping for the real z steppers
M906 X1400 Y1400 Z1000 E800 I60 ; set a sensible power level
M584 X0.0 Y0.1 Z0.2:1.0:1.1:1.2 E0.3 ; add the dummy drive (still at 100mA) back to the group.
This does break automatic bed leveling since RRF3 now thinks I have 4 independent z's and I'm only declaring 3 in bed.g - I don't think there is any easy solution for that but if anyone has a good suggestion...
Thanks !
@dc42 and that'll be what gets you the reputation you have in these parts !
Thank you for the quick reply. I am too tired to try it tonight but I will do so tomorrow and report back / mark resolved assuming it works !
I don't know if you want to rename the thread to make finding that answer easier.
I looked pretty carefully and it wasn't advice I found elsewhere.
Thanks again !
@deckingman thank you for that. I assume it's also true you can't run z probes on an expansion board (still).
It's not the end of the world I just have to extend the wiring for all three of my z steppers and move them to the main board.
I wonder if @dc42 could comment as to when either of the above will be solved (or indeed it they are solved in the current beta).
Just by way of additional information.
Moving the bltouch to the expansion board (1.io0) didn't work. It no longer seemed to work at all.
Moving it back to 0.io7 and it works again fine (responds to M401 / M402)
The obvious thing would be to move my z steppers to the main board but I have a cable length issue.
Well I was asking if the firmware limitations apply because that would explain my issue without other people having to spend time helping me debug it.
config,g (relevant bits).
; Drives
M569 P0.0 S1 ; physical drive 0.0 goes forwards
M569 P0.1 S0 ; physical drive 0.1 goes backwards
M569 P0.2 S1 ; physical drive 0.2 goes forwards
M569 P0.3 S0 ; physical drive 0.3 goes forwards
M569 P1.0 S1 ; Drive 5 goes backwards Front Left Z
M569 P1.1 S1 ; Drive 6 goes backwards Rear Left Z
M569 P1.2 S1 ; Drive 7 goes backwards Right Z
M671 X-10:-10:333 Y22.5:277.5:150 S7.5 ;Front left, Rear Left, Right S7.5 is the max correction - measure your own offsets, to the bolt for the yoke of each leadscrew
M584 X0.0 Y0.1 Z1.0:1.1:1.2 E0.3 ; set drive mapping
M350 X16 Y16 Z16 E16 I1 ; configure microstepping with interpolation
M92 X200 Y200 Z1600 E837 ; set steps per mm
M203 X24000 Y24000 Z900 E3600 ; set maximum speeds (mm/min)
M201 X3000 Y3000 Z100 E1500 ; set accelerations (mm/s^2)
M906 X1400 Y1400 Z1000 E800 I60 ; set motor currents (mA) and motor idle factor in per cent
M566 X1000 Y1000 Z100 E1500 ; Maximum jerk speeds mm/minute
M84 S30 ; Set idle timeout
; Axis Limits
M208 X0 Y0 Z-0.5 S1 ; set axis minima
M208 X330 Y350 Z650 S0 ; set axis maxima
; Endstops
M574 Y1 S1 P"io1.in" ; configure active-low endstop for low end on X via pin io1.in
M574 X1 S1 P"io2.in" ; configure active-low endstop for low end on Y via pin io2.in
M574 Z0 S2 ; configure Z-probe endstop for low end on Z
; Z-Probe
M950 S0 C"io7.out"
M558 P9 C"io7.in" H10 F120 T3600 ; set Z probe type to bltouch and the dive height + speeds
G31 P500 X2 Y40 Z0.8
homez.g
; generated by RepRapFirmware Configuration Tool v2.1.5 on Mon Jan 13 2020 13:41:08 GMT+0000 (Greenwich Mean Time)
G91 ; relative mode
G1 H2 Z4 F200 ; raise head 4mm to ensure it is above the Z probe trigger height
G90 ; back to absolute mode
G1 X100 Y100 F2000 ; put head over the centre of the bed, or wherever you want to probe
G30 ; lower head, stop when probe triggered and set Z to trigger height
Bltouch is in io7 (on the main board) per the instructions. Z steppers are 1.0,1.1,1.2 (eg the three drivers on the expansion).
Hi,
I'm having an issue getting my z homing working. My bltouch appears to be working perfectly - I can test it - deploy it - retract it - get a trigger when I press it and it's deployed etc.
However - z homing just continues past the trigger.
I wonder if the firmware limitations here - https://duet3d.dozuki.com/Wiki/Duet_3_firmware_configuration_limitations - apply (I'm running the latest stable releases of everything). The firmware limitations suggest that applied to RC2 - but I don't see any update that suggests they are all resolved.
Specifically - my config is that I am driving my 3 Z steppers from the expansion board but I am using my bltouch on the main board.
The firmware limitations
Endstop switches connected to the main board cannot control motors on an expansion board.
Z probes connected to expansion boards are not supported.
Suggest that this might be the issue.
Is that right? And if so - is there a solution?
Kind Regards,
David