More information during print

[Render 28]

[...]
 CXX   Servo.cpp
 CXX   /Applications/Arduino106.app/Contents/Resources/Java/hardware/arduino/cores/arduino/Tone.cpp
 CXX   /Applications/Arduino106.app/Contents/Resources/Java/hardware/arduino/cores/arduino/main.cpp
 CXX   _Ultimaker2/Marlin.elf
target: Marlin
_Ultimaker2/electronics_test.o.progmem.gcc_sw_table+0x2e): warning: internal error: out of range error
_Ultimaker2/electronics_test.o.progmem.gcc_sw_table+0x30): warning: internal error: out of range error
_Ultimaker2/electronics_test.o.progmem.gcc_sw_table+0x32): warning: internal error: out of range error
_Ultimaker2/electronics_test.o.progmem.gcc_sw_table+0x34): warning: internal error: out of range error
_Ultimaker2/electronics_test.o.progmem.gcc_sw_table+0x36): warning: internal error: out of range error
_Ultimaker2/electronics_test.o.progmem.gcc_sw_table+0x3: warning: internal error: out of range error
_Ultimaker2/electronics_test.o.progmem.gcc_sw_table+0x3a): warning: internal error: out of range error
_Ultimaker2/electronics_test.o.progmem.gcc_sw_table+0x3c): warning: internal error: out of range error
_Ultimaker2/electronics_test.o.progmem.gcc_sw_table+0x3e): warning: internal error: out of range error
_Ultimaker2/electronics_test.o.progmem.gcc_sw_table+0x40): warning: internal error: out of range error
_Ultimaker2/electronics_test.o.progmem.gcc_sw_table+0x42): warning: internal error: out of range error
_Ultimaker2/electronics_test.o.progmem.gcc_sw_table+0x44): warning: internal error: out of range error
_Ultimaker2/electronics_test.o.progmem.gcc_sw_table+0x46): warning: internal error: out of range error
_Ultimaker2/electronics_test.o.progmem.gcc_sw_table+0x4: warning: internal error: out of range error
_Ultimaker2/electronics_test.o.progmem.gcc_sw_table+0x4a): warning: internal error: out of range error
_Ultimaker2/electronics_test.o.progmem.gcc_sw_table+0x4c): warning: internal error: out of range error
 COPY  _Ultimaker2/Marlin.hex
AVR Memory Usage
----------------
Device: atmega2560
Program:  134910 bytes (51.5% Full)
(.text + .data + .bootloader)
Data:       5999 bytes (73.2% Full)
(.data + .bss + .noinit)
  text	   data	    bss	    dec	    hex	filename
134614	    296	   5703	 140613	  22545	_Ultimaker2/Marlin.elf

Nicolinux, your program exceeds 128K of flash (134910 bytes) and I guess you're dealing with a problem related to AVR. Daid talked about it a few posts before yours, and you can find the workaround he did here (only if you are using make to build the firmware).

The thing is, if function pointers are used (and they are), their targets should reside in the lower 128k of the chip, so you have to force the linker to start with those files.

So, edit the makefile and move "electronics_test.cpp" from the end of line #221 to the end of line #216. This will solve the warnings. On the other hand, you have to consider this matter for any other files that you create if they have function pointers targets.

By the way Daid, does this issue affect MarlinSimulator? I guess the environment doesn't consider this kind of low level stuff, but I've been finding a weird behaviour since I exceed 128K and I'm not sure if it's related. Everything goes right but sometimes, when I close the simulator window, it won't return to CodeBlocks, instead, Windows complains about the program not exiting fine.

Also, if you are not using make to build your releases, are you dealing with this problem within CodeBlocks? I mean, you don't need to because Ultimaker2Marlin doesn't exceed 128K of flash but, have you done the same workaround in CodeBlocks with compiler and linker settings?

I will love to also have your CodeBlocks project for Marlin besides MarlinSimulator, would it be possible?

[chuck-yanke 9]

Tinkergnome, I want I am just a humble user and have updated my U2+ with your most recent firmware. It is amazing. I have so much more information and control over the printing process. I am sure this takes a lot of your time, I truly appreciate all your work. Thank you!

[peteruithoven 4]

The Ultimaker 3's display is managed by a different kind of computer (Olimex instead of Atmel (Arduino)), so this firmware probably isn't suitable for Ultimaker 3's right?

Maybe this is something that could be clarified in the introduction topic?

[ultiarjan 1,209]

The Ultimaker 3's display is managed by a different kind of computer (Olimex instead of Atmel (Arduino)), so this firmware probably isn't suitable for Ultimaker 3's right?

Maybe this is something that could be clarified in the introduction topic?

 

 

What is the "Tinker-Firmware"?It's an alternative firmware for machines of the Ultimaker 2 series.

 

Think it's already clearly stated it's for the Ultimaker 2 series.

[tinkergnome 862]

Well, regarding the firmware the Ultimaker 3 is a completely different thingy...

Let's make a compromise: If someone develops a nice and free firmware builder for the UM3, i'll add it to the exclusion list, ok?

[fuerer_g 0]

I don't know how the remaining time is calculated, but the last few (more than 10, sometimes) layers' remaining time is always one minute. This is not very helpful nor accurate.

Any way to change/fix that? Or display the remaining number of layers, if remaining time is less than one or two minutes.

What do you think?

Edited November 30, 2016 by Guest

[gr5 1,602]

The proper solution would be for Cura to insert a comment on EVERY layer change that says expected remaining time. Then Marlin can make a more intelligent calculation based on how long it took so far and how long cura *thought* it would take so far.

Instead there is only a single comment at the top of the gcode file. So if the top of your part is very fast to print such as robot antenna then it will give you an estimate that is too high (will print much faster than marlin expects) but if you have the opposite - say you print a cow with skinny legs and then a large body - it will tend to error in the other direction saying it's a minute left when it still has 4 minutes.

I find that the original estimate by Cura is extremely accurate if you don't change the feedrate.

[AreDigg 8]

Is there a way to see what is stored after an "adjust build plate" is done? I changed to a slightly thicker build plate, and after adjusting I still had to use "baby stepping" up to 0.35 just to get the nozzle to extrude. It literarily is digging up the plate. I am using 16.08.2 on the um2e+. I tried to adjust with even higher gap, but it seem like it is not storing the newer values anymore.

[tinkergnome 862]

Is there a way to see what is stored after an "adjust build plate" is done?

 

 

• connect the printer to a serial console (e.g. pronterface)

• send "M501" to the printer - that loads the stored settings from EEPROM and prints a summary on the console

• check the line that starts with "echo: M206..."

• the Z-value is the stored home offset

 

[jeroenm 5]

Is it needed to update de UM2 with V17 before switching to Cura 2.4 ?

[gr5 1,602]

No. Cura 2.4 works okay with any version of Marlin on UM2. I still prefer Cura 15.X for my UM2 and I use Cura 2.4 for my UM3. Although I did slice maybe 5 models with cura 2.X and maybe 2 with Cura 2.4. Cura 15.X is faster to launch, faster to slice and view, the keyboard shortcuts work better, the options are simpler. Cura 2.4 does have some very nice features but usually Cura 15.X is good enough.

[Novastorm 12]

Hello at all,

I have a question abaut the pause triggering on the PC7 pin.

The compiled hex file monitors the PC7 input pin and triggers the pause menu if it is pulled down to LOW (during printing from sdcard *). Resuming the print is done manually via the menu.

Does the PC7 need 5V to LOW, or a other Voltage than 5V, to operate?

[gr5 1,602]

I recommend you measure the pin when the board is powered on. It will be either at 5V or 3.3V depending on the type of arduino. In other words there is a "pull up" resistor inside the arduino that makes PC7 go to the normal arduino power voltage (3.3V or 5V).

I'm pretty sure it's a 5V arduino which would mean setting it to any voltage above about 2.5V normally should be okay and then set it to 0V when you want the printer to stop.

If you set it to a little higher than 5V there is protection circuitry that will feed your voltage into the 5V supply. If it's a small amount of power then no harm done but if you put in many amps you can fry the arduino and anything else trying to run on the 5V power.

Pulling PC7 only down to 3.3V should be fine (no halt - no damage). In other words if you are using 3.3V circuitry to control this PC7 signal that should be fine.

[Novastorm 12]

Thank you for the informations @gr5 .

On the J23 is a power pin with 5V.

For safety is better to reduce the voltage to 3,3V.

I switch the 3,3V with a optocoupler relais. Because my PLC run with 12V DC. It would be the safest way to decoupel both Circiuts.

I think that will work.

[gr5 1,602]

If you have an opto-isolated relay then you can just do the normal method and use the relay to short it to ground when you want the printer to stop and leave the relay open normally. There is no reason to connect J23 to anything when you don't want the printer to stop as it already has a "pull up" resistance.

[Novastorm 12]

The PC7 is on the J23 connector. So i must only connect the PC7 and ground from J23 to the optocoupler-relay. When the relay switched on, the PC7 get a low signal.

I did not knew that it has a pull up, this makes it more easy.

Thank you.

I have not much experience with arduino controllers. I work mostly with industrial electronics. Like Siemens S7 300 and 400.

[mendells 52]

Is the tinkergnome "filament_sensor" the same or similar to the marlin "filament runout sensor"? I just got a Filament Sentinel and I'm trying to figure out how to update our firmware to add it in(I am not a code guy and so far it's all been a little out of my comfort zone). I noticed there is a "FILAMENT_SENSOR_PIN -1" in the pins.h and "FILAMENT_SENSOR_PIN=30" in the package.sh (which I cannot for the life of me figure out how to make work).

So i'm just wondering if the filament sensor is already set up and If I can just plug the signal pin into PC7 and have it work without having to load new firmware?

[Labern 765]

Is the tinkergnome "filament_sensor" the same or similar to the marlin "filament runout sensor"? I just got a Filament Sentinel and I'm trying to figure out how to update our firmware to add it in(I am not a code guy and so far it's all been a little out of my comfort zone). I noticed there is a "FILAMENT_SENSOR_PIN  -1" in the pins.h and "FILAMENT_SENSOR_PIN=30" in the package.sh (which I cannot for the life of me figure out how to make work).

So i'm just wondering if the filament sensor is already set up and If I can just plug the signal pin into PC7 and have it work without having to load new firmware?

You can read all about it here

[mendells 52]

You can read all about it here

Thanks! I don't know how I missed that :/

[nzo 16]

Vielen Dank für deine tolle Firmware Tinkergnome. Ohne Probleme auf meinem UM2+ installiert. So gut, um zu sehen, was live passiert!

[nzo 16]

How can I preset the nozzle temp and have it stick? Currently the nozzle is set to 0 on UM2+ boot. Thanks!

[tinkergnome 862]

How can I preset the nozzle temp and have it stick? Currently the nozzle is set to 0 on UM2+ boot. Thanks!

 

Let's see... If you are referring on the material settings: which material is selected and which printing temperatures are stored for it?

And if you are referring to the PREHEAT menu: the nozzle is pre-heated to 80 percent of the selected printing temperature (rounded down), but only if the temperature of the buildplate is within a range of 10 degree to its target temp.

And if you're talking about somehing completely different - please explain about it...

[nzo 16]

Tinkergnome: This is the PRINT screen I've been viewing to wind the nozzle temp to 210C each time I print.

The MATERIAL menu has the correct settings for PLA on this machine.

[nzo 16]

I'm sorry Tinkergnome - I found my own answer just by watching that menu carefully. There is a heating sequence at the end of which the temperatures update and away it goes But thank you for responding.

[tinkergnome 862]

I'm sorry Tinkergnome - I found my own answer just by watching that menu carefully. There is a heating sequence at the end of which the temperatures update and away it goes :)But thank you for responding.

yep, it's the same principle - the nozzle heating starts as soon as the temperature of the buildplate is near it's target temp.