Steps per mm keep changing
-
because you need to address canbus extension. thats the number before the dot.
so ie 121.0 -
Ok, an otherwise incoherent burst of irrational OCD rage averted
Someone might want to add that to the wiki though.
Makes no mention of such a thing. And a 3 minute browse of the Duet 3 pages also fails to mention it.
But then I'm one of those people poking around and grumbling about the fact that the SCARA guide is now out of date due to 3.0 changes.
(I know, I know, its a wiki, if I really want it fixed I should go fix it).
I assume that just single digit entries still work the same? 0 or 1 working the same as 0.0 and 0.1?
Isolate, substitute, verify.
-
@theruttmeister The Can address for the main board is optional. That is to say, the preceding "0." Is not needed if one only uses a duet 3 main board. If no preceding board number is specified, then the firmware will default to assuming the driver referred to is on the main board. So 0.0 and just 0 would both refer to driver zero on the main board.
Personally, I prefer to always explicitly define values which would otherwise have a default setting - just in case a firmware change altered the default behaviour. Also, because I use 3 expansion boards where the board number is required, it makes config.g more legible if all drivers are referred to using board.driver format. -
@theruttmeister said in Steps per mm keep changing:
Makes no mention of such a thing. And a 3 minute browse of the Duet 3 pages also fails to mention it.
only needed when using expansion boards, so its covered there.
-
@akhilnex said in Steps per mm keep changing:
M350 X32 Y128 Z128 I1 ; configure microstepping with interpolation
M350 E128:128:128 I0 ; configure microstepping with interpolation
M92 X6400.00 Y5120.00 Z5120.00 E1207.22:1207.22:1207.22 ; set steps per mmThe settings don't fit for a 2005 spindle.
The calculation is steps/rotation * microsteps / mm/rotation,
- i.e. 200 * 32 / 5 = 1280 for X
- 200 * 128 / 5 = 5120 for Y and Z
so the M92 for X is wrong.
You can also check the M122 and check for hiccups whether you have lost steps.
Your M203 setting of speed is very low (only about 6 mm/s), this is also strange.But your question was about the extruder:
E128 with I0 without interpolation could mean too high step rate (3 extruders, plus xyz steps), but this would show up in the hiccup reporting of M122. Speed for extruder is maximum 20 mm/s for each extruder, and 1200 steps/mm meaning 24 kHz for every extruder, total 72 kHz. And I would check the current for the Nema 17 steppers, whether 2100 mA is 50 to 80% of the RMS current in the datasheet.I read an intersting article yesterday https://www.geckodrive.com/support/step-motor-basics/accuracy-and-resolution.html about accuracy of steppers. The linearity of steppers of microsteps varies by stepper models. A high microstepping doesn't mean high accuracy. Imho a high ratio gear is a better idea if you want to achieve a high precision of the extruders.
-
Gentlemen,
I have now taken a bunch of pictures to clear things up and I apologize for little information past evening. Let me start by explaining the setup in a more detailed manner. The entire CNC/3D printer is an experimental build and I had been running the CNC (X,Y,Z) portion of it originally through another chipset and external drivers for steppers with good results and accuracy.
The reason I changed to Duet 3 was to make a machine that can also 3D print and take advantage of being a CNC mill when needed.
This is based on the reprap configurator tool:
Pictures below show the entire build and the controller with dual Z-axis (that I plan to manually change to based on either I am using CNC mill or 3D print function)
The picture below shows the 3 filaments mounted on a tool board with NEMA 17 motors. The filament runs through a 7.5 mm hob nut and to the hot end (hot end never tested still working on steppers):
What I have tried so far?
-
Changed the microstepping to 16x, 32x, 128x with and without interpolation with same results.
-
Changed motor current in hopes to reduce any back EMF that may be causing deviation in steps per mm
-
Played with steps per mm, acceleration, max speed, current etc. to see if it makes any difference.
So far I have deviation in all drives that is off by a known amount and I have been wondering if there was a possibility to use a multiplying factor based on deviation that I have been noticing.
Please find the config.g file attached. I may have tweaked a few things.
-
-
@Veti Thanks. I checked and I am using the cartesian type. Also I have posted the config.g file in my reply to the main thread.
-
@theruttmeister said in Steps per mm keep changing:
You say that your axies are all running that same leadscrew... but your settings don't match that. Your Y and Z match what you say, your X is off.
@theruttmeister you are right and I forgot to mention past evening that I installed a gear reducer (5:1) to run the heavy Y axis gantry.
-
those are some beefy stepper motors. can you post the specs for them?
-
Specification table is on the second tab. I didn't find a torque curve or any performance graph though.
-
you should aim for about 75% of the rated current.
so around 3150 for the nema23.
and stay with x16 with interpolation for now.
going high puts unnecessary load on the cpu. -
@Veti I have made the changes to 16x and the deviation is still present. Although the amount of deviation is slightly different for requested [actual] readouts: 50 [ 48.5 mm], 100 [102 mm], 150 [155 mm], 200 [210 mm], 250 [265 mm], 300 [317.5]. It seems like the pattern changed but the amount exceeding follows a similar trend starting with low deviation and increasing at 2.5 mm increments as the the requested distance goes up.
config (1).g -
@akhilnex please be aware that 1:5 gears are often 1:5.18 gears (exactly 1: 5+2/11 = 1: 5.181818). The datasheet will tell you.
-
@JoergS5 that's a good point and I think it is true 5:1 planetary reduction gearbox. Here is the link of what I got on Amazon: https://www.amazon.com/dp/B089R8CC1Z/ref=cm_sw_r_cp_apa_fabc_.-m6FbC0RS0XV
Seems like with the new settings the x,y,z axis are running quite accurate. However the NEMA 17 extruder steppers are the one causing trouble.
-
I used these for my belt driven Z axis conversion.
The 5-to-1 is a true 5-to-1.
They have a similar "economy" line product which is not.
Frederick
-
yes, looks like a true 5:1
-
@akhilnex did you check M122 after running the steppers for some time? M122 reports several possible problems, please post the result. (one is hiccups, but also stepper problems, voltage problems etc.).
-
@JoergS5 M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v1.01 or later (standalone mode)
Board ID: 08DJM-956L2-G43S8-6J9D0-3S46Q-9U2GD
Used output buffers: 3 of 40 (40 max)
=== RTOS ===
Static ram: 154604
Dynamic ram: 162740 of which 20 recycled
Exception stack ram used: 376
Never used ram: 75476
Tasks: NETWORK(ready,356) ETHERNET(blocked,436) HEAT(blocked,1200) CanReceiv(suspended,3820) CanSender(suspended,1488) CanClock(blocked,1424) TMC(blocked,60) MAIN(running,4512) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 00:31:39 ago, cause: software
Last software reset at 2020-12-27 10:43, reason: User, spinning module GCodes, available RAM 75476 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN
Error status: 4
MCU temperature: min 40.6, current 41.1, max 41.5
Supply voltage: min 24.0, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.1, max 12.2, under voltage events: 0
Driver 0: standstill, reads 20644, writes 14 timeouts 0, SG min/max 0/0
Driver 1: standstill, reads 20632, writes 27 timeouts 0, SG min/max 0/81
Driver 2: standstill, reads 20645, writes 14 timeouts 0, SG min/max 0/0
Driver 3: standstill, reads 20646, writes 14 timeouts 0, SG min/max 0/0
Driver 4: standstill, reads 20646, writes 14 timeouts 0, SG min/max 0/0
Driver 5: standstill, reads 20634, writes 27 timeouts 0, SG min/max 0/431
Date/time: 1970-01-01 00:00:00
Slowest loop: 999.77ms; fastest: 0.13ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 2.8ms, write time 29.6ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 373, MaxWait: 1347113ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 12, completed moves: 12, 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
=== GCodes ===
Segments left: 0
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
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: 57.01ms; fastest: 0.03ms
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: 1 of 8- Ethernet -
State: active
Error counts: 0 0 0 0 0
Socket states: 5 2 2 2 2 0 0 0
=== CAN ===
Messages sent 7600, longest wait 0ms for type 0
=== Linux interface ===
State: 0, failed transfers: 0
Last transfer: 1899941ms ago
RX/TX seq numbers: 0/1
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
- Ethernet -
-
Since X,Y and Z gantries are working fine, I am wondering if the NEMA 17 motors on E0,1,2 that I purchased from stepperonline are faulty. I am thinking about ordering atleast one different brand NEMA 17 and a regular extruder hob gear to check and see if it works any better.
-
Can an issue arise from having NEMA 23 and NEMA 17 running on the same board? Should they all be the same 23s or 17s?
