Posts made by pungoboy

Hey all, just saw this post and thought I'd throw my hat in the ring.

Location: New York City, US
Contact: Through forum

I've done logic board repair professionally in the past, like others I'm kitted out with the stereoscope, hot air, all manner of soldering gear etc etc. Also have a suite of test gear for more advanced troubleshooting (scope, 4.5 digit meter, function gen). 2.5 years experience microsoldering, and I've been doing through hole for much longer. Willing to take a look at anything for the cost of shipping both ways.

@dc42
Ah, I had overlooked the part about negative coordinates being allowed as minima, that is definitely an easier method for defining the print area. Thanks.

@dc42 I am doing it like this, currently:

G90			; abs position
G0 X5 Y5		; rapid to X5 Y5 (just off the sensor disk)
G10 L20 P3 X0 Y0	; set this position as the origin of coordinate system 3 (creating hard printable area)
G56			; set coordinate system 3
M208 X156 Y156		; set new axis limits for print duration

This way, the slicer can still behave as if interacting with a printer whose printable area is from X0 Y0 to X158 Y158 with no special offsets. When the printer is in machine coordinate mode, X0 Y0 ends up right on top of one of the sensor disks. The end/cancel macros put it back to machine coordinates and reset the axis limits, which I measured to be X165 Y180 Z163. Would love any input on making this simpler, but to me it seemed like the best way to avoid special tool/work offsets in the slicer.

I suppose another option would be to default to the "printable" coordinates in config.g and only change to the "true" machine size coordinates in the macro for wiping the nozzle or doing the bed leveling, but to me it feels like six one way, half dozen the other.

I was planning on sharing some of my process and settings as soon as I get most of the kinks out, I will definitely cross-post to the Lulzbot forums. Still tweaking the startup macro to match the original firmware's wipe and probing sequence while making it less Cura-dependent. For instance, Cura would set the wiping and probing temps separate from the printing temps using Cura exclusive variables. My hope is to replace that with the filament macro functionality, so the standby temp is the probing/wiping temp for the loaded material and active temps are for printing.

The original firmware also had some kind of baked in work coordinate offset, as the official printable area is 158x158 but the sensor disks and wiper are well outside of that, so I'm working that into Duet's G53-G59 system. Could just offset in the slicer but when I'm done I'd like the printer to be as slicer-agnostic as possible, since I change slicers more often than I should.

My Aleph Objects Lulzbot Mini V1 (such an unfortunate name) finally got some much needed upgrades. Managed to squeeze a Duet Maestro into the original housing and carefully filed some new cutouts for the ethernet and SD card. Also, got a V1 aerostruder at a slight discount, as they're being discontinued.

Haven't used DWC/Duet since 2018, so I'm still working out some old GCODE habits, and trying to nail down the best pre-print/post-print macro setup, but she prints, and shes quiet at long last. No more serial tether, no more always on fans, it's amazing. I know Aleph Objects printers are already kinda expensive, but adding a duet really completes the professional look and feel of the printer while keeping the open source roots. I just wish they shipped with one.

I have some pretty cheap rails myself, but I'll be honest I've never noticed them becoming affected by run-of-the-mill house dust. What kind of environment is the printer running in? Do the linear bearings have seals? I only ask because I run a cabinetry CNC at work whose linear bearings are constantly buried in all manner of crap and they never seem to get rough.

Same result, unfortunately.

I get this error in DWC every time I run or try to view the mesh bed compensation height map. Running OSX 10.12.6, Chrome V.68, Firmware V 2.02beta1. It happened basically the same on older versions of both DWC and Duet firmware.

Thanks for the quick response, I'll let you know if I run into any trouble.

@wilriker said in Motor Whine/Loud Movement:

https://forum.duet3d.com/topic/5392/does-m906-set-rms-or-peak-current/18

I could definitely use some help generating the proper values to input, I only vaguely know the word bitmask and I'd like to not damage my nice new Duet messing about with it.

Hey, I'm a little sad to find that after powering up and configuring my Delta for the first time, the motors are quite loud, both when moving and when idle.

Specs: Duet 2 Wifi
Latest firmware
Steppers : Nema 17 Bipolar 0.9deg 65.1 oz/in 2A 2.8V 3.0mH 1.4ohm from steppers online
24V meanwell PSU

I've tried settings all the way from 800mA to 1800mA with little change in the sound. I'm using 1/16 interpolated µstepping.

Current config:
; Drives
M569 P0 S0 ; Drive 0 goes forwards
M569 P1 S0 ; Drive 1 goes forwards
M569 P2 S0 ; Drive 2 goes forwards
M569 P3 S0 ; Drive 3 goes forwards
M350 X16 Y16 Z16 E16 I1 ; Configure microstepping with interpolation
M92 X160 Y160 Z160 E663 ; Set steps per mm
M566 X1200 Y1200 Z1200 E1200 ; Set maximum instantaneous speed changes (mm/min)
M203 X18000 Y18000 Z18000 E1200 ; Set maximum speeds (mm/min)
M201 X1000 Y1000 Z1000 E1000 ; Set accelerations (mm/s^2)
M906 X1400 Y1400 Z1400 E800 I30 ; Set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout

Any help would be appreciated. I'd like to know how to mess with the 2660's spreadcycle parameters to see if that helps. Also, potentially the minimum step time is wrong? Idk.

edit: Also, the whine frequency changes each time it's moved in x/y. Reminds me a lot of when I tried to set up TMC2130s on my old printer with a 12v PSU, it did the exact same thing.