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... )

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.

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.