Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EECONFIG is a printer property, should be a board property. #181

Open
Traumflug opened this issue Aug 10, 2015 · 2 comments

Comments

Projects
None yet
2 participants
@Traumflug
Copy link
Owner

commented Aug 10, 2015

Heads up that this should be moved. For the ARM port I currently disable it silently in config_wrapper.h, because the LPC1114 doesn't even have an EEPROM, so it's not possible to implement this kind of storage. The proper way would be to make it a board property.

... or to remove EEPROM storage entirely in favour of having them stored in the board file as well. Branch issue-74 has some work in this direction. Bonus points for a calibration utility in Configtool to set these values automatically ...

@jbernardis

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2015

What more is there to this besides turning it off or on? What do you have in mind for a calibration utility?

@Traumflug

This comment has been minimized.

Copy link
Owner Author

commented Aug 14, 2015

What more is there to this besides turning it off or on?

EEPROM storage is just 4 values (14 bytes) per heater, each heater's P, I, D factors as well as I_limit. Currently they're set to fixed defaults (DEFAULT_P, DEFAULT_I, DEFAULT_D, DEFAULT_I_LIMIT), which isn't ideal, because their best values depend on an individual heater's properties like wattage, weight, etc., so they should be editable per heater.

There is some prior art. I had to introduce inverted signals for heaters for the Gen7-ARM (it uses an inverting driver to switch the MOSFET). This was done in this commit on gen7-arm: be6ca4c

The other prior art is on branch issue74: 29de379 It introduces these 4 PID values to DEFINE_HEATER() (plus two obsolete ones).

No problem if you're not comfortable with this "config_wrapper.h magic" used in the firmware, I can take on this part.

As gen7-arm introduces a fourth parameter already, it'd be best to add no. 5 to 8 on top of this branch, not on master or experimental. Unless I missed something serious, gen7-arm will go to experimental before too long, anyways.

What do you have in mind for a calibration utility?

Some firmwares have "PID tuning": http://reprap.org/wiki/PID_Tuning. This is an algorithm which heats the heater up and down, looks how long this takes, and calculates the best PID parameters from the result. This is done only once per printer/heater lifetime, so it's entirely fine to hardcode the values.

Configtool knows how to connect to the printer, it can send G-code for heating (M104, M140), it can look at the temperatures by sending M105. It can even re-upload a firmware with refined settings. So the idea is to run this tuning from there.

More in general I can see a third section with tabs (next to "printer" and "board") for printer calibration. One for testing endstops, one for verifying steps/mm, one for PID tuning, one for doing test prints, and so on. Can all be done by sending some G-code, asking the user for the results, uploading a refined firmware. Better, the simple fact such a set of tabs exists is a good hint for the user what he should take care about before trying to print arbitrary models. Like "before printing, work through this set of tabs to be reasonably sure your printer is calibrated properly".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.