@phaedrux - see, that's what I'm talking about! Innovation, dare to explore and try. If we gave up easily, there never would have been reprap in the first place
BTW @Phaedrux - have you patented this, coz I might try :0)
@phaedrux - see, that's what I'm talking about! Innovation, dare to explore and try. If we gave up easily, there never would have been reprap in the first place
BTW @Phaedrux - have you patented this, coz I might try :0)
@sinned6915 I'm not sure I actually stated any expectations, nor questioned anyone's credentials. I'm here to seek a simple answer. The simple answer to the question just needs to be "a plate of x and y size, needs to be z thick". Based
on many other factors then I can make a decision, with one more blank filled in.
I've seen terrible warped beds work "ok" (I used to have one). So I know not to "need" perfection. I'm pragmatic.
Many times I've got through life with "good enough" solutions, by listening, learning and then acting, learning some more when I stuff up, and iterating. That's all I'm doing here. I'm not sure how the impression was gained that I'd be acquiring iron or granite plates. I just find this diverse thinking interesting and educational.
@theruttmeister - I've never been to the "real" Perth, but I'm originally from Yorkshire. But you could tell that from the accent, right?
So the best answer to the question sounds like ~22mm
@jens55 we are kindred spirits.
@o_lampe I did contact one tombstone supplier, but they were a dead loss!
I don't know if it was CoVid invoked, but the guy couldn't stop coffin. (ouch)
I think if anybody could make a printer lift a monolithic build plate, it would be @deckingman
@jens55 I do like the look of that. Reminds of the Jubille. Very clean build.
Cheating? Who made the rules?
@theruttmeister yep much of what you've said on aluminium I've either done on previous build (525x525 + kinematic mounts). The granite is a fascinating idea too.
Here in Perth, Western Australia, we focus on getting iron ore out of the ground. So buying a tipping tray for a 250tonne capacity hail pack is easier than getting MIC6. Typically we have to wait weeks. Also shipping interstate at rates where shipping doesn't rise above material cost, can take weeks, if needed the thing you want is available in country.
So sometimes we have to get creative
@slimshader hey thanks for the insights. I'm not a first time builder, and all of these "safety" aspects are built into my current (pardon the pun) 525x525x8.5mm build plate.
8.5mm? Yep it was an extruded aluminium plate milled down from 10mm to until had <= 0.1mm deviation across the surface. This is kinematically mounted, so expansion is taken into account. Mains powered/SSR, of course, fuse, of course.
Weight is easy to calculate once I know a thickness that is required to reduce the bowing to an acceptable level.
Thanks again.
@falkia and others, thank you. I imagine there are lots of challenges. But I've seen claims from people who have built this size or bigger (e.g. 1.5m) Not sure if they used "multiple heat zones".
@dc42 - A voron style would be a good idea for sure.
I'm just keen to know the dimension of the plate. I'm aware of there being many other challenges.
Could anybody please tell me the required thickness of an aluminium plate sized at 1000x1000 which would have the smallest possible "reasonable deflection" due to it's own weight, support at three point like a triple Z kinematic bed support.
And, does anybody have any experiences of building a printer with this build area. Were any alternatives such as a glass build plate (minus any aluminium plate beneath) considered?
Thanks!
Chris
Wow I can't believe how off topic things have gotten, and how much energy is being consumed. It looks like there is a 1.0 -> 1.1 so minor revision.
I can confidently say as a customer (not someone who is thinking of buying) that I expect revisions and major upgrades to be released. As long as the product I bought meets my requirements, I've not been disadvantaged, underserviced or left behind in anyway. I got what I needed, and paid for, even if a new one comes out tomorrow.
The Duet team is incredibly honourable, and many have given 100s to 1000s of hours of their time supporting this community.
I love that Voron design posted previously which really integrates the tool board into the carriage assembly. Nice work.
Can't wait for v1.1 to arrive in Australia. Everything should land here first, as we're upside down, underneath most of you, so a few boards should fall down here quickly I think
SOLVED: Issuing M18 to turn off motors results in probe responding to deploy/retract.
Recap of issue:
Suspect cause of issue is incorrectly formed stop, sleep, cancel scripts.
Perhaps these scripts should contain M18.
@Phaedrux many thanks for your assistance and input.
FOLLOW-ON Note in case it helps anyone else. This is my end of job script:
G1 H2 Z460 F3000 ; Drop the bed
G1 H2 X1 Y1 F8000 ; Move head near home position
M18 ; Motors off
M0 ; STOP which turns off heaters
I'm not sure why, but whilst there were instructions in stop.g the bed heater was shutdown but not the nozzle. So I emptied stop.g and in my shutdown.g the above results in the bed being parked, all heaters off and motors turned off, which finally results in the probe responding again.
@Phaedrux re: standalone mode, unfortunately I can't do that.
Thanks for the category change, makes perfect sense.
I'll keep trying different things as they occur to me and keep you posted.
Still no luck. Long story short, I'd previously configured to join the beta program and at the time there were some sort of certificate errors. Today I didn't get those errors, so did apt-get update/upgrade and am now running v 3.3-b2.
Keeping it simple, the issue is consistent and can be described as executing G28, G32, setting nozzle temperatures, after which I can deploy and retract the probe multiple times. If I extrude, then execute M0 or M1...I can't deploy the probe until I do an emergency stop.
Why this is an issue is because after a print completes, I can't start another print, because without the prove, I can't home the bed for the next job.
So I'm happy to work around for the moment by doing a reset between jobs. Would still appreciate any insights / trouble shooting steps.
Great insights thank you, yes, I can certainly try the upgrade to 3.2.2 this week.
Thanks for the clarification on stop.g. The issue is repeatable outside that context though...i.e. I run the prepare, then purge scripts then the probe stops responding. I can test again after the 3.2.2 upgrade.
Confirming that running my prepare macro is ok, and probe deploys / retracts. After running the purge script the probe becomes unresponsive. I thought it would be useful to capture M122 whilst it was in this state. Hope that helps...
M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956BA-NA3TJ-6J9DL-3S86J-9T9AT
Used output buffers: 1 of 40 (10 max)
=== RTOS ===
Static ram: 154604
Dynamic ram: 162848 of which 44 recycled
Exception stack ram used: 552
Never used ram: 75168
Tasks: NETWORK(ready,1980) HEAT(blocked,1200) CanReceiv(suspended,3820) CanSender(suspended,1420) CanClock(blocked,1436) TMC(blocked,68) MAIN(running,4952) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 00:02:27 ago, cause: software
Last software reset at 2021-03-13 05:20, reason: User, spinning module LinuxInterface, available RAM 74760 bytes (slot 3)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min 38.4, current 38.5, max 38.8
Supply voltage: min 27.9, current 29.4, max 29.4, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.2, current 12.2, max 12.3, under voltage events: 0
Driver 0: standstill, reads 60320, writes 17 timeouts 0, SG min/max 0/130
Driver 1: standstill, reads 60320, writes 17 timeouts 0, SG min/max 0/138
Driver 2: standstill, reads 60321, writes 17 timeouts 0, SG min/max 0/128
Driver 3: standstill, reads 60321, writes 17 timeouts 0, SG min/max 0/222
Driver 4: standstill, reads 60321, writes 17 timeouts 0, SG min/max 0/219
Driver 5: standstill, reads 60322, writes 17 timeouts 0, SG min/max 0/61
Date/time: 2021-03-13 05:22:37
Slowest loop: 4.87ms; fastest: 0.14ms
=== Storage ===
Free file entries: 10
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 ===
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 371, MaxWait: 31970ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 38, completed moves: 38, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is ready with "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
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 0.83ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 0 of 8
Next stack level
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 30.52
OK this is interesting - this is a macro I wrote to do an initial purge. After I run this script, when executing GCODE to deploy probe the probe doesn't actually deploy. But the status isn't showing busy. If I send M999 I can then execute deploy probe again.
PURGE MACRO (results in probe not deploying after this is executed)
T0 ; select Tool 0
G1 X150 Y495 Z50 ; Drop the bed to allow clear space for the nozzle and move to purge bucket
G92 E0
G1 E100 F300 ; purge 10mm
G92 E0
G91
G1 X-75 F3000 ; Wipe the head side to side
G1 X75 F3000
G1 X-75 F3000
G1 X75 F3000
G90
G28 XY ; Home X and Y
Quick additional notes. After power on and completion of the PREPARE macro, I can execute G29 and get a height map. I can then deploy and retract probe.
I'll try some different GCODE sequences to see if I can isolate what might leave the status as busy.