More information during print

[Blizz 53]

If it's technically possible that would be cool!

I am still hoping that Cura will start adding meta comments for the progress as well.

That way the firmware can start showing more accurate times while printing instead of how much % of the file was processed already... I've had it occur more than once that it says 1 minute left and it still has 10 minutes work and vice versa

 

[tinkergnome 927]

...

I've not looked into it but i think that other info is available in UltiGcode (it's possible to copy a profile from gcode).

Do you think it's possible to display more info?

...

 

Let's see...

The informations for (estimated) printing time and material length are read from the comments at the top of the gcode file (only for UltiGCode-flavor AFAIK).

Displaying the time in another format (incl. minutes) should be easy.

The Cura profile is a different challenge...

It is embedded at the end of the gcode in an encoded format. Due to the very limited RAM available at the Arduino board - decoding and parsing of the Cura profile would be... ... ... not so easy...

Perhaps a better approach:

Someone... could write a Cura plugin that includes the major profile informations as comments at the top of the file.

The same might work for progress informations. Basically the end-position of the E-axis is needed. I guess, the firmware could calculate the progress and the estimated printing time more accurate just by comparing the current E-axis position to the last position...

Mmmhhh - or a more general approach...

how long would it take to parse the whole file at the beginning (without printing) and track the max. positions...? I think this is worth a test...

 

[ultiarjan 1,223]

I really like the human readable comments in the Simplify3D gcode ... all settings are in there.

I wonder what info is readable from CURA, if you set your machine to RepRap/Marlin you get to set the start and end code in CURA , This is easy to use for UM2 as wel. Just make some changes to the start code (include priming etc)

http://umforum.ultimaker.com/index.php?/topic/10075-ulti-evening-march-23rd/?p=103183

If I look in this start code I see stuff like

;Print time: {print_time}, I wonder if there are more parameters not currently used available ....

 

Anyhow, maybe not worth it to spend to much time on this as "pink unicorn" will probably make it useless again ...

 

[NBroenner 7]

Hi,

I have upgraded from the stock firmware to this firmware mod. Until now I did not noticed any bugs. I like the detailed information, a huge imporvement to the old "estimation" - 1 hour left .... I think you know what I mean.

I got a little scared, when I checked my print and suddenly the lights and the display went off. At first I though it would be a power failure - but why is then the printer still printing. Today I took a closer look into the additinal settings and there was it: the sleep mode . Very nice and sometimes shocking .

Regards,

Nils

[ultiarjan 1,223]

@tinkergnome

totally forgot to ask but a few weeks ago I tried to compile your firmware with 2 extruder activated and got a error during compilation. Of course I forgot the error but do you have any idea if there's anything blocking dual extruder in your firmware? Basically I'm asking for a dual extrusion version as I'm now back to default and therefore constantly in tune mode.... I can test again but maybe you have a quick direction pointer?

[rigs 735]

 

@tinkergnome is discrete since the new forum ...

Edited June 4, 2015 by Guest

[ultiarjan 1,223]

That's a serious loss... let's hope @tinkergnome will return ....

[rigs 735]

That's a serious loss... let's hope @tinkergnome will return ....

 

I hope arjan

[NBroenner 7]

Can someone explain me what is the difference between the normal and the big bang version of this firmware ?

[tinkergnome 927]

Phew! I am back!  

Thanks to Arjan who has redirected me to Sander...

Thanks to Sander who has passed my issues with the forum account to the developers...

...and thanks to the nameless developer who was able to reset my password manually...  

 

Can someone explain me what is the difference between the normal and the big bang version of this firmware ?

 

I somehow like the term "big bang"...

Seriously:

The custom firmware is compiled with PID control for the printbed temperature.

Because of this reported issue i released the "b" version with the standard "bang-bang" control method (in addition).

The difference is described in the links.

If i find some spare time it will become a selectable option someday... (it's on the todo list)

Greetings from the tinkercave!

Edited June 17, 2015 by Guest

[ultiarjan 1,223]

 

@tinkergnome good to see you back here !

[swordriff 119]

OMG @tinkergnome

Thank you for being back!!

[rigs 735]

@tinkergnome OUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU !

Welcome, it's a good day !

[DidierKlein 729]

@tinkergnome I just asked @rigs about news from you since he talked with you on twitter and now you're here!

Great to see you back!

I have had something weird with your firmware not sure why, the version is 15.02 i think. When i do a print everything is fine, when i do another print without switching off, it seems that the icons are lost somehow

I'll have to try that with the latest version, did you do the 15.04 version yet?

[tinkergnome 927]

[...]

Great to see you back!

I have had something weird with your firmware not sure why, the version is 15.02 i think. When i do a print everything is fine, when i do another print without switching off, it seems that the icons are lost somehow

I'll have to try that with the latest version, did you do the 15.04 version yet?

 

First: i never went away - it was just not so easy to (re)activate my forum account and i considered the matter not soooo urgent...

Regarding the firmware:

I noticed some weird things with this version too (at least sometimes...). I guess it was some kind of stack overflow (or something similar).

I removed the support for the (custom) gcode commands M605 and M606 since version 15.03. These stuff allocated a huge amount of the rare RAM and i never saw that anyone used it.

It seems that those issues went away with the recent version, you should give it a try.

i know ...someday i should ask @dim3nsioneer about the intention of these commands...

Obviously there will be no "tinker" version 15.04 - the last changes of the default firmware were only "cosmetic" AFAIK (basically the displayed support address for fatal errors has changed and the material preset "UPET" was renamed to "CPE"). I believe - we don't need to rush it...,

but the story continues

I'm trying to implement a "recover an aborted print from a selectable height" - function (*) at the moment. This will be release 15.06 (or probably 15.07...)

(*) = working title

[DidierKlein 729]

I beleive that version 15.04 also has the feature to turn on the rear fan on the latest UM2 when the temp reaches 40°c (on my extended it does that with standard firmware 15.04) that's basically why i'm asking

Anyway glad that your user account issues were solved, hopefully the others will be able to rejoin the community soon too.

[tinkergnome 927]

I beleive that version 15.04 also has the feature to turn on the rear fan on the latest UM2 when the temp reaches 40°c (on my extended it does that with standard firmware 15.04) that's basically why i'm asking

[...]

 

I see...

I heard that rumor too, but there are no commits on GitHub related to this (as far as i can see...). Perhaps it's completely handled by the hardware, or it's a secret firmware change that is not published (yet).

I have no clue...

[DidierKlein 729]

Maybe it's only hardware i don't know but it seems to me that the firmware has something to do with it. But my extended came in with a non released firmware so it might be somewhere there

Thanks for the feedback anyway

[NBroenner 7]

 

@tinkergnome: I am interested in your upcoming feature "recover an aborted print from a selectable height". Will it be possible to use this feature to continue prints, which ran out of filament. For example you have 1/3 of a filament roll and you want to print something that needs 300 gramm. You let it print all night and in the early morning it runs out of filament. Then it would be nice to continue at the height were the filament run out. Would it be possible to attach a switch to the mainboard to "remember" where the filament ran out ?

[tinkergnome 927]

Will it be possible to use this feature to continue prints, which ran out of filament.

 

The problem in this scenario is usually the heated printbed. As long as it stays hot and the printed object doesn't come loose it is often possible to recover the print.One can simply measure the current height and restart from there... The latter is the solution that i'm trying to achieve with this new firmware function.

But once the object no longer sticks to the build platform the print is ruined anyway...

 

Would it be possible to attach a switch to the mainboard to "remember" where the filament ran out ?

 

I'm just a software guy and have nearly no clue about electronics, but it seems that some enthusiasts are working on filament sensors. I cannot find the example that i have in mind, but there are others here and here (for example).

These solutions are perhaps a bit exaggerated for this purpose, but it looks promising.

[NBroenner 7]

 

@tinkergnome: I checked the Mainboard of the UM2, there is one connector left, named Analog. Maybe this can be equipped with a switch (like the minature swichtes of the end positioning) somewhere near the noozle (like a pull-up or pull-down, depending on the layout). Can you read the values in the firmware from the Analog connector ?

[tinkergnome 927]

Can you read the values in the firmware from the Analog connector ?

 

Basically Marlin should be able to use any pin the Arduino offers (read and write). You have to define the correct pin number in "pin.h" and make use of the corresponding functions from the Arduino libs ("analogread" resp. "digitalread").

If i remember correctly there exists at least one unused "safety connector" with an open (unconnected) cable near the printhead....?

A very nice solution would be a combination of a cheap sensor like this and these (introduced) resurrection system.

Looking at your skills - i am confident...

Edited June 20, 2015 by Guest

[Dim3nsioneer 557]

I removed the support for the (custom) gcode commands M605 and M606 since version 15.03. These stuff allocated a huge amount of the rare RAM and i never saw that anyone used it.

[...]

i know ...someday i should ask @dim3nsioneer about the intention of these commands...

 

The M605 and M606 are for saving current settings of the UM2 such as print temperature for later recall. It's the only way TweakAtZ can recall values on an UM2 set on the machine itself. If you don't need it, remove it. Others may want to use it. The number of setting sets that can be stored could be reduced from 10 to a smaller number if RAM is really an issue.

[NBroenner 7]

@tinkergnome: I am sure that I could do a demo version on one of my A-Star 32U4 Micro boards (Arduino Leonardo compatible). Yes there is an unused cable with two wires, but it should not be a problem to add additional wires. I think the biggest problem would be to find a location as near as possible to the nozzle without inhibiting maintenance or other things. The type of sensor might also be a difficult decision (switch, light barrier ...).

The analog connector has 3 wires (according to Main Board V2.1.1.pdf): 5V+, Gnd and ADC 15 via 1K R. So this connector should be compatible with the LM393 board.

Is there a guide how to setup the firmware development environment ? I did notice that you need Arduino IDE 1.0X and not the newer versions, but how can you setup the simulation environment ? Is there a step by step guide ?

Edited June 20, 2015 by Guest

[tinkergnome 927]

The M605 and M606 are for saving current settings of the UM2 such as print temperature for later recall. It's the only way TweakAtZ can recall values on an UM2 set on the machine itself. If you don't need it, remove it. Others may want to use it. The number of setting sets that can be stored could be reduced from 10 to a smaller number if RAM is really an issue.

 

Many thanks for the explanation, so i must admit that removing this part was not my best idea...

The buffer for 10 settings allocates permanently 700 Bytes of RAM. This are nearly 10 percent of the available 8kB only for this single thing - and irrespective of the use of these commands.

This topic needs definitly a close look again - i put it on my todo list...

Greetings to Zurich!