I just finished testing it and it's working great; it uses a $0.50 optical endstop.
Check it out, I'd love to hear some feedback!
I just finished testing it and it's working great; it uses a $0.50 optical endstop.
Check it out, I'd love to hear some feedback!
@chrishamm Heyy amazing thank you for the update!
Installed 64bit on my Duet3 MB6HC + Rpi3b+ and everything running mighty fine right out the box this time -- no vnc/hdmi shenanigans like with the experimental build.
Hdmi touchscreen feels super snappy too, way more responsive than back on buster, outstanding work, now to push some plastic!
Just published the updated model using a $3 Schmitt trigger equipped arduino sensor;
Getting much more consistent reading
Check it out there
Awesome Stuart, thanks for carrying on Danal's work
Looks well documented too, I'll give it a shot over the weekend.
Very neat of you to handle issues outside of your own setup too
Do you think in it's current state this could realistically be implemented as a plugin in DWC for a possible GUI?
@o_lampe Excellent question; it worked about fine for me with pretty high tolerance (ended up running 25-200%) but would still get occasional spikes at 400% triggering false positives
Then @JohnOCFII made this awesome in-depth investigation using a logic analyzer and found out that the signal was indeed noisy and implementing a schmitt trigger solved the issue; https://forum.duet3d.com/topic/19284/inconsistent-results-with-optical-encoder-wheel-filament-sensor
So I found an IR sensor that has a shmitt trigger integrated and modified the housing for it
brilliant, that would give a great second life to my old ipad; the web interface gets clunky through safari
I'll give it a shot!
Hey man I just noticed I had this lines in my config.g here for my sensorless homing;
it seems like Stealthchop would not engage unless these are in place
; Stealthchop parameters
M915 P0 S3 F1 H134 T1 R0
M915 P1 S3 F1 H134 T1 R0
I do not not why, but my guess would be around T parameter that controls the coolstep register according to https://duet3d.dozuki.com/Wiki/Gcode#Section_M915_Configure_motor_stall_detection
Edit: Also the Hmin parameter; for which I made a calculator here:
https://docs.google.com/spreadsheets/d/1gCapl-1CZh7Zz267W_CFtLBbBV-UMDjpXMGDIyr5oE4/edit?usp=sharing
@dc42 thoughts?
@bearer Oh boi I sense we'll be needing incremental encoder support
Would be fairly simple to implement though; "just" adding a second sensor and 2nd row of slots from the hardware point...now to add it in the code..
I use a custom Flex3Drive with absolute shortest filament path so I haven't experimented with PA either
@jay_s_uk Well I'd be damned; didn't think of removing them but these were indeed tied to my TMC5160 tuning
Also somehow missed that I had M569 set to D3...
Set it back to D2, disabled M915 and it seems to be running like a champ now, thank you very much!
Let's push some plastic now
Hi @Phaedrux , yes mounting them was the first thing I did upon reception; when the problem occured I removed the belts to insulate the gantry binding possibility and kept testing this way to prevent crashing it due to the stalls
@JohnOCFII brilliant results that is a huge improvement
I actually have a C045 single inverter from my TBS Crossfire mod lol; might give it a shot
There's one thing I miss a lot from Octoprint and just realized even Wordpress has it too;
A full window click-n-drag area
How many times did I clik and drag my gcode only to realize DWC is in the wrong tab....so sad and frustrating
Now I understand that there are 3 main folders where files can be dropped in; sys, macros and jobs.
So how about following the Octoprint split window (upload to internal/SD card) with a twist?
I'm proposing splitting the window in 3 areas when a file is dragged over
With a 1/5 - 3/5 - 1/5 repartition for instance; giving the largest area to the most used one, gcode
so that's 1/5 on either side for sys and macros
and the remaining 3/5 in the middle to upload to jobs
Wouldn't that be useful to everyone?
Please comment or upvote if you think so too
Cheers!
Hello!
I've spent the last couple of days trying to figure out how to setup Stealthchop on my machine and I've made a lot of progress; it's much quieter now but only up to exactly 66mm/s.
From 67mm/s on diagonal moves (then all moves at higher speeds) the driving stepper starts having a complete seizure while moving.
Quite the spectacle; I had to remove the belts just to make sure it wasn't the gantry.
The seizure stops as soon as I send it back to Spreadcycle and it's back to the usual screamy billy
Would anyone know what's happening and how can I enjoy Stealthchop up to normal print speeds?
The machine is a CoreXY; Railcore II ZL
It runs a Duet3+SBC with LDO NEMA23
Powered by a 24V 350W Meanwell
Here's what the relevant config.g lines look like
; Trinamic Drive Tuning
M569 P0 V30 H5 ; X - Set tpwmthrs so StealthChop runs up to 125mm/sec
M569 P1 V30 H5 ; Y - Set tpwmthrs so StealthChop runs up to 125mm/sec
; Stealthchop parameters
M915 P0 S3 R0 H134 T1
M915 P1 S3 R0 H134 T1
; Steppers Settings
M350 X16 Y16 Z16 I1 ; Set 16x microstepping for axes with interpolation
M350 Z16 I1
M350 E16 I0 ; Set 8x microstepping for Flex3Drive extruder interpolation OFF
M906 X1650 Y1650 Z1008 E420 I35 ; Set motor currents (mA) and motor idle factor (%)
M84 S30 ; Idle timeout 30s
M201 X1600 Y1600 Z100 E120 ; Accelerations (mm/s^2) (Was 2500)
M203 X24000 Y24000 Z900 E2400 ; Maximum speeds (mm/min)
M566 X800 Y800 Z100 E6 ; Maximum jerk speeds mm/minute
M208 X290 Y303 Z325 ; Set axis maxima and high homing switch positions (adjust to suit your machine)
M208 X-27 Y0 Z0 S1 ; Set axis minima and low homing switch positions (adjust to make X=0 and Y=0 the edges of the bed)
M92 X160 Y160 Z1600 E4130 ; Steps/mm
; Dynamic Acceleration Adjustment
M593 F52
And what M569 returns; based on a fellow member values
M569 P0
Drive 0 runs forwards, active low enable, step timing fast, mode stealthChop, ccr 0x08053, toff 3, tblank 1, hstart/hend/hdec 5/0/0, pos 856, tpwmthrs 30 (156.2 mm/sec), thigh 5 (937.5 mm/sec)
Thank you!
@bearer , @aidar
Well that's uncanny;
I thought R2200, P1.0 were the Duet3 standard values so I left them on
Removing them actually solved the issues; PID tuning is complete and it heats up to temp in seconds
That board is smarter than it looks
Thanks!
@osterac Yep as @Phaedrux said (thank you for the ping) there is a notable discrepancy with your setting
Can you try changing E5 to E51? This helps averaging out the pulses over a whole turn of the wheel; smoothes out printing artifacts of your encoder wheel
L value also depends on which encoder wheel model you chose to go with, you could get a base value by dividing that 51mm perimeter by the amount of slots, but eventually you would replace it with the closest measured value
--> in your case 38mm is abnormally high; I would check that the rubber wheel has a good grip on the filament and nothing is rubbing
Cool thank you @bearer @Danal and @chrishamm; I didn't know about the instability; everything's updated now, hopefully that fixes it!
@osterac hmm that's still way off; ideally you would get as near to 100% on both min/max
You did print the revision 2 right? With the schmitt-trigger sensor?
If so you might want to check if the axle is spinning properly when you're feeding filament through the sensor;
Just take a piece by hand, feed it through the sensor and watch for the axles spinning/sensor blipping.
On V2 you can also pinch the axle while it spins to feel how well does it grips
@osterac Ok I just updated the whole files on the thing; there's only one version now for clarity
And yep you really need your seams to be well tuned on that wheel; if they're protruding a bit you can still trim them with flush cutters or a razor blade