Posts made by monster

I practically don't know how bed is going to look like. At the moment it is:

• Polycarbonate sheet (PLA sticks to it well and it bendable - easier to get part out)
• Below it some fire resistant "thing" from construction/building domain I assume.
• "Thing" sits on 3 leveling bolts which held by acrylic arm.

I'd like to get heated bed eventually as I would need to print ABS.

• So for now I see a glass or some designed specially for 3d printing surface or again polycarbonate - need to test if it holds bed temperature.
• Which will sit on top of I guess an aluminum which will be adjusted by same leveling bolts. But bolts will be not anymore sitting on the acrylic arm (arm is too shaky) - they will be on brackets. One bracket already there. Another bracket I'll make and it will be moved by second Z ball screw&stepper.
• Under aluminum there will be a heated silicon mat I guess.
  -- I guess heated PCB would be lot better but I'd need 35cm x 35cm (about) size which isn't standard for anything neither for silicon mats. Not sure if I wanna dive in making one myself with nichrome string...

So I'm not sure that future surface will be like.
Will it be compatible with inductive proximity sensor or IR. But mechanical sensor should do in any case.

Ups, I should have bought BLTouch from you
@CaLviNx
What kind of inaccuracy you are talking about? 1mm - 0.1mm ? More or less?

by the way is "move.axes[0].max" is available in RC7 ?
Also is there way to define own constants? E.g. I could define X Y coordinates at witch magnet for Z endswitch is locates and refer to those constants in homing g files.

Quickhomexy.g

; quickhomexy.g
; called to home x and y axes
;
; generated by RepRapFirmware Configuration Tool v2.1.8 on Mon Mar 30 2020 01:10:04 GMT+0300 (Eastern European Summer Time)
M117 "Quick homing X&Y begin"
G90
;if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
;  M98 P"quickhomexy_doublepass.g"
;else
;  M98 P"quickhomexy_singlepass.g"

if move.axes[0].homed && move.axes[1].homed && move.axes[2].homed
    M98 P"quickhomexy_singlepass.g"
else
    M98 P"quickhomexy_doublepass.g"
;G91                     ; relative positioning
;G1 H1 X-300 Y-300 F900  ; move slowly to X and Y axis endstops once more (second pass)
G90                    ; absolute positioning

M117 "Quick homing X&Y end"

and

;M98 P"quickhomexy_doublepass.g"
;M291 P"Double"
M117 "Double pass X&Y homing"
G90
G1 H1 X10 Y10 F5000
G91
G1 H1 X-300 Y-300 F4000
G1 X10 Y10 F600
G1 H1 X-20 Y-20 F600

and

; M98 P"quickhomexy_singlepass.g"
; called to home x and y axes
;
; generated by RepRapFirmware Configuration Tool v2.1.8 on Mon Mar 30 2020 01:10:04 GMT+0300 (Eastern European Summer Time)
;M291 P"Single"
;M300 S200 P100 					; play beep - debug sound 
M117 "Single pass X&Y homing"
G90
G1 H1 X10 Y10 F2000 	; move quickly to X and Y axis to 10cm away from expected home (first pass)
G91                     ; relative positioning
G1 H1 X-20 Y-20 F900  ; move slowly to X and Y axis endstops once more (second pass)
G90                    ; absolute positioning

I took a screenshot to show that the error message appears by the end of homingz

Homing z code is below (sorry it is messy at the moment)

; homez.g
; called to home the Z axis
;
; generated by RepRapFirmware Configuration Tool v2.1.8 on Mon Mar 30 2020 01:10:04 GMT+0300 (Eastern European Summer Time)
G91               ; relative positioning
;G1 Z10 F500 		; lower the bed slowly because it can already be in lowest position
G90

M98 P"quickhomexy.g"

G90              ; absolute positioning
;if move.axes[0].homed && move.axes[1].homed && move.axes[2].homed
;	G1 H2 X150 Y150 Z15 F3000  ; move quickly to X and Y axis middle (where Z home trigger is) and at the same time bring Z to 15mm befor home spot
;else 
G1 H2 X150 Y150 F4000  ; move quickly to X and Y axis middle (where Z home trigger is) not moving Z

;G1 H2 Z10 F2000    ; move quickly to 10cm away from expected home

G91               ; relative positioning
G1 H1 Z-200 F500 ; move Z down until the endstop is triggered
;G92 Z0            		; set Z position to axis minimum (you may want to adjust this)
G92 Z2.8

; Uncomment the following lines to lift Z after probing
;G91              ; relative positioning
;G1 Z10 F2000       ; lift Z relative to current position
G90              ; absolute positioning

M117 "End of Z homing"

So I could say yes I'm sure.

One finding since yesterdays RC7 installation.
I started to get (while homing) error message

G28 Z
Error: Code is not supported
Error: Code is not supported

And I started to figure out where do I have that command. (Btw according to https://duet3d.dozuki.com/Wiki/Gcode#Section_G28_Home that shouldn't cause any errors but anyway)
Then I did download all files from my system directory and searched for "G28" in all *.g files.
And I found one occasion "G28" (without Z parameter) in my start.g which isn't called during homing.
This is why I writing here is there a chance of a bug? That somehow "G28 Z" called automatically? Perhaps when WebUI "Home Z" pressed?
And why it does produce error message...?

@dc42
I've been using M300 in debug purposes. Figuring out which *.g script just being run or in which part of the script printer now.
In case M300 isn't producing any sounds anymore what would be my method to do this kinda feed back messages?

Though homing happens...

I'm not sure.

I tried to run this test macro (hoping that IF will work in RC7)

if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
    M300 S300 P200 
else
    M300 S100 P200 

And got: Code isn't supported
And M300 S100 P200 is being sent to controller with no error replied, though no sound produced. This is new behavior.

@bearer

pi@beast:~ $ echo M997 S0| sudo /opt/dsf/bin/CodeConsole
Connected!

pi@beast:~ $

WebUI up and

Board: Duet 3 MB6HC (MB6HC)
DSF Version: 1.3.2.0
Firmware: RepRapFirmware for Duet 3 MB6HC 3.01-RC7 (2020-04-14b3)

Note: You can install updates on the System page.

Hi,

I just used https://duet3d.dozuki.com/Wiki/Getting_Started_With_Duet_3#Section_Duet_3_RepRapFirmware_notes
in order to get me latest RC
log file of my console to Pi is attached (in case I did some stupid move).
log.txt

Now it sits in last line for too long:

pi@beast:~ $ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  binutils binutils-arm-linux-gnueabihf binutils-common libbinutils libgl1-mesa-dri libjavascriptcoregtk-4.0-18 libwebkit2gtk-4.0-37 mesa-va-drivers mesa-vdpau-drivers pcmanfm
The following packages will be upgraded:
  duetcontrolserver duetruntime duetsd duetsoftwareframework duettools duetwebcontrol duetwebserver reprapfirmware
8 upgraded, 0 newly installed, 0 to remove and 10 not upgraded.
Need to get 32.4 MB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 https://pkg.duet3d.com unstable/armv7 armhf duetsoftwareframework armhf 1.3.2 [1,706 B]
Get:2 https://pkg.duet3d.com unstable/armv7 armhf duetsd all 1.0.6 [2,010 B]
Get:3 https://pkg.duet3d.com unstable/armv7 armhf duettools armhf 1.3.2 [50.3 kB]
Get:4 https://pkg.duet3d.com unstable/armv7 armhf duetcontrolserver armhf 1.3.2 [176 kB]
Get:5 https://pkg.duet3d.com unstable/armv7 armhf duetruntime armhf 1.3.2 [28.8 MB]
Get:6 https://pkg.duet3d.com unstable/armv7 armhf duetwebserver armhf 1.3.1 [71.4 kB]
Get:7 https://pkg.duet3d.com unstable/armv7 armhf duetwebcontrol all 2.1.2 [2,815 kB]
Get:8 https://pkg.duet3d.com unstable/armv7 armhf reprapfirmware all 1.3.2-1 [478 kB]
Fetched 32.4 MB in 18s (1,838 kB/s)
Reading changelogs... Done
(Reading database ... 79400 files and directories currently installed.)
Preparing to unpack .../0-duetsoftwareframework_1.3.2_armhf.deb ...
Unpacking duetsoftwareframework (1.3.2) over (1.2.4.0) ...
Preparing to unpack .../1-duetsd_1.0.6_all.deb ...
Unpacking duetsd (1.0.6) over (1.0.5) ...
Preparing to unpack .../2-duettools_1.3.2_armhf.deb ...
Unpacking duettools (1.3.2) over (1.2.4.0) ...
Preparing to unpack .../3-duetcontrolserver_1.3.2_armhf.deb ...
Unpacking duetcontrolserver (1.3.2) over (1.2.4.0) ...
Preparing to unpack .../4-duetruntime_1.3.2_armhf.deb ...
Unpacking duetruntime (1.3.2) over (1.2.4.0) ...
Preparing to unpack .../5-duetwebserver_1.3.1_armhf.deb ...
Unpacking duetwebserver (1.3.1) over (1.2.3.1) ...
Preparing to unpack .../6-duetwebcontrol_2.1.2_all.deb ...
Unpacking duetwebcontrol (2.1.2) over (2.0.7-1) ...
Preparing to unpack .../7-reprapfirmware_1.3.2-1_all.deb ...
Unpacking reprapfirmware (1.3.2-1) over (1.2.4.0-1) ...
Setting up duetruntime (1.3.2) ...
Setting up duetwebcontrol (2.1.2) ...
Setting up duetcontrolserver (1.3.2) ...
Installing new version of config file /opt/dsf/conf/config.json ...
Setting up duettools (1.3.2) ...
Setting up duetwebserver (1.3.1) ...
Installing new version of config file /opt/dsf/conf/http.json ...
Setting up duetsd (1.0.6) ...
Setting up reprapfirmware (1.3.2-1) ...
Sending update request to DCS...

and nothing happens.
What to do?

---

added later:
It is Duet 3 + Pi

thanks

You left me no choice! Ordered!

Hi,

I'm very new in the domain.
Reworking BFB Touch 3D old printer with newer controller (Duet 3 + Raspberry Pi).
This re-build is already in a state that it can print some. But I'm already managed to get a headache from leveling bed and particularly even from finding Z0.
At the moment Z axis uses reed end switch (magnet is sitting right below middle of the bed). This end switch is well visible on first photo.

Very often people refer to z-probe and how good to have it. And so I feel I can't live without one any longer
But which one should I go for is the question here.
Could you advise some sensor(probe) to go with considering present hardware visible in attached photos.
I also assume with some solutions I can get rid of that reed sensor and with some I still keep it?

@bearer said in Firmware update woes. Duet3:

Duet 3 or Duet 3 + Raspberry Pi? (Also probably better to make a new thread to keep it easier to follow the information later)

Duet 3 + Raspberry Pi it is! Shall it go to new thread then?

P.S. When I was beginning with it - I tried to flash SD card following some instructions. But I couldn't succeed with that card. Fortunately with card that came with Duet 3 it went better. Though I'm not sure is this information even relevant, you see this needs "for dummies" level instructions

May I kindly ask, in the end do we have a instructions how to do it for dummies?
I kinda got to update mine duet 3 and reading this post is scary

Hi, I got similar problem with exactly same model to print
But in my case whole model prints very well except first layers corners and corners only were over extruded.

Since in your print it is in bottom and up layers, that might suggest that you could have a look on slicer settings for top/bottom check if you have some hidden settings in slicer and unhide them. Hope you find a clue.

Regarding mine problem I wasn't even looking for that solution just because I have generally something very wrong with filament flow in my setup...

I remember seeing somewhere setting (or something) that has something to do with extrusion in slows down for cornering, but can't remember where. I'll post if I find.

I can't remember where did I read that by now.
But back then when I was choosing controller I did read somewhere that when Duet 3 used with Pi it (or I guess Pi) can do slicing. And if my memory not mistaking that was saying about actually Cura slicer in Pi.

Is it something I could try? I mean try to use that slicer.
Hope it is not to difficult to setup and use. May be that could solve my problem...

@Phaedrux said in How to calculate feed rate?:

Is that with 6500 or 650? If this is correct, then your steps per mm is correct.

Something else is wrong in Cura.

with 6500

M92 X87.40 Y87.40 Z1060.00 E6500.00:6500.00:6500.00 ; set steps per mm

@Phaedrux said in How to calculate feed rate?:

The E steps per mm is likely too high which explains the 800% flow rate.
M92 E6500.00:6500.00:6500.00

Try a value of 800 and redo the extruder calibration again.

I must be not getting something big here.
When you suggest putting lower values - that means there will be less extrusion per mm in print, isn't it?
I just changed 6500 -> 650 and that made (together with 100% flow in Cura) almost like no extrusion.
Though when I use this interface
screenshot from guide
with setting = 6500
And, say, command to extrude 5mm with 1mm/sec extruder actually "eat" 5mm of raw filament and it takes 5 sec.