• Recommissioning the Anycubic Linear Plus

    kelvinA08/13/2022 at 17:29 0 comments

    [18:28] 6 hours ago, I was looking at the Tetent Timespy [gd0136] concept I had modelled the day before and desired to print it. I thought about the printers I had available. The CR600S is completely out of commision and the Tevo Flash needs a fan shroud tweak and a new fan, but I couldn't think of anything hardware related that stopped me from using the Linear Plus. 

    Fixing auto bed calibration

    Powered it on and it homed fine, so I started an Auto Bed Calibration and that's when I found out that the issue was firmware related. The printer wasn't moving to the correct next probe position. So, 5 hours ago, I got started.

    Pulling from common

    So my Marlin Github is set up to have "common" as the main branch that has all the common changes I make to all Marlin printers, and then printer specific branches. Since I didn't want any suprises, I pulled changes from common as-is instead of first pulling from marlin/bugfix-2.0.x. About an hour later after accepting changes, I was ready for the first compile.

    Yeah I thought I could get away with this and marlin would automatically apply the value to the other 2 axes.

    Yeah that make sense.

    Oh yeah... that's right. There was some sanitycheck bug I found when compiling for the DP2. Instead of going into that file, adding a "!" and recompiling, let's take our chances and spin a win on a git pull bugfix2.0.x -> common.

    Pulling from bugfix-2.0.x

    So there's a bunch of new things I have to accept in the config files, and so I finish one and then see this:

    Why is there so many things that failed to merge??? I haven't touched any of these files!

    Thus, I "Accept all incomming" for maybe 20 files at a time, since, for some reason, I couldn't do all at once successfully.

    Yeah... this is probably one of those "caught inside a merge" kind of errors. I don't know what they're actually called, but I imagine that a non-compiling codebase was pushed to the branch. I copy out the 4 files I've modified, hard reset the repository, paste the 4 files back in and... same result. 

    Pulling from bugfix-2.1.x

    Wait. There's a 2.1.x!?

    So after like an hour figuring out how to pull from 2.1.x and not 2.0.x, I go through the config and find out what a TPARA is:

    I accept changes in the config files, then do the same copy-out strategy mentioned above. 

    Success?

    FINALLY WE HAVE GREEN

    Man it's so nice to see that logo, signalling a successful firmware flash.

    The changes from the initial LP firmware is 

    • changing the probe margin from 30mm to 45mm to increase the likeliness of the piezo sensors detecting a signal. The closer the probe point is to the edges, the closer it is to the rigid bed mounts and the less the bed vibrates enough to trigger the piezos.
    • Reducing Z_CLEARANCE_BETWEEN_PROBES from 18mm to 10mm to see if a bug has been fixed since the last time I flashed firmware.

    Solving the delta calibration issue

    First time trying the auto calibration and the Z was moving down at a snail pace.

    This is probably why. Changed that to 120mm/s.

    Then the probing looked pretty gittery so I was thinking it was to do with a low DELAY_BEFORE_PROBING of 70ms. It barely succedded with a standard deviation of 0.49 after 3 iterations. Increased it to 200 and then 500ms and the calibration failed and made it more obvious that the bug I mentioned earlier was still around. For some reason, the printer won't move to the correct location if this value is too low.

    I changed DELAY_BEFORE_PROBING to 100ms and increased Z_CLEARANCE_BETWEEN_PROBES back to 18mm/s. I got a successful calibration and after 4 iterations, the screen spat out a s.d. of 0.35. Now it's been entire years since I've last done a delta calibration, but I feel like the typical standard dev is 0.020, but maybe I'm misremembering 0.200.

    My hypothesis was that 18mm was high enough for a full auto calibration, but not high enough for the linear plus to move to the...

    Read more »

  • [A] DP2 Repair -> Printer Repair

    kelvinA08/13/2022 at 16:31 0 comments

    I'm going to start putting all my printer repair logs into this project, so it has been renamed.

  • Trying the GC6609 Stepper Drivers

    kelvinA03/22/2022 at 13:20 5 comments

    For gd0036, I wanted to see if I can use these drivers (on the S6609 stepstick) instead of (drastically) more expensive (and out of stock) TMC5160s at 36V. 

    [13:15] So far, it doesn't seem like I can just set the axis to TMC2209 in Marlin and get a UART connection.
    so it's not as simple as this video made it appear.

    [14:43] I've just discovered that the logo on the board is FysetC's. I knew I recognised that logo somewhere. I've also discovered the datasheet, but I don't have an account so I can't see the other 8 pages.

    [15:03] Tried getting some component values, seeing if I could find some kind of rsense. 

    It's not much but it's honest work. Most resistors read as 0ohms. The 1K resistor is for TX and RX.

    [15:07] Oh yeah I forgot I don't have to do that at all because there's an image of the board schematic.
    Turns out 0 ohm resistors actually exist. Seems that the 2 large resistors are the sense resistors, coming in at only 0.11 ohms, so it makes sense why I couldn't read those.

    [16:43] Huuuuh. I was scrolling through this fysetc page on the TMC2209 and I found a schematic that looks awfully similar.

    I'm going to continue my testing with the driver set to 2209 in Marlin and see if this gives me any leads.

    Wednesday 23 March

    [05:54] Fysetc calling their latest TMC2209 driver the S2209, as well as similar text layout, adds more evidence that the S6609 is a 2209 clone from FysetC. Judging by the schematics, it also looks like Index and Vref were intended to be swapped on the S6609 v1.0 PCB to match the S2209 v3.1, but there was an error when setting the header pin numbers.

    It's likely possible to correct the mistake with an extra long 2 pin header which is only soldered to the DIAG pin (from bottom side) and shrinkwrap over the vref pin, and then some wire or solder bridge from Index. This also menas that a shorter heatsink will be needed if the stepsticks are mounted like in the SKR instead of like the SKR Octopus. 

    Also, without UART, both chips can only be set to a maximum of 1.77A R.M.S..

    [06:46] I just realised something:

    That's the 2 relatively large Voltage(motor) capacitors. This seems like a situation where the chip can do one voltage (which is the one advertised), but the stepstick can only work to at a different, lower voltage. Nothing short of penny pinching here. Micropennies actually. Further research uncovers that the general consensus is to use capacitors up to 70% of rated voltage, which means I'd need at least 51.43V capacitors and these current capacitors are really only for 24.5V usage. This knowledge is interesting though, as the SKR Octopus Pro uses 63V capacitors, which should equate to a 44.1V recommended max input voltage. 

    50V caps for these S6609s and 48V max for the Octopus Pro is probably still a good amount of tolerance.

    [08:29] Looks like the S2226 has an even more identical pinout, suggesting that the "judging by the schematic" stuff I said at 05:54 is irrelevant.

    [18:04] I've just discovered that MLCC capacitors (the brown ones on the stepstick) don't require derating as they have "higher voltage strength".

    Phew. I was worried all day about having to desolder and resolder like 32+ stepsticks; an entire reflow station is still probably cheaper than a couple of HV 5160 stepsticks (that have just shown up on virtual shelves). Speaking of those stepsticks, it seems that the DIAG pin is the only one needed for sensorless homing.

    Thus perhaps the elaborate solder job I mentioned earlier wouldn't be needed at all. I'm not planning on using sensorless homing currently, but it's useful information for the future.

    Thursday 24th March 

    [10:05] UART woes aside, I thought I'd see what these drivers even sound like. Can confirm they are TMC2208 grade. I feel the 6609 is like 1dB quieter on the Y axis when I did the test, but the 2208 seems to take the win when playing...

    Read more »