FT5 R2 EEprom Enabled Firmware

[JohnS]

Hi there,

I'm fairly new to the 3D printer game and am having a bit of trouble with the firmware for the FT5 R2 with a SKR Board. After a few good prints with the original setup I changed my extruder after I wasn't satisfied with the original. Then I found out that I need to adjust my steps/mm as it's severely under extruding now. My problem is that the EEPROM on the original firmware downloaded from the Folgertech shared folder has the EEPROM disabled, therefore it can't be changed on the display, the Repetier host software, or using G codes to save changes.

Folgertech has instructions for compiling a new firmware, but the link to the Marlin-bugfix-2.0-biqu in the instructions leads to a path that no longer exists so I've been compiling marlin firmware from various sites for the SKR board and have had little success. The closest was this one:
https://github.com/MarlinFirmware/Marlin/tree/bugfix-2.0.x
which matched the instructions, but once compiled and set on the board the motors don't operate.

Does anyone know of a good firmware I can use or compile that has the EEPROM disabled?

[Tin_Falcon]

IMHO there is no good reason to have eprom chitchat turned off on a home machine , a Makerspace machine with multiple users maybe not as much. so turn the eprom chitchat on.

second of all at this point bugfix 2.0 is a bit outdated,
The latest version of marlin is 2.0.6 found here
https://github.com/MarlinFirmware/Marlin/releases

in my experience FT firmware has not been the latest and greatest at best it needs some tweaking.

There are many good video's on u tube about marlin 2.0 the software to load it and the Varus popular board . You may need to set parameters for the FT5 r2
Hope this helps.

[carefudundae]

I'd also suggest rebuilding your own firmware from the base Marlin, I personally learned a lot and found tons of features in there that may not be enabled by default.

To get you up and going quickly though, just put a command in your startup gcode to change your steps/mm.
Depending on what you have, it'll be something like

M92 E420

or whatever your steps/mm number is (420 is what I use for a 16 microstepping bmg extruder).

[Ron]

Hi John,

Welcome!

FWIW-
I am running 832 steps/mm with my DotBit extruder, however I am running it in 1/32 micro-stepping mode on an MKS SBASE board with Smoothieware.
If you are running in 1/16 microstep mode (most likely), try 416 steps/mm.
This is very, very close to the value @carefudundae is running so you should definitely be in the ball park.
I do like his method of setting it in the pre-print gcode text as a way to get it printing quickly.
There should be no harm in doing that permanently if need be, plus it allows you to very easily tweak it for different filaments in your slicer.
Such as- M92 E416
I would put that statement just after any homing commands personally, and certainly after any command that reloads parameters from the EEPROM (if enabled).
But I also agree with him and with @Tin_Falcon that the EEPROM function should be enabled.

On the Smoothieware setup I am running it is a simple matter of editing a text file on the board's memory and rebooting.

The other problem you mentioned- After compiling the bugfix version the motors won't run, sounds to me like a board selection or I/O pin definition problem.
Unfortunately I do not have an SKR board to try anything out on, so hopefully someone who is running one can help in greater detail.

[JohnS]

Thanks for the advice everyone,

I've compiled the new 2.0.6 marlin firmware and enabled the EEPROM by uncommenting lines:
define EEPROM_SETTINGS
define DISABLE_M503
Then, after looking at the boards.h file I realized I had my SKR board configured as SKR V.1 when it's actually a V.3, so that got the motors responding to manual commands. Thanks for that @Ron. All seem to work except the home functionality. If I home any of the axis it lifts the Z up about 100 steps at maximum speed while ignoring the home flags.

In addition to that my printer display turns on, but no longer reads anything and instead just shows blank squares in place of where numbers or text could be. Any general idea what could cause this?

I figure there's a few things that need to be edited in the firmware, but as someone just learning what all these files actually do it's going slowly. @carefudundae, I like your idea of making my own firmware from the base marlin, but I wouldn't know how to start at this phase of my firmware experience. I figure if I can get one set of firmware working and modifiable I can learn my way up from there.

[JohnS]

I spoke too soon! I figured out the display problem. Looks like there wasn't a display defined on this firmware, so I uncommented:
define REPRAP_DISCOUNT_SMART_CONTROLLER
Now the display is working. Which is great, but i'm still having the homing problem.

[carefudundae]

Try homing just x or just y first... G28 X or G28 Y.

Also, before switching to corexy, I had my ft5 working on a very similar setup to you. Used an SKR 1.3 with TMC 2208 drivers, dotbit bmg-style extruder, and a bltouch, so there may be some differences. But you can take a look at the github location below if you want. Mostly you just want to look at the configuration and configuration_adv files.

https://github.com/CareFudundae/FT5_firmware/tree/master/Marlin-bugfix-2.0.x%20FT5%2020200327/Marlin

[Tin_Falcon]

I like your idea of making my own firmware from the base marlin, but I wouldn't know how to start at this phase of my firmware experience. I figure if I can get one set of firmware working and modifiable I can learn my way up from there.

A little secret, you are doing it one step at a time and seem to be making good progress.
sound like you need to tweak your homing motor routine.

[JohnS]

Ok, so thanks again for the help everyone. i've been messing with this on and off a few days and while i have a much better understanding of the firmware and compiling it, i'm still at a loss on the homing problem. There are two things that are wrong, first is the endstop signal. Z is inverted, showing triggered (via M119) when not pressed and Open when pressed.

Whether i switch the logic for Z to true or false it never changes, however and Y and X change as would be expected. That said, my original firmware still loads and doesn't have the inverting issue, so i know it's not hardware related.
// Mechanical endstop with COM to ground and NC to Signal uses "false" here (most common setup).
define X_MIN_ENDSTOP_INVERTING true // Set to true to invert the logic of the endstop.
define Y_MIN_ENDSTOP_INVERTING true // Set to true to invert the logic of the endstop.
define Z_MIN_ENDSTOP_INVERTING true // Set to true to invert the logic of the endstop.
define X_MAX_ENDSTOP_INVERTING true // Set to true to invert the logic of the endstop.
define Y_MAX_ENDSTOP_INVERTING true // Set to true to invert the logic of the endstop.
define Z_MAX_ENDSTOP_INVERTING true // Set to true to invert the logic of the endstop.
define Z_MIN_PROBE_ENDSTOP_INVERTING true // Set to true to invert the logic of the probe.

Are there any other locations to invert the logic of the endstop besides configuration.h?

And my second still remaining problem is that if i home X or Y, Z moves up about 100 steps (ignoring the home flag), then they home properly.
And if Z is homed it just moves indefinitely until it hits something, even if i toggle the still inverted home flag. Any clue on what could cause that?

This is a text file of my Configuration.h
Configuration.h.txt (85.6 KB)

[Tin_Falcon]

If that is the case check the wiring sounds like a connection pin is not connected on the z end stop

check hardware issues before trying to adjust firmware.

[carefudundae]

1st problem: What type of switch is used on z homing? is it a standalone microswitch, a switch on a pcb (with other things), or are you using a bltouch or other extruder mounted homing?
The following assumes its a standalone microswitch
I've had issues before with switch debouncing. Essentially what that means is that low quality switches can give the appearance of switching on even though for the most part they are certainly off. I'm not an electronics expert by any means, and don't entirely understand it, but that is why they suggest wiring regular microswitches for NC to signal, then invert logic to "false". I had this issue with my MPCNC where whenever I would home the z would move up a bit, then x would home fine, then y wouldn't move towards home... instead it would just move back a bit. There are some firmware settings to help with debouncing, but I'd suggest using a non-microswitch (e.g. a switch integrated onto a pcb) or making the logic NC to signal instead of NO to signal... then inverting logic.
You could also try uncommenting and adjusting the parameter below (in Marlin 2.0) to account for this... I did that and it helped, but not all the time.

#define ENDSTOP_NOISE_THRESHOLD 2

2nd problem: z moving up when homing is a feature of "homing_height" i believe.
try changing the parameter below (default value shown) to 0...

#define Z_HOMING_HEIGHT  10

I honestly think this problem won't be an issue anymore after you fix problem 1

best of luck! I look forward to hearing about your eventual fix!

[JohnS]

@Tin_Falcon that was my first thought, but when i switched back to the firmware the printer comes with the z end stop works as it should. That led me to believe it's something in the firmware i'm using that's changing the logic.

@carefudundae, i'm using a prusia endstop connected from the SKR board to the switch. I'm new to the switch options, but i take it that's a standalone microswitch.

As for my homing problem, we're definitely a step forward, the Z homing height is what's causing the Z to move upwards every time i homed X or Y. In fact, after changing that I can home Z by triggering the endstop, then releasing it to "simulate" it homing correctly. Which would mean my only problem is figuring out this swapped endstop logic.

But there's more suspicious activity now. When i home Z, X and Y move to a seemingly random position in the middle of the printer before Z moves (it looks to be about [110,210]), sort of like the problem i had with Z, now on X and Y. Originally it was hitting the edge of the printer.

[JohnS]

Thanks to everyone who helped! I finally got it working!

[carefudundae]

That's great to hear, what was the fix?

[Ron]

Apparently he had a bad version of Marlin (2.6) and once he changed it to 2.6.1 and made the necessary tweaks everything worked.