# Specific 3D Printers, Scanners, & Hardware > RepRap Format Printer Forum > MakerFarm Forum >  About to try Marlin1.1.0RC4...

## lakester

I'm about to try Marlin1.1.0RC4 (well..., current RC branch anyway), on my 12" i3v (w/ a Hexagon HE and RUMBA controller).

I've taken my best shot at migrating the appropriate Configuration.h settings from Colin's firmware source for the above mentioned machine, to the new firmware.

Encountered one compilation problem related to DEFAULT_SOURCE_URL not being properly defined in the RUMBA case (in language.h).  Fixed that.

(Heh..., so that might suggest I'm an, er, early adopter on the RUMBA...  :Wink:  )

One thing I've never played with are EEPROM_SETTINGS.  I'm not even sure exactly how they're used..., so my question is this:  in Colin's version of the firmware, and in the source for 1.1.0RC..., EEPROM_SETTINGS is enabled by default.  Do I need to care about this?  Do I need to clear EEPROM somehow before attempting to use the new firmware?  It looks like EEPROM_SETTINGS are only put into effect with an explicit M50x command of some sort, i.e., unless I generate GCODE that does that..., it doesn't matter what the data in EEPROM actually is.  Or am I way off?  Or...???

Apart from the EEPROM_SETTINGS thing..., any other things I might want to double check before installing the new firmware?

Thx! -- John

----------


## Roxy

You should be using RCBugFix and not RC-5.   The RC-x is in place just to make the starting point for the Release Candidate very clear and easy to get back to.   But RCBugFix has all the improvements to the Release Candidate.   And as it turns out...   Your problem is already fixed in RCBugFix.

(RCBugFix got promoted to RC-5 a week or two ago.   Things are much better than RC4's base.   

As for EEPROM usage....   You are better off leaving that turned off until you get things up and running.  Otherwise it is very easy to be fighting problems you don't need to fight.   The problem is if the EEPROM is turned on, and values in the EEPROM are loaded and used and the settings in Configuration.h are ignored.   You need to do a M502 (to load default Configuration.h settings) followed by a M500 (to write the current configuration to EEPROM) to get things setup every time you make a change.   Its just easier to turn off the EEPROM until you have everything crossed over to the new Configuration.h file.

----------


## lakester

Cool..., thx!

Yah..., I'll switch to the RCBugFix rather than RC branch..., and will disable EEPROM.  

To be honest..., I'm not sure I would ever use EEPROM.  Most of the tuneables I care about are generated in the GCODE..., and I figure once the machine is "working"..., well..., should I wish to tweak Configuration.h-like stuff..., it just doesn't seem that hard to reburn the firmware..., and avoid weird mistakes by playing with EEPROM...

Thx again!




> You should be using RCBugFix and not RC-5.   The RC-x is in place just to make the starting point for the Release Candidate very clear and easy to get back to.   But RCBugFix has all the improvements to the Release Candidate.   And as it turns out...   Your problem is already fixed in RCBugFix.
> 
> (RCBugFix got promoted to RC-5 a week or two ago.   Things are much better than RC4's base.   
> 
> As for EEPROM usage....   You are better off leaving that turned off until you get things up and running.  Otherwise it is very easy to be fighting problems you don't need to fight.   The problem is if the EEPROM is turned on, and values in the EEPROM are loaded and used and the settings in Configuration.h are ignored.   You need to do a M502 (to load default Configuration.h settings) followed by a M500 (to write the current configuration to EEPROM) to get things setup every time you make a change.   Its just easier to turn off the EEPROM until you have everything crossed over to the new Configuration.h file.

----------


## Roxy

> Cool..., thx!
> 
> Yah..., I'll switch to the RCBugFix rather than RC branch..., and will disable EEPROM.  
> 
> To be honest..., I'm not sure I would ever use EEPROM.  Most of the tuneables I care about are generated in the GCODE..., and I figure once the machine is "working"..., well..., should I wish to tweak Configuration.h-like stuff..., it just doesn't seem that hard to reburn the firmware..., and avoid weird mistakes by playing with EEPROM...
> 
> Thx again!


Yeah....   That's how I operate.  My Configuration.h has my settings.   But with that said...   There are some cool features coming soon where you will need to have the EEPROM.   The High Resolution Mesh Bed Leveling will let you save a 15x15 grid of heights for your bed.   And the only reasonable place to keep those numbers is in the EEPROM.

----------


## lakester

Heh..., behold..., my can of worms!  I think I will open it...

I think this actually hits on the one remaining question I had...

But first:  I installed the new firmware..., *and it appears to just work!*  All endstops are obeyed..., everything moves in the right direction..., things heat correctly..., etc.  When I have some time later today..., will re-level the bed and try a print.  Thx to y'all on Team Marlin!

Back to the question:

I don't plan many more upgrades for this printer, but I will be adding the aluminum Y-plate, and want to use manual mesh leveling..., and therein lies the question:

I had assumed that manual mesh leveling saved its results somehow..., but I'm guessing I may not be exactly right about that.

*Is there a "reasonable" way to only occasionally do a manual mesh leveling..., with the results being restored from somewhere prior to a print?
*



> Yeah....   That's how I operate.  My Configuration.h has my settings.   But with that said...   There are some cool features coming soon where you will need to have the EEPROM.   The High Resolution Mesh Bed Leveling will let you save a 15x15 grid of heights for your bed.   And the only reasonable place to keep those numbers is in the EEPROM.

----------


## Roxy

Yes, the Manual Bed Level already saves the mesh to EEPROM.   But it isn't set up to do a high resolution matrix right now.

----------


## lakester

That is good to hear!  (Will investigate as to whether EEPROM_SETTINGS needs to be set for that particular thing)

FWIW..., I just completed the first print with 1.1.0RCBugFix..., and it worked perfectly, first time.   :Big Grin: 

For anybody following this:

Even though 'SDSUPPORT" isn't defined in the Makerfarm version of the code, be sure to set it if you need the SD card to work.

Nit:  I'm not sure this is exactly a bug..., or an "artifact"..., but it seems a little odd that the "notification" line at the bottom of the standard (non-"Graphical") LCD shows "Heating Bed", even when a job has completed and all heating has been shut off.

OK..., now off to the Makerfarm site to order the aluminum bed (and to other places to order the things needed to switch to a solid state relay so as to enable PWM on the heated bed).

Again..., thx Roxy and to everyone else for the work on Marlin. -- John





> Yes, the Manual Bed Level already saves the mesh to EEPROM.   But it isn't set up to do a high resolution matrix right now.

----------


## lakester

Follow-up:  not sure if I should post this to a new thread...

First:  Tried manual mesh leveling.  It appears to be working.  I wasn't 100% certain after the leveling operation whether I needed to save to EEPROM..., so I did (M500), just in case.  G29 returns credible values and Z axis is moving as expected during prints.  Forgot to mention..., I went ahead and added a M501 to the gcode startup section in the Slic3r config.

*Second..., but:  Printing from the SD card doesn't seem to work.  I can see the files fine from the control panel, but when I select one to print, the display goes blank and the machine just sits there.
*
The following defines are set:

#define MOTHERBOARD BOARD_RUMBA
#define SDSUPPORT
#define REPRAP_DISCOUNT_SMART_CONTROLLER
#define EEPROM_SETTINGS

The card had been removed and inserted and messages indicating that activity appeared on the control panel as expected.  The "Print from SD Card" menu item displayed the expected list of files.  It was only when a file was selected that things hung up.

FWIW..., when the hang was encountered..., all heating was discontinued.

----------


## Roxy

There was a minor bug in the SD Card printing when a filename started with a number.   That has been fixed.   It might be worth while to start a thread about what you are seeing over at www.github.com/MarlinFirmware/Marlin  because that is where the LCD Panel people hang out.   

Have you used this SD card before on your printer?   I'm wondering if there is a problem because it is a High Capacity card, or maybe it isn't formatted with an appropriate file system?   I never use SD Memory cards, so I'm not going to be much help on this issue.

----------


## lakester

Alrighty.

I did a pull on the current RCBugFix and the problem persists.

Interestingly, the file I initially tried to print does begin with a number..., but it appears I can select any file and it fails.

Yah, I've used this card (8GB) many times.

I'll ping the LCD people and see what happens..., thx!




> There was a minor bug in the SD Card printing when a filename started with a number.   That has been fixed.   It might be worth while to start a thread about what you are seeing over at www.github.com/MarlinFirmware/Marlin  because that is where the LCD Panel people hang out.   
> 
> Have you used this SD card before on your printer?   I'm wondering if there is a problem because it is a High Capacity card, or maybe it isn't formatted with an appropriate file system?   I never use SD Memory cards, so I'm not going to be much help on this issue.

----------


## lakester

This exact behaviour was observed by others when building with Arduino 1.0.6.  The problem "magically" goes away when building with later versions of the Arduino IDE.  I installed 1.6.8, and voila, printing from SD now works.

For reference:  https://github.com/MarlinFirmware/Marlin/issues/3229

----------


## Roxy

> This exact behaviour was observed by others when building with Arduino 1.0.6.  The problem "magically" goes away when building with later versions of the Arduino IDE.  I installed 1.6.8, and voila, printing from SD now works.
> 
> For reference:  https://github.com/MarlinFirmware/Marlin/issues/3229


Oh Geeeze!   I forgot to mention that.   It is in the Release Notes for RCBugFix to use Arduino v1.6.8 but people don't seem to be paying attention.

----------


## lakester

No problemo..., ya pointed me in the right direction for sure.

I notice there's a recent commit that sets Arduino 1.6 as the lower limit..., heh..., if only I had waited a day!

One "final" question:  heh..., where ARE the release notes?

Thx again -- John




> Oh Geeeze!   I forgot to mention that.   It is in the Release Notes for RCBugFix to use Arduino v1.6.8 but people don't seem to be paying attention.

----------


## ROBOCOP

Does anyone have config files for Makerfarm I3V 12" with Marlin RC6 mesh and Rumba they can post ?

----------


## lakester

I can share my current Configuration.h.  

*It is compatible with the RCBugFix branch of Marlin* as of this writing, though you should review the diffs before applying them to your system.

It is configured for the following:

Makerfarm I3V 12"RUMBAHexagon HE (w/ associated thermistor)Standard LCD (i.e., not the "graphical"/big display)Manual Mesh Leveling is enabled.SD Card support is enabled.

It also includes optimizations based on the work of printbus:

http://3dprintboard.com/showthread.p...ll=1#post41192

The entire thread is worth reviewing.

Keep in mind you may need/want to tweak your slicer settings to align with the printbus changes.

I also made some minor tweaks regarding some dimensional settings, to allow for clips..., etc.  I will probably revisit some of those changes in the future, but for now, they work for me.

I've attached the file..., hopefully it arrives intact.

Good luck! -- John

Configuration.h





> Does anyone have config files for Makerfarm I3V 12" with Marlin RC6 mesh and Rumba they can post ?

----------


## ROBOCOP

Thanks . I apriciate it. I should be able to make any needed changes from here. My slicer is simplify3d

----------


## ROBOCOP

Does anything need to be changed in config.adv ? How does mesh work with the fixed Z endstop on the i3v? Im having trouble understanding that.  With the robo the xaxis lifts of the z rods which triggers the endstops so it basically z homes below the bed .With the makerfarm the fixed z endstop would be above the bed so how do you do the leveling process?

----------


## lakester

I don't recall changing anything in config.adv.

The process is to first go through the regular mechanical leveling, setting the z-stop in the xy home position, and making sure that the other three corners are set to the same gap.

From that point, you go through the manual mesh leveling process, which allows for both positive and negative z-corrections..., wherein corrected/effective z can actually dip below the end-stop limited Z (but only by a very limited amount).  So..., the bed has to be mechanically level within this z tolerance, and then you use mesh leveling.

Don't forget to store results in EEPROM when done.  

FWIW, the steps I follow after burning new firmware are:

from the control panel...reset to "factory" config (these are the settings you set in Configuration.h)store to EEPROMdo manual mesh leveling.store to EEPROM

It's not clear to me what the compatibility is in EEPROM from build to build, so I go with better safe than sorry and redo it whenever I update the firmware.

Also, FWIW..., I have to do the full mechanical leveling very rarely these days, so maybe do the mesh leveling every couple of weeks or so.  I have a fairly consistent heating "protocol", so things settle down pretty repeatably.  Will be switching to a metal Y-plate when I have some tinkering time, which I assume will improve stability over time even further.




> Does anything need to be changed in config.adv ? How does mesh work with the fixed Z endstop on the i3v? Im having trouble understanding that.  With the robo the xaxis lifts of the z rods which triggers the endstops so it basically z homes below the bed .With the makerfarm the fixed z endstop would be above the bed so how do you do the leveling process?

----------


## ROBOCOP

Thanks. Iv been using mesh leveling on my Robo for a while now.  I got RC6 with mesh leveling all setup and running but for some reason i keep getting thermal runaway like 90% done with the print. Not sure why this is. Any ideas. Other then that its printing up until then fine. Maybe firmware issue or possibly has to do with the Z always moving now thus heating up the stepper driver more?

----------


## Roxy

I would suggest relaxing the thermal parameters in Configuration_adv.h   They might be set too tightly for your machine.   But it is a little bit strange it happens at the end of the print instead of early on.    

(By 'relax' I mean make the time duration longer and the temperature change a number smaller.   It will make it less likely to trip the protection if your hardware is having problems at the heat you are trying to operate.)

----------


## ROBOCOP

Thanks . Ill try it

----------


## printbus

Robocop - Are you printing with the bed heated?  What hot end are you using, and how is the thermistor attached to it? How is the wiring to the hot end bundled and routed?  I'll bet that what is happening is the cabling to the hot end is shifting as you print higher up, this causes the thermistor on the hot end to shift a bit, and the thermistor is no longer monitoring the hot end temperature properly.  

Thermal runaway has nothing to do with motor temperature, driver temperature, or the temperature of your RUMBA board.  Unless the new Marlin changed things, thermal runaway means either a hot end heater or the bed heater couldn't be kept at the set temperature for unusually long time. The suspicion here is that the heater is actually on constantly or close to it and there's a problem measuring the temperature correctly. If so, the heater could be in a thermal runaway situation where it is overheating. The printer shuts down as a safety precaution.  

If a thermistor doesn't maintain good thermal connection to what it is measuring, it starts reading lower temperatures than it should, and the heater will have a tougher time maintaining the set temperature....

----------


## ROBOCOP

What would you recomend i change these to?Like 60sec and 2degrees ?

If you get false positives for "Thermal Runaway" increase THERMAL_PROTECTION_HYSTERESIS and/or THERMAL_PROTECTION_PERIOD
 */
#if ENABLED(THERMAL_PROTECTION_HOTENDS)
  #define THERMAL_PROTECTION_PERIOD 40        // Seconds
  #define THERMAL_PROTECTION_HYSTERESIS 4     // Degrees Celsius

The problem may also be because their is no fan on the Rumba board. (Which i will be adding)It was never a problem with the old stock Makerfarm firmware but i know the Rumba was always pretty hot. The mesh leveling is a major plus for this printer as the MF heatbed is always pretty warped. 

Btw in another question i noticed the reprap full graphics lcd no longer shows the percentage of the print. Is there a way to add this back? 

Last question. With mesh the prints are looking great except for slight bulging of the corners . What settings can correct this?

----------


## ROBOCOP

> Robocop - Are you printing with the bed heated?  What hot end are you using, and how is the thermistor attached to it? How is the wiring to the hot end bundled and routed?  I'll bet that what is happening is the cabling to the hot end is shifting as you print higher up, this causes the thermistor on the hot end to shift a bit, and the thermistor is no longer monitoring the hot end temperature properly.  
> 
> Unless the new Marlin changed things, thermal runaway means either the hot end heater or the bed heater is on constantly for a duration exceeding a set threshold. The heaters should toggle on and off at a rate far quicker than the set time threshold while the desired temperature is being maintained.  The idea with the thermal runaway detection is that if the heater can't maintain to the set temperature, the heater will stay on constantly. If so, something is wrong and the printer shuts down as a safety precaution.  
> 
> If a thermistor doesn't maintain good thermal connection to what it is measuring, it starts reading lower temperatures than it should, and the heater will be turned on for longer an longer periods of time....


Nothing changed hardware wise from the old firmware i was running which always printed fine. Yes i am printing PLA with stock Makerfarm 12" heated bed / relay with boro glass top. The hotend is a Hexagon with tapped screw in 3mm 100k epcos thermister( I can see that causing the issue but its been working previously. ) The cabling is zip tied to the wades so it doesnt move near the hotend. The temps on the LCD stay within 1 degree plus or minus while in print it looked like and the print is printing very good. The temp seems dialed in from the looks of the part. If the hotend remained heating wouldnt it not print good cause of the filament being too hot?

----------


## printbus

> ... If the hotend remained heating wouldnt it not print good cause of the filament being too hot?


Well, the bulging at the corners could be a sign of too high of a temperature...

Are there two additional thermal runaway lines in the configuration file for the bed? Are they also uncommented? I'm just trying to understand which of the two temperature control circuits is tripping - hot end vs. bed.  Does the error message on the display add any insight?  Were you monitoring the temperatures displayed on the LCD or on control  software right at the point of shutdown?  If I understand Marlin thermal runaway, a temperature should have been  reading low by at least the thermal runaway hysteresis amount before the trip  occurred.  That would answer whether the problem is with the bed or the  hot end. 

Note that I don't believe any MakerFarm firmware configuration has thermal runaway protection enabled, so you probably didn't have that in your printer until now. It could be that whatever issue you have now, you've always had.

----------


## printbus

Here are two threads that talk about having thermal runaway problems on a MakerFarm printer -

http://3dprintboard.com/showthread.p...-ambient-temps - Here the problem was a bit too much print cooling fan airflow in at a cold ambient temperature tripping the hot end thermal runaway.

http://3dprintboard.com/showthread.php?10166-Thermal-Runaway-Protection-(Dual-Extruders) - Here the problem was the heated bed, but the OP didn't come back and say what he did to fix the problem. Like here, the thermal runaway problem showed up as soon as he enabled detection for it.

----------


## ROBOCOP

There are these 2 lines
#define THERMAL_PROTECTION_HOTENDS // Enable thermal protection for all extruders
#define THERMAL_PROTECTION_BED     // Enable thermal protection for the heated bed

I think i may have found something though. Not sure if it can cause the issue but the thermister in the hot end is a 100k 3950 which is option 11 and i forgot to change it in the firmware . Right now its set at 1 (100k epcos) . I gotta go check the printer . Its actually not my printer. I bought it for my brother a while back so its at his house. The error message just said thermal runaway on the lcd so not sure if its the bed or hotend. Im leading toward hotend. I didnt see the temp right when it went to thermal runaway. I did monitor it for the first half of the print when it was fine. I need to check again and fully monitor the temps. Im heading over there now so i will report later. Thanks for the help. I appreciate it.

----------


## ROBOCOP

Ok so i went over there to check things out and when i went to turn the printer on it wouldnt . Power supply was dead. I did notice even before i printed anything yesterday the LEDs and hotend fan were like flickering so im wondering now if it was already on its way out . Anyway gotta wait until a new PSU comes in before going any further. It a cheap 12v 30A LED type PSU.

----------


## printbus

Robocop - so now you have the quandary of was it a heater/thermistor problem that put a more extensive load on the power supply, or a failing power supply that couldn't heat things properly...  Others have had early failures with the LED-type power supplies, so you're not alone there. My vote would be the failing power supply couldn't maintain the high load necessary for the heat bed as the power supply warmed up. Flickering lights is a good sign of this.  If the power supply output is lower than it should be, the heaters will be dissipating less heat than they should.  If the power supply output is bad enough, the heaters won't be able to reach the set point, leading to the thermal runaway protection kicking in. The wrong thermistor setup would have caused the hot end temp to read low by about 15 degrees at a 200 degree setpoint. While an error, it shouldn't have been a big enough error to create the thermal runaway detection. At bed temperatures, the thermistor error would have only been a few degrees. 

I've looked at the thermal runaway code in at least older versions of Marlin.  I've corrected some inaccuracies in my first post.   Robocop is correct that the LCD won't show which heater is the problem. If the printer is connected to host software however, the host software should be getting a thermal runaway message that includes various detail.  A HEATER ID value between 0 and 8 correlates to an extruder number; a value of 9 correlates to the print bed.  

Since my last post, I've realized Robocop doesn't have a MakerFarm printer.  Somewhat getting back to Lakester's context and this being the MakerFarm subforum, I think a key point of note is that thermal runaway detection is disabled in MakerFarm builds, but is enabled by default in the Marlin github repository files.  MakerFarm owners that get thermal runaway errors when migrating to the new Marlin should likely assume they have hardware issues that have been going undetected with their old firmware.  The errors are not likely to be due to setting changes in firmware or with their slicer.  To determine what is causing the thermal runaway possibility, you either need to monitor the LCD for measured temperatures that aren't staying at the set point, look at the serial messages being sent to host software, or perhaps go in and disable thermal runaway for the bed (where the need is arguable anyway) and see if that causes the error to no longer occur.

----------


## ROBOCOP

Powersupply should be in tuesday. Then i can do some tests. I didnt have the printer connected to the computer at the time to see the communication. I will do so when testing with the new PSU. The printer is a Makerfarm I3v 12" .You are correct i believe in that the original makerfarm marlin firmware didnt have thermal protection. The heatbed is a 300W heatbed with a relay switching power directly from the PSU so it does need like 25A. I have heard the LED type PSU's failing out of nowhere which does make it hard tell if was because of load . I do have a 30A fast blow fuse inline and the fuse is still intact. Also using heavy 12Ga silcone wire for the heatbed and relay. If it does turn out to be a heatbed issue that went unnoticed with the old firmware i will probably change the heatbed. 25A is a bit overkill. Probably go with a lower wattage kapton heater with aluminum heatspreader like on my other printers. Never been a fan of the PCB type anyway cause of the warping. 

I know i read of some people having thermal issues with the 12" Makerfarm heatbed and toasted relays and PSU failures.

I found this thread which seems to be just like my issue. 
http://forums.reprap.org/read.php?262,604700

----------


## printbus

> I found this thread which seems to be just like my issue. 
> http://forums.reprap.org/read.php?262,604700


(paragraph deleted. Even here I may have been misrepresenting how the thermal runaway protection algorithm handles a change in the temperature setpoint like that person was doing. I really don't know. )

BTW, the additional link in that thread, https://github.com/MarlinFirmware/Marlin/issues/2582, says the abstract '9' correlation to the bed has been replaced with descriptive text in newer versions of Marlin.  What a thought.  I think I'm out at this point. I've got to stop trying to help people with firmware updates I don't use and haven't even looked at.

----------


## lakester

First comment:  On or around line 369 in Configuration_adv.h, it looks like you can uncomment "//#define LCD_PROGRESS_BAR" to restore the functionality I think you mentioned.

Second comment:  Apologies if I missed something in the preceding discussion..., but it also seems at least possible that you have a genuinely failing bed heater relay.   I missed if you mentioned that the firmware was actually reporting a runaway condition..., if it was..., were the HE and bed being successfully de-powered?  ..., or did the bed just sit there and cook?

FWIW, I still run the mechanical relay, but I wired it with 10Ga from the start, AND I placed the relay board (and the RUMBA for that matter) on standoffs..., to ensure airflow underneath the board(s) as well.  As I recall, MF's instructions just have you screw everything down flush to the wood.

----------


## ROBOCOP

Very good to know about disabling the progress bar . Thanks.  It is possible the relay is failing. Its on my list to check before installing the new PSU. The bed wasnt cooking when it failed. Felt about the right temp .It was printing PLA so it was only at 60 degrees and the room was warm. It is weird that the thermal runaway was at the end of the print as the bed pulls more current in the beginning of the print. Still not sure the thermal runaway was because of the bed though. I do have both relay and Rumba on standoffs. The 12Ga silicone wire i use has very high strand count. I could barely fit the wire in the screw terminals.

----------


## ROBOCOP

UPDATE:  So i got the new powersupply in . Before installing i went over all the printer wiring to make sure it was good . Tested the heat bed relay which all turned out good. I changed the thermister in the firmware to the correct 100k 3950 (11) . I had previously forgot to change it from 100k epcos (1) . In config.adv i also changed the thermal protection period from 30 to 60 on the hotend and 20 to 60 on the bed.  I then did a test print while having it connected to the computer to watch for any error codes . Well turns out it printed fine. Both hotend and bed temps stayed with plus or minus 1 degree from the target. No problems . I printed a few more things and all is good. 

I cant be sure what caused the problem originally but it had the be the thermister option or the thermal protection period and i dont think the powersupply failure was related to the thermal failures ,just coincidence . The bed Thermal protection period at 20 and 2degrees hysteresis is my guess for the thermal failures. 

I did have one issue with mesh leveling in that at the end of the print the nozzle plunged down into the part instead of homing the x y first . In my endcode though i have G28 X0 Y0 so im not sure why it did that. What the best way in the endcode to have it lift up then home x and y ?

----------


## lakester

It'll be interesting to see what happens when I upgrade my y-bed to aluminum..., on the off chance that'll change thermal response in a way that triggers the default thermal runaway protection settings.  Likewise when I eventually upgrade to a SSR for the bed.

Anyways, congrats on things working out!

As for the end-of-print z move behaviour..., hmm.  Since I switched to the new firmware, I noticed that I tend to have a "z-positive" dimple (guess that's a pimple) at the pre-homing exit point.  It's very small/minor.  I can't honestly say I've been attentive enough to attribute it to any one thing..., i.e., I haven't noticed there's any Z movement at the end of a print at all..., but that doesn't there hasn't been.

I'll keep an eye out and report back.  For the moment..., here is the tail-end of a typical print:

...
G1 X140.361 Y106.977 E2.63078
G1 X140.323 Y105.648 E2.65583
G1 E0.65583 F900.00000
G92 E0
M104 S0 ; turn off temperature
M106 S255 ; Turn on part cooling fan to help speed cool-down
G28 X0  ; home X axis
G28 Y0  ; home Y axis
M84     ; disable motors
M190 S0 ; wait for bed temperature to be reached

----------


## ROBOCOP

I may also change my bed to aluminum/kapton heater. Not a fan of the PCB type expecially at 12x12 which bows and warps so easy. If you go with a SSR make sure its quality like a Crydom SSR . The cheap Fotek style dont work to well and cant handle PIDs. 

As for the plunging im not sure why its doing it .I think its something in the mesh doing it as it only plunges down a few mm before homing the x and y but i dont have anything in my end code in S3D relating to Z at all. Could it have something to do with the below line in the mesh leveling code

#define MESH_HOME_SEARCH_Z 2 

What does that do?

----------


## lakester

I'll check out MESH_HOME_SEARCH_Z, in the meantime, I wonder if the z-correction is being inappropriately removed/discounted during the homing operation...




> I may also change my bed to aluminum/kapton heater. Not a fan of the PCB type expecially at 12x12 which bows and warps so easy. If you go with a SSR make sure its quality like a Crydom SSR . The cheap Fotek style dont work to well and cant handle PIDs. 
> 
> As for the plunging im not sure why its doing it .I think its something in the mesh doing it as it only plunges down a few mm before homing the x and y but i dont have anything in my end code in S3D relating to Z at all. Could it have something to do with the below line in the mesh leveling code
> 
> #define MESH_HOME_SEARCH_Z 2 
> 
> What does that do?

----------


## lakester

Hmm (again).  In ROBOCOP's case, the G28 X0 Y0, if that is the actual gcode being used, should not create any z-movement at all.

MBL is disabled during most homing moves, but even that should produce no Z movement due to the loss of a previous correction.  MBL IS enabled when G28 implies or specifies a Z homing operation (though not during any XY homing moves with which it is possibly combined).

For G28 operations that imply or explicitly specify Z, then in MOST cases, the Z move will be done last, after any XY moves (which is opposite the behavior ROBOCOP describes).

FWIW..., G28 X0 Y0 is one of a couple special cases for homing.   It MIGHT be worth trying uncommenting the line:

*//#define QUICK_HOME  //if this is defined, if both x and y are to be homed, a diagonal move will be performed initially.*

in Configuration_adv.h

..., though I kinda doubt this will inhibit the z-move you're seeing..., since I'm thinking the G28 may NOT be the culprit.

Anyways..., 0.02USD...

Note:  almost forgot:  the MESH_HOME_SEARCH_Z is MOSTLY involved with the bed leveling procedure itself..., I don't think it actually is influencing anything seen during "print time".

----------


## lakester

Small update:  

I paid attention to z-movement at the end of the past couple of prints.  

There is no z-movement during the end-of-print homing operation.  FWIW, I'm homing XY with separate G28 commands, i.e.,
G28 X0
G28 Y0

When I print next, I'll try it with G28 X0 Y0.

----------


## ROBOCOP

G28 X0 Y0 should be the same . I havent had a chance to print to check .Ill post up when i do.

----------


## lakester

Agreed..., but it is a special case in the code, so might be worth testing the combined as well the individual homing operations.




> G28 X0 Y0 should be the same . I havent had a chance to print to check .Ill post up when i do.

----------


## ROBOCOP

Ok well this is weird . I just upgraded to a E3D v6 , reflashed the firmware and now its not doing it anymore . I didnt change anything in the start code from previously. I cant see how the new hotend can cause that so it must have been a glitch when i first installed the firmware and reuploading it fixed it.

----------

