Tinker firmware - introduction

[Smithy 1,144]

On 8/7/2020 at 8:20 AM, Rene88 said:

Is it still good to use Tinker Firmware with my Ultimaker 2+ extended? or beter use stock firmware?

Yes, I like it much. The firmware is basically an extended version of the stock firmware, it is based on it.

[Smithy 1,144]

9 hours ago, joatrash said:

Is anyone having troubles with this firmware and Cura 4.7?

No, but I rarely print longer print jobs on my UM2+Ext. 

I will give it a try in the next days, with a longer print job.

[joatrash 1]

Ok... I've spent a couple days experimenting now and there's something going on with Tinker on a specific 3d model I am trying to print. If I go back to the original (latest) UM2+ firmware it prints fine. I now tried slicing with cura 2.5, 4.1 and 4.7 and the results are similar- the print just stops after a while as if it were finished. The same model, sliced waaaaaaay back with an early cura (2.1 I think) still prints.

The weird thing is that I went back and redid the model with different topology, made it 100% error free, manifold and watertight but the result is the same. If IS a rather detailed model though, at around 50MB. Unfortunately, I can't share this particular model, since it's a confidential file, but I'll try a different model (that I CAN share) and see if I get errors on that too.

[joatrash 1]

OK... more testing. Look at this:






 

 

I imported the gcode files into Simplify3d just to look at them. It looks like Cura has inserted random super-fast print head movements because the red lines are exactly where the print failed. UMs original firmware seems to be able to handle the files anyway, but Tinker stops printing when it reaches those lines every time.

Any thoughts as to what could be going on?

[tinkergnome 927]

3 hours ago, joatrash said:

Any thoughts as to what could be going on?

 

Dunno, can you translate "random super-fast print head movements" into a more precise measuring unit?🙂

Or can you share the gcode file?

 

[joatrash 1]

1 hour ago, tinkergnome said:

 

Dunno, can you translate "random super-fast print head movements" into a more precise measuring unit?🙂

Or can you share the gcode file?

 

Haha, well looking at the screenshot... the red line seems to indicate a moment of 9000mm per  minute!

But I did more digging. It looks like the problem might be hardware-related on my end. I suspect a faulty SD-card reader. (Or if it's not, then Windows is indexing the SD card even though it's not supposed to be.) Looks like errors start showing up in files when the SD card is removed. Information in the files goes missing, like here:

Broken copy on the left, error-free copy on the right.

Apologies for thinking it was a Tinker issue.

ONE puzzling thing though... the UM firmware seems to IGNORE the error and carry on, but Tinker stops. is there an extra-sensitive error-check in there?

[rayholland 6]

The headbed of my UM2+ does not cool down anymore (temp keeps rising).

I think the mosfet for heater3 is broken and i'm not really in the mood of buying a new mainboard 😉

 

The mainboard has 3 heater terminals:

heater1 (occopied), heater2 (free) and heater3 (this is the heater for the headbed).

I also see that there are 3 seperate mosfets for all these 'heaters'.

 

So, i'm thinking, using the Tinker firmware, is it possible to use the 'heater2' terminal (not occopied) on the mainboard for the original headbed?

 

@tinkergnome Is there maybe a setting/option in the Tinker firmware to set heater2 as primary heatbed?

 

BR,

Ray

Edited October 16, 2020 by rayholland

[tinkergnome 927]

2 hours ago, rayholland said:

So, i'm thinking, using the Tinker firmware, is it possible to use the 'heater2' terminal (not occopied) on the mainboard for the original headbed?

 

The buildplate heater draws a lot more current than a hotend. Dunno, but you should be absolute sure that the capability of the outputs is really the same before you change anything.

 

There are probably only minor things to change on the software side, but you have to compile a custom firmware in this case.

 

[rayholland 6]

Would changing the line '#define HEATER_BED_PIN      4'  to '#define HEATER_BED_PIN      3' in the pins.h be sufficient?

[tinkergnome 927]

10 hours ago, rayholland said:

Would changing the line '#define HEATER_BED_PIN      4'  to '#define HEATER_BED_PIN      3' in the pins.h be sufficient?

 

Probably yes. I would swap the pin numbers between HEATER_1_PIN and HEATER_BED_PIN

Take sure that you are in the correct section (MOTHERBOARD == 72) and it should work.

 

[npbazan 0]

On 10/16/2020 at 3:25 PM, rayholland said:

The headbed of my UM2+ does not cool down anymore (temp keeps rising).

I think the mosfet for heater3 is broken and i'm not really in the mood of buying a new mainboard 😉

 

The mainboard has 3 heater terminals:

heater1 (occopied), heater2 (free) and heater3 (this is the heater for the headbed).

I also see that there are 3 seperate mosfets for all these 'heaters'.

 

So, i'm thinking, using the Tinker firmware, is it possible to use the 'heater2' terminal (not occopied) on the mainboard for the original headbed?

 

@tinkergnome Is there maybe a setting/option in the Tinker firmware to set heater2 as primary heatbed?

 

BR,

Ray

I have same Issu but the heater dont work, so never start printing

 

Did you change the pin? because we can swtich to heater 2, but I dont know if the current would be supported because the mainboard has a finder relay 361190054011 that i dont know what is for...

 

So if you could do it, please tell us, I will do it too and tells you

 

Thanks!

[JRDM 5]

How do you change the abort retraction? I've changed my hot end and it retracts way too much for the new hot end.

Edited November 27, 2020 by JRDM

[my3DBr 4]

Hello guys. Are you using the latest stable version V17.10.1 or the newest one V19.03.1? Once in a while my UM2 inverts all axis by itself and I have to factory reset it. Does it happens to anyone?

[schafe 3]

My UM2 is one of the very first.  I am using 17.10.1.  The only issue I have is sometimes at the end of the print it will retract almost all the way back to the extruder motor.  No other problems.

[JRDM 5]

On 4/16/2021 at 1:29 AM, schafe said:

My UM2 is one of the very first.  I am using 17.10.1.  The only issue I have is sometimes at the end of the print it will retract almost all the way back to the extruder motor.  No other problems.

 

I've seen that too, on later firmwares. I think the extruder position reset g code doesn't get accepted, I haven't figured out when or why this happens. I just turned off the retract command in my ending g code. I'd rather a tiny bit of ooze over having to refeed the filament.

Edited April 19, 2021 by JRDM

[bhjram 0]

Hello,

First, Im not entirely sure if this is where i can raise concerns. Sorry if this is the wrong place. 

I just installed UM2+ Tinkergnome version 17.10.1. I decided to change firmware for the purpose of recovering a failed print. I measured the Z axis using the adjust z position and when i tried the recover print option, it was reading the file for a very long time. I was patient until it reached my set z height. But then its showing Z193.96/ 36.00 (I set 36.00 as Z axis) and seems stuck there. I thought it might be a build issue and tried v 19.03.1 as its the latest option. Same issue persisted.

 

One thing though, when i looked at the gcode file, i found that MAXZ is set to 34.39. So, is that the issue? So what should i give in recover print?

Kindly help me out. 

Edited September 10, 2021 by bhjram

[gr5 2,167]

First of all - keep your bed hot - if you let it cool to room temp the part may easily pop off the bed.  So keep the bed at 60C (or whatever was your printing temp) as soon as possible!

 

Going to 19.03.1 is a good thing as there is a pretty serious bug in older version if you are using the power budget feature (which you probably aren't).

 

Could you post the gcode file?  Search through your gcode file for "Z".  The letter Z should only appear a few times in the begining and maybe once per layer.  Unless you have zhop enabled in cura which will probably ruin the "recover failed print" feature.  Look at all the Z values.  Do they go up to 36.00?  Do they go beyond?

 

Maybe you should post the gcode file here.

[bhjram 0]

15 hours ago, gr5 said:

First of all - keep your bed hot - if you let it cool to room temp the part may easily pop off the bed.  So keep the bed at 60C (or whatever was your printing temp) as soon as possible!

 

Going to 19.03.1 is a good thing as there is a pretty serious bug in older version if you are using the power budget feature (which you probably aren't).

 

Could you post the gcode file?  Search through your gcode file for "Z".  The letter Z should only appear a few times in the begining and maybe once per layer.  Unless you have zhop enabled in cura which will probably ruin the "recover failed print" feature.  Look at all the Z values.  Do they go up to 36.00?  Do they go beyond?

 

Maybe you should post the gcode file here.

Thanks for the quick reply. I have attached the gcode. I found that there is no Z36. It stops at Z34.39. 

So, using the adjust z position, I measured the base plate level and it was around 18.57. So I figured the value to start my print would be 36 - 18.57 = 17.43. When I gave this Z in the recover print, it started to print but way above my failed print.  So Im back to square one. 

 

Actually in regards to the power budget feature and 19.03.1, my reason for failed print is because my powerblock is too old and needs replacement. So what it does is after a few hours of print, it stops midprint and restarts. I know I should probably get a new brick. But in the mean time can this budget feature help? (provided I upgrade to 19.03.1).

 

Thanks

 

 

UM2_ARM_v5.gcode

[tinkergnome 927]

18 hours ago, bhjram said:

I measured the Z axis using the adjust z position

 

What? Why?

If you don't have a caliper at hand - the "Move axis" menu can be "abused" to figure out the height of the part ("Home" the z-axis first of course). I think it can be found under "Expert functions" or such.

 

"Adjust Z Position" is a completely different task. It adjusts the offset between the nozzle and the buildplate. And... that's something that has to be avoided at any cost if you want to continue an aborted print...

 

The number that is shown in this "adjust-z" menu is the offset between Z_MAX_POS (a fix value of 230.0mm for UM2) and the current Z-position. So.... it's technically possible to calculate the height of the printed part if you compare two offsets, but never confirm any new offset in this menu for the purpose of measuring. It has an abort option if i remember right?

 

But once again: a caliper or - at a pinch - the "Move axis" function is a much more natural and suitable way for a quick measuring. Because the shown coordinates can be used as is.

 

Hope that helps!

 

[bhjram 0]

41 minutes ago, tinkergnome said:

 

What? Why?

If you don't have a caliper at hand - the "Move axis" menu can be "abused" to figure out the height of the part ("Home" the z-axis first of course). I think it can be found under "Expert functions" or such.

 

"Adjust Z Position" is a completely different task. It adjusts the offset between the nozzle and the buildplate. And... that's something that has to be avoided at any cost if you want to continue an aborted print...

 

The number that is shown in this "adjust-z" menu is the offset between Z_MAX_POS (a fix value of 230.0mm for UM2) and the current Z-position. So.... it's technically possible to calculate the height of the printed part if you compare two offsets, but never confirm any new offset in this menu for the purpose of measuring. It has an abort option if i remember right?

 

But once again: a caliper or - at a pinch - the "Move axis" function is a much more natural and suitable way for a quick measuring. Because the shown coordinates can be used as is.

 

Hope that helps!

 

Thank you so much. I got confused and thought adjust z position as the move option. My bad. 

 

All sorted now. Well except for the power surge issue. Will try power budget. 

Thanks for developing the firmware.

[gr5 2,167]

So Ultimaker claims that USB printing on the UM2 is unreliable and to be avoided.  In the future, why not use the SD card instead?  Then if your computer crashes it won't matter.

 

 

[Naudnaud 0]

Hello
I have my UM2+ with bondtech QR feeder since 2017.
 

Now, i upgrad it with tinkergnome firmware.
But i have a lot off probleme with Z level now.
Impossible to have a perfect first layer.

Can you explain how work Z adjust with Tinker ? 

Need to adjust with stock bed leveling only ? 
or need to adjust with stock leveling and Z adjust position ? 

thank's :D


 

[tinkergnome 927]

9 hours ago, Naudnaud said:

Need to adjust with stock bed leveling only ? 
or need to adjust with stock leveling and Z adjust position ?

 

The normal leveling procedure works as usual and is still sufficient as before.

"Z adjust" changes only the distance between nozzle and buildplate (not the leveling) and is only there for lazy people like me to fine tune the distance without the need for a whole leveling sequence. 🙂

 

From your picture i would say the distance is a little bit on the high side, i would try to reduce the z-distance a bit.

(assuming the feed rate - or steps/mm - is proper configured for the QR feeder)

 

[Naudnaud 0]

Ok, 
if i do a new stock calibration, the Z adjust will reset ? 

[tinkergnome 927]

9 hours ago, Naudnaud said:

Ok, 
if i do a new stock calibration, the Z adjust will reset ? 

 

yes, that's correct