To answer your question how (by assuming you have a 4 pins PINDA v2 sensor) to connect the sensor to your board, you have 2 options:
Do not connect the white wire and treat the sensor as you would use a normal endstop switch (blue is ground, brown is +5 V, black is signal),
Connect the 4 wires (use a splitter cable to split out into a 3 and 1 pin ...
So the problem was that the TMC2208 were wired for UART mode, yet Marlin was configured for standalone, which apparently makes them work, but with completely wrong step sizes. Changing it in the configuration completely eliminated the problem
I would check the "steps per distance" setting. If the motors were moving more than the firmware thinks, the height would measure as shorter than actual (since the number of steps would be less than the firmware expected). Similarly, the radius would scale up.
You replaced the controller and motor drivers, so perhaps the micro-stepping is different.
You need to enable the constant Z_SAFE_HOMING (like: #define Z_SAFE_HOMING) in your printer configuration file (if you're using Marlin firmware that is). This will move the nozzle to the middle of the plate prior to lowering the nozzle by default:
#define Z_SAFE_HOMING_X_POINT ((X_BED_SIZE) / 2) // X point for Z homing when ...
There is a temporary solution which I have found here, on the reprap forums, Re: Upload to the board failed after LCD enabled:
An official fix has been posted. Grab the new ultralcd.cpp from [github.com]
Apparently the sources contained a bug which was fixed later, a new version download fixed the problem.
I second the previous answer if running second Z motor in parallel, just split wires or buy adapter consisting of two females to one male, Z motor on most printers don't draw huge current (or at least in smaller less frequent intervals to give things time to cool).
Erm I extruder with two temperature zones, hmmm buy a larger heating element, like a E3D ...
Localized underextrusion usually means you're oozing material somewhere it wasn't supposed to go. Since you have Marlin 2.0, linear advance might help solve that, and in general right retraction amount is important and turning off combing may be needed (combing over infill allows material to ooze).
Also there are reported bugs in Marlin 2.0 such as https://...
If you followed the video verbatim then the pins file will be wrong, because he's changing the pins based on an MKS Gen 1.4 and not the SKR 1.3. All pins on the SKR will look similar to P2_04, which is the pin for the 2nd hotend terminal.
Well I found that I can use a DuPont cable to connect the diag1 pin to the right endstop
There is also a beta functionality in the Marlin firmware I haven't tried: Just uncommenting SPI_ENDSTOPS definition
* SPI_ENDSTOPS *** Beta feature! *** TMC2130 Only ***
* Poll the driver through SPI to determine load when homing.
* Removes the need for a ...
Basically, you are also using a probe, the nozzle is the probe. So this is very similar to an auto levelling setup using a capacitive or inductive sensor, the difference is that your M851 nozzle to probe distance is zero, and may receive a positive value to slightly raise it to get a sheet of paper in between the nozzle and printing surface.
Please note that ...
I've bought an SKR Pro V1.1 which is suffering from the same problem. It has actually to do with a shortcoming or design flaw (of the "HAL" or "Hardware Abstraction Layer" addressing of SPI devices) of Marlin and access to the SD card; I quote:
The problem: On board SD-Card on SKR-PRO 1.1 can't be used.
After the SD card has been inserted, the firmware ...
Use Z Safe Homing to avoid homing with a Z probe outside the bed area
According to Marlin firmware with this feature enabled:
Allow Z homing only after X and Y homing AND stepper drivers still
If stepper drivers time out, it will need X and Y homing again before Z homing.
Move the Z probe (or nozzle) to a defined XY point before Z Homing when ...
Marlin 2.0 is still very much in development.
If you face issues like this and you're certain you haven't introduced any typos,
try downloading the most current version of Marlin again (Github -> Download -> Download zip).
Copy in your configuration files and try to compile.
If the issue persists, you may try to use a version from a few days / weeks ago.
Marlin 2.0.0 is in an Alpha state. 'Alpha' is a state before Beta, meaning, it's not hot off the presses, it isn't even off the presses. You need to go back to the most recent "stable" version of Marlin, which is 1.1.9 (found on the same page as the link above). This should most likely solve the errors and problems you're seeing.