Ok, I played around with this stuff and made some preliminary configs for the new build system.
The main difference from the config in this thread is that instead of setting Y2_USE_ENDSTOP and Z2_USE_ENDSTOP these settings are removed. This will allow Marlinâs pins.h to do the right thing and automatically use the DIAG pins configuration it already has for the board.
I would appreciate if @KCGreg you could download one of the zips from my repository and see if it buillds & works for you. Below is a link to the latest build as of 07/22.
Oh, I almost forgot. I designed a plastic shell that can be snapped around couplers to provide protection from over-extending. There is 1mm space between the walls and the coupler in the horizontal direction. This allows the coupler to still flex when encased although it will probably not reach the full 2 degrees these should be originally designed for.
These work great for homing in Z_MIN direction. The nice thing about homing down with these is that there is no calibration or careful installation required. The hard stop is a direct contact between XZ and YZ plastic parts which is as true as it can get. The downside is that homing down is somewhat less convenient: One has to make sure there is enough space for the gantry to go all the way down which may not be the case if a full-sized sheet is on the machine.
Thanks! The manual changes I made in the original post were due to the fact that at the time of that post, the pins.h file was not mapping correctly. In the config files that I later posted (on a newer Marlin build), this was corrected. Several of the bugs I had originally entered on the Marlin Github had been corrected as part of the newer firmware. I canât say enough about how responsive the developers are that are handling the Marlin upgrades.
I can now put the full Primo sets up there. I ran into file size issues previously. From what I remember it will even show you a difference stl preview. As in you can see exactly what has changed!!! Pretty sure Barry pointed that out a long while back. I am going to have to edit a file just to see it. Maybe I will drop a logo on that one and see what happens.
Has anyone attempted sensorless on the SKR 1.2 PRO that Ryan sells? I know this topic covers SKR 1.3 and I have seen others online successfully doing it with the SKR 1.3 for their printers on youtube but I am not sure if the PRO 1.2 will also work - in theory it should?
It should. You just have to roll up your sleeves and configure it. The drivers are the same, and the processor and stuff shouldnât be different enough to matter.
Iâve found this very helpful. My goal is to do what KCGreg has done with senseless homing. I have an SKR 2 instead of the 1.3, does that change anything in the firmware? I currently have dual y and dual z motors connected in serial mode. Do I need to run them individually and use my E0 and E1drivers? Looking forward to implementing this along with the TFT touch screen.
just a question about sensorless homing, i use your firmware and z axis sensorless homing not working. i have same skr 1.3 and tmc2209, z axis alway home issues, do you know how to fix it?
For sensorless homing, the motors need to skip. They will destroy the couplers before they skip. Regular endstops can be used with Z and a screw for adjustment. Sensorless homing isnât a good idea here.
Not really, with bump homing disabled on Z (a must for sensorless mode) and sensitivity set right, the motor will not lose a step. If it does then the accuracy of homing is greatly diminished.
The challenge of-course is that every motor is different so you will skip some steps while tuning the values
Destroying the couplers is only ever an issue when homing to Z- or DOWN. Homing up will not stretch the couplers but requires extra hardware to block the movement. With default setup there is really nothing that would stop the lead screw threading itself out of the nut or worse.
I donât have a good solution here. On one hand homing in Z- direction with âcoupler saversâ is great because both sides are guaranteed to end up at the same height from the wheels by the virtue of mechanical design. However the savers may also break and itâs really annyoing if you lose position and then have to re-home when you have a bit mounted and some thick material attached to the bed.
Iâd probably opt for hard stops clamped around Z pipes and homing towards Z+ as a recommendation. Now if only one could find a good way to calibrate / set these stops so both sides end up being equal
As per KCGregâs notes, set the following to sensitivity of 20:
#define X_STALL_SENSITIVITY 20 // Stall sensitivity must be > 0
#define Y_STALL_SENSITIVITY 20 // Stall sensitivity must be > 0
#define Z_STALL_SENSITIVITY 20 // Stall sensitivity must be > 0
As of todayâs date, when I downloaded the Bugfix edition of Marlin, the following was commented out, but to me it makes sense to uncomment it.
Hey, Iâve used your notes to configure sensorless homing, and I got a successful build, based on editing the V1 firmware for dual endstops. I changed that file according to your notes. However, while homing works, it only homes to one of the two Z steppers and only homes to one of the two Y steppers. So, when I try to test it fixing being out of square, it fails that test. Any idea what I may be missing?
UPDATE: SUCCESS. After a lot of work tweaking config files and compiling firmware, I finally got Sensorless Dual Homing working for both Y and Z on my LowRider v2 with SKR Pro 1.2 and TMC2209 drivers!
I feel like I became a junior expert on this. LOL.