Duet Noob trying to join the cool kids
-
On most machines it's not possible to use native x256 microstepping because it requires unfeasibly high step pulse generation rates. So I suggest you change your M350 and M92 commands to use x16 microstepping with interpolation enabled. You can experiment with higher native microstepping later if you want, when you have everything working.
-
I currently have a dual Z screw setup using leadscrews.
Tr8*8-4
Lead Screw Diameter ∅ 8 (mm)
Pitch 2 (mm)
Lead 8 (mm)
Stainless Steel
I plan to change out the leadscrews for belts when I get the parts in a month+ (long shipping time).
Obviously running the drivers (x256) on the DuetEth, and bought all e3d high torque stepper moters. Extruder is running on small but powerful stepper.I will make the suggested changes tonight and follow up. Thanks!
-
@phaedrux said in Duet Noob trying to join the cool kids:
M122
I have yet to change anything on the printer. I wanted to make sure you could see the below before I touched anything.
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.01(RTOS) running on Duet Ethernet 1.02 or later
Board ID: 08DGM-9T6BU-FG3S0-7JTDL-3SN6N-TS6VG
Used output buffers: 3 of 20 (15 max)
=== RTOS ===
Static ram: 28476
Dynamic ram: 95940 of which 16 recycled
Exception stack ram used: 508
Never used ram: 6132
Tasks: NETWORK(ready,328) HEAT(blocked,1248) MAIN(running,3540)
Owned mutexes:
=== Platform ===
Last reset 00:06:14 ago, cause: software
Last software reset at 2018-08-31 17:36, reason: User, spinning module GCodes, available RAM 6108 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 28.6, current 28.8, max 28.9
Supply voltage: min 23.7, current 24.1, max 24.3, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 2018-08-31 17:43:21
Slowest loop: 1.10ms; fastest: 0.08ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 421, completed moves: 421
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.4
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
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
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 4.87ms; fastest: 0.04ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state: 5
=== Expansion === -
I think I fixed it, but one of the two things I did confuse me...
- to fix the bed leveling, I went through the RepRap configurator again.
At this point everything just worked better, with one thing to note. The Z Probe offset was now .9. I ran through this process a few times and it was .9 or .91. So I decided to print my test print again...
and it still seemed to print in the air. Just when I was going to cancel the print again, it went to the bed. Odd thing was it wasn't printing the brim I put in S3d. I waited a few minutes and watched because the print was just weird. And then it printed the brim...
It looks like it was printing it upside down! It didn't print the entire object before it started to print the brim, and just seems like the Gcode file had its layers all confused.- I resliced it. I don't know why that fixed it, as I went through the config in S3d, and didn't see anything that jumped out at me that I could do to fix this, and just saved it. Put it on the printer, and even though it is printing the first 9 layers into the glass, its working and just want to see it print something. Once this is done, I will try to level it again.
Just to confirm. What is the Z offset measuring? The distance from where the probe sees the bed, and the bed itself? Or the distance from the Probe to the Nozzle on the Z axis?
I have the Mini Height Sensor. I went with all optical endstops on this printer, and I really like this Mini Height Senor. -
Can you post the first 50 lines or so of that gcode file?
What is your bed surface?
-
@phaedrux
I knew you were going to ask that... right after I saved over it it. I should have shared it right away...
Sorry about that.I print on glass. Right now just testing with PLA, so nothing but glass. I will spray the glass with Glass Build Plate Wizard when I print with PETG.
-
@bluedust I'm just wondering how your probe is being affected by the bed surface. It may be influenced by reflectivity to some degree.
-
The Z offset for a probe should be the distance between the nozzle and the bed, when the probe is triggered. Basically it is used to set the Z to this value, when the probe is triggered. Take your 0.9 as an example: when your probe triggers, the firmware set Z = 0.9mm; so printing at 0.2mm layer height, will move the nozzle closer to the bed, by 0.7mm to be at 0.2mm
How it could be measured, is simply start with a value too big (like 10mm) and let it probe (after probe, mine is set to lift the nozzle slightly, but this does not matter). Next command the nozzle down, when it gets close use smaller differences. Finally when the paper test is good (or alternative method like feeler gauges), note the Z value and do a simple subtraction (Start Z - End Z = Z Offset). Now it should also be noted that this new Z offset also have the paper's thickness in it, Simplify 3D wants to know where the bed is, not the start of the first layer, so that thickness should also be subtracted for best results.
Depending on the probe type, glass can have issues. My IR probe did not always see my glass surface (causing nozzle strikes). These days I stick small white stickers under the probe locations on the glass (more accurately on lamination pouch on the glass - works the same).
The Simplify 3D issue, where it seems to be random, did you notice (in the preview) and large blue squares at some heights? I sometimes get this when slicing and those gcode files are simply unusable. Usually re-slicing produces better results, or sometimes I even have to change settings for a reliable slice.
-
@Jacotheron
Thanks for the info. That helped make more sense of this when trying to calibrate it. Knowing that seems to make it easier for me to do it. I didn't notice anything odd when slicing.I have DC42s IR probe. I bought it right after I saw his write up says it has a high resistance to glass reflection issues. I believe it did say that depending on what's under the glass could cause it problems.
@Phaedrux
I am using DC42s IR Probe. -
The IR probe works OK with a target of uncoated glass with a matt black surface underneath. This is what I use on one of my printers. The problem starts when you put a coating on the glass. Ideally the sensor would only see the reflection from the top surface of the glass, but in practice it sees some from the bottom surface too, and that affects the trigger height. When you put a coating on the glass, that affects the intensity ratio of the two reflections. the coating is rarely uniform, so the intensity ratio varies, and with it the trigger height.