Mightyboard support

[TBSliver]

Hi,

Have been looking at how to add mightyboard support recently, as have got access to a Replicator clone - however have run into several issues. Main one is, there is no support for MCP4018 I2C digipots for stepper motor current setting. Obviously this will need to be added, and am willing to do the work, however there also doesnt seem to be a logical place to start adding support for a new board in.

After looking at both the Development and Release branch, there doesnt seem to be some logical place to put any new work, especially for adding a new Board support, as the pins definition location has changed between the two. There also seems to be a lot of commits between Development and Release, which makes me wonder if the Development branch is stable enough to base new work of. Is there a particular commit ID which would probably be best to start from?

And in regards to 'Why not use Makerbots software', well a Replicator clone is going to get nearly zero support in their Makerware closed source software, and has anyone actually tried using ReplicatorG recently? Especially compared to Cura or even Slic3r... Also, theres no support for part cooling fans in ReplicatorG...

[thinkyhead]

Developers: If one of you would like to help @TBSliver put together this feature, you can find an article about I2C which discusses the MCP4018 here and the spec sheet is here.

[thinkyhead]

@TBSliver The Development HEAD is the starting-point you should use for any new features, otherwise it won't match up to the current code. At the moment the Development HEAD is more bug-free than the tagged 1.0.2 version, as we have fixed dozens of bugs since that time, but there may be a lingering issue with auto bed leveling, so keep an eye on that if you use that feature.

[TBSliver]

Auto bed leveling is (in this case fortunately) not a feature on Replicators.

Information about the pins on the Mightyboard for this MCP4018:

• the controller is an atmega1280
• pins are:
  • X-AXIS-POT - 94
  • Y-AXIS-POT - 90
  • Z-AXIS-POT - 86
  • A-AXIS-POT - 73
  • B-AXIS-POT - 69
  • POTS-SCL - 68

So the I2C library we use will need to be a software based, as they are not on I2C ports.

schematics and gerbers here - http://www.thingiverse.com/thing:16058/#files

The other thing which will need to look at is the Thermocouple support, which is a MAX6675 IC. This is used on the two hotends:

• THERMO-DO - 7
• THERMO-CS2 - 6
• THERMO-CS1 - 5
• THERMO-SCK - 4

The heated bed seems to be a Thermistor, which I know is already in Marlin.

[whosawhatsis]

Not saying Mightyboard support shouldn't be added to Marlin, but for the record, Sailfish firmware is written for Mightyboards and is an actively developed open source project. I'm told that the "official" firmware run by pre-Gen5 makerbots and their clones is more or less just an older version of Sailfish.

[TBSliver]

Yea, they do run an older version of sailfish - infact a cut down one with just the core processes, due to the first-run stuff that Makerbot wanted which takes up the rest of the space. This firmware is obviously not updated as they now only support their closed source machines, so theres been no improvements. I could put latest sailfish firmware on there instead, but I'l still be stuck by the 'must use ReplicatorG' issue, or use GPX with Cura or another slicer - which I've tried multiple times (almost got it to work too), but requires too much faffing about. Especially when trying to support this for a hackspace...

[thinkyhead]

Thermocouple support, which is a MAX6675

It's in Marlin for a while, and it actually seems to work now.

[AnHardt]

But only for one of them.

[AnHardt]

We also have already support for MCP4451 four chanel I2C digipots for for setting the current on Azteeg X3 Pro. Grep for 'DIGIPOT' to find a starting point for your work.

[whosawhatsis]

I had to implement an MCP4331 for something else, and after carefully reading the datasheet, I figured out that it didn't actually need any code changes from one that was already implemented, I just needed to use {0x10, 0x60, 0x70, 0x00} for DIGIPOT_CHANNELS to account for some small differences in the protocol for addressing them. A similar method might work for MCP4018.

On Tuesday, May 12, 2015 at 05:24, AnHardt wrote:

We also have already support for MCP4451 four chanel I2C digipots for for setting the current on Azteeg X3 Pro. Grep for 'DIGIPOT' to find a starting point for your work.

— Reply to this email directly or view it on GitHub (https://github.com/MarlinFirmware/Marlin/issues/2051#issuecomment-101257355).

[TBSliver]

I dont think that will work, as the 4 digipots are on seperate pins, and probably on the same channel number. Infact, the device I2C address is identical on all devices (see Table 5-2 in the spec sheet mentioned here) which is 0x2F.

May have to have an extra #define for which type of stepper digipot there is, and then set the DIGIPOT_CHANNELS to the pins, and the SCL pin as another #define... hmm. Actually, will have a quick Grep around and finish commenting shortly

[TBSliver]

Have had a dig around, and come up with an initial proposal for some of the changes - please comment! (in this ticket obviously...)

Marlin MCP3018 Proposal

[AnHardt]

Looks reasonable for a start - to me.

[TBSliver]

Well this job just keeps getting more fun...

So not just am I having to define a new set of #define's for the MCP3018, will have to also re-do the way the reading works for MAX6675, as the Mightyboard defines a different set of pins for the SCK, DO, and CS... although does share the SCK and DO between the two MAX6675's on board.

This may take a while.... :/ Unless i've missed something, the only thing you can set for a MAX6675 is the SS pin? (I'm ignoring that it I have two extruders for now - this is causing enough headaches :P)

[thinkyhead]

@TBSliver I'm not very intimate with the MAX6675, but as I recall when we were having conflicts between it and the SD card, it was partly due to the lack of proper CS on these devices – the MAX6675 at least. Maybe someone else who knows more about it can explain better, or correct me if I've got the issue wrong.

[uhrheber]

I also have a makerbot clone (Weistek WT150), that uses a mightyboard and a modified sailfish firmware, and I'd like to help. I'm not so much of a software guy, but a designer of embedded hardware. Where do we start?

[TBSliver]

Hey, had to postpone my work on it due to just not having enough spare time... and also to how much of some of the code would have to be rewritten, or refactored, to accommodate this machine.

The part I hadn't started looking at was the thermocouple and thermistor monitoring, as Marlin currently only has support for a single thermocouple.

That, and the working with the specific chips they use for the digipots on the stepper drivers are basically what are needed to be done.

If I get a chance tomorrow I will push what I had started on, although it's not much more than initial figuring out how to do this.

On Mon, 8 Jun 2015 at 10:22 uhrheber notifications@github.com wrote:

I also have a makerbot clone (Weistek WT150), that uses a mightyboard and a modified sailfish firmware, and I'd like to help. I'm not so much of a software guy, but a designer of embedded hardware. Where do we start?

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2051#issuecomment-109925691 .

[TBSliver]

In regards to @thinkyhead's comment, the problem is that they are using a software defined SPI port for the MAX6675's rather than one of the hardware ones - which means another SPI library will have to be included for software based stuff. Also I think there are no software I2C libraries which support multiple instances of itself, as the digipots only share the clock port - Although I remember Adafruit having something that would work wiht some thermocouple MAX chips which could work on any pin.... I'l have to dig and find it

[TBSliver]

Infact yes! here it is! https://github.com/adafruit/MAX6675-library

I knew it was around here somewhere.... That code supports any pin to be used on a MAX6675

[uhrheber]

My problem is that I currently only have one printer. I'm using it to build parts for a RepRap Funbot I1, so before I haven't finished the funbot, I'm not experimenting with the WT150. But the problem with the epots should be easy to solve, because the code is already in the sailfish sources, and there are also Arduino libs for that. Worst case I'll just buy a separate epot and test it with an Arduino Mega.

[TBSliver]

Thats not a bad plan... And actually thinking about it, I have a couple of MAX6675's sitting around, or their bigger brother atleast. Hrm.... may be able to emulate some of this then yea to make it easier.

[uhrheber]

I just ordered samples of the MCP4018 and the MAX31855, they should arrive next week. In the meantime I'll try to learn something about the special touch TFT that the WT150 uses. Maybe I can add support for it to Marlin.

[uhrheber]

Speaking of epots, makerbot has a special GCode (G130) to set the potentiometer values. They are using it to reduce the current when the steppers are idle for a longer time (e.g. waiting for the tools to heat up). AFAIK no other software supports this, and it's also not in marlin. How will we handle this? Add the G130 to marlin, or just ignore it? And where will we store the default values? In the E2PROM or just as constants in the flash?

[AnHardt]

@uhrheber That opens an other can of worms. If the power reduction is available, it should be preferred over switching off the power for the steppers with M84, M85, What makes M84 and M18 different. We already have defines for the 'normal' current. A 'reduced current' define could be nice. Storing in EEPROM and having a menu is more a philosophical question - makes sense during a setup-phase - but not if a good setting was found. Same for G130, to set the actual current - convenient for setup - later useless.

[uhrheber]

I wouldn't say it's useless, otherwise makerbot wouldn't use it in their startup code. Here's an example from Makerbot Desktop 3.7:

"G1 X#START_X Y#START_Y Z#START_Z F3300.0 (move to waiting position)", "G130 X20 Y20 A20 B20 (Lower stepper Vrefs while heating)"

After heating up, and before printing, they set the currents back to their default values: "G130 X127 Y127 A127 B127 (Set Stepper motor Vref to defaults)"

I guess that's necessary to prevent overheating strong stepper motors of the bigger Makerbots. But maybe it's just to prevent a 'singing' of the motors.

Also, switching off the motors completely while waiting isn't possible on printers that rise the platform from Zmax to Zmin with a belt drive (like my Wt150). When you turn off the steppers, the platform will fall down unbraked.

But another question: What number space should I choose for the Mightyboards in boards.h? I don't want it to collide with something else later.

[AnHardt]

@uhrheber What they do with G130 (manually) we have a automatic for. But this switches OFF the motors, what causes Motors to jump to the next full step. Therefor it is switched off by default. (https://github.com/MarlinFirmware/Marlin/blob/Development/Marlin/Configuration.h#L351) If we can reduce the current for this instead of turning of, the automatic makes much more sense - and makes G130 useless.

[scotty1024]

Reducing the vref values reduces the current being put into the stepper coils making that current available to go into the extruder heater thus reducing heat up time.

On Jun 11, 2015, at 6:04 AM, uhrheber notifications@github.com wrote:

I wouldn't say it's useless, otherwise makerbot wouldn't use it in their startup code. Here's an example from Makerbot Desktop 3.7:

"G1 X#START_X Y#START_Y Z#START_Z F3300.0 (move to waiting position)", "G130 X20 Y20 A20 B20 (Lower stepper Vrefs while heating)"

After heating up, and before printing, they set the currents back to their default values: "G130 X127 Y127 A127 B127 (Set Stepper motor Vref to defaults)"

I guess that's necessary to prevent overheating strong stepper motors of the bigger Makerbots. But maybe it's just to prevent a 'singing' of the motors.

But another question: What number space should I choose for the Mightyboards in boards.h? I don't want it to collide with something else later.

— Reply to this email directly or view it on GitHub.

[uhrheber]

In this case I'd say we ignore G130, and add two sets of constants in pins.h, in the yet to be written Mightyboard section: One for the default potentiometer value for every axis, and one for the reduced current. If it works, we can try to enable the autoreduction later.

[AnHardt]

"pins.h" is not the best place. The DIGIPOT configuration for the 'Azteeg X3 Pro' resides in Configuration_adv.h line 275+.

[uhrheber]

I would've preferred a complete set of settings for a particular board in one place, but as marlin is a firmware mainly for DIY printers, it makes sense to define only the generic board type in pins.h, and define the tuning values in Configuration.h and Configuration_adv.h. Ok. But what is the difference between #define DIGIPOT_MOTOR_CURRENT and DIGIPOT_I2C_MOTOR_CURRENTS ?

[AnHardt]

I guess it's different taste between the implementors of 'RAMBo' and 'Azteeg X3 Pro'. The one puts in direct values for the digipot, the other one tries to put in Amperes (and fails with this because of the non linearity of the curves)

[uhrheber]

Again: Where do I get a number space for the mightyboards? Should I just define one and submit the change?

[AnHardt]

@uhrheber I can't find a obvious systematic in the numbers. I suggest, not more then 3 digits, not interrupting or ending a consecutive row. Maybe close to a similar board.

[thinkyhead]

There was once some kind of inherent logic to the motherboard numbers, but it has never been very clear to me. Whatever existing board is most closely related to the Mightyboard, choose a number "like" it.

[Wackerbarth]

Ultimately, we need to get away from having any code that depends on the actual number.

[uhrheber]

How about using a binary number, where the digits describe the features of the board?

[TBSliver]

That could cause an issue where two boards have identical features, but different wiring.

Honestly, the best thing to do for this is to just make sure its a unique number. The code already in place means that you dont have to worry about the number at all, all the checks are done using the preprocessor defines - check boards.h and pins.h to see what I mean. If there are ones which depend on the number, then they should be changed to use the MB(BOARD_NAME) function.

Also, configuration which is specific to a motherboard and wont change at all (for example the Mightyboard pin configs for the I2C digipots) should be in the board specific header file, leaving config only in the config files - so number of digipots should be in the board header file, but the values should be in the configuration.h (or configuration_adv.h) file.

Annoyingly, cleverly arranging the config files and board header files into folders would be so useful - unfortunately Arduino doesn't support it... :/

[Wackerbarth]

If we structure our builds expecting the use of the Arduino IDE (at least 1.6.3 or 4), and expect anyone who does not wish to use the IDE to still conform to the file layout, we can somewhat improve the situation. by using variants and libraries rather than trying to place all of the code adjacent to the (useless) .ino file.

[thinkyhead]

@Wackerbarth @TBSliver I went through the tedious process of moving common code into a libraries subfolder at one point, and I seemed to get pretty far, but ultimately it was just too broken and Travis CI definitely didn't like it either. Sure, I could have packaged up parts of Marlin as libraries that users install would need to install into the Sketchbook folder, but that didn't seem really nice to users either. But perhaps things are better now since 1.6.x came along…?

[Wackerbarth]

Yes, things are getting better in 1.6.x (But they also still have a way to go).

These don't need to be USER libraries. They can be vendor(platform) level libraries. So the entire Marlin package can be moved into a library format and the user portion reduces to the .ino fie which calls "main".

Everything in the user space has to be flat because that is all that the IDE knows how to copy. However, the libraries get compiled from their original source. They can reference hierarchal folders of header files, etc.

[AnHardt]

For removing the board-numbers the difficulty is to remove/replace the MB()-macro.

define MB(board) (MOTHERBOARD==BOARD_##board)

The cpp can only compare numbers. To include the pin_*.h files we could find a substitute similar to the language-files, but there are some other locations where we make decisions based on MOTHERBOARD, which i cant find a replacement for.

if MB(RAMPS_13_EFB) || MB(RAMPS_13_EFF) || defined(IS_RAMPS_EFB)

[Wackerbarth]

I was not suggesting that in the underlying implementation numbers would not be used. However, the value of those numbers should be made to be opaque.

On Jun 13, 2015, at 3:17 AM, AnHardt notifications@github.com wrote:

For removing the board-numbers the difficulty is to remove/replace the MB()-macro.

define MB(board) (MOTHERBOARD==BOARD_##board)

No, that macro is just what we DO want. The issue is only in how we define MOTHERBOARD

We compile with gcc -DMOTHERBOARD=RAMPS_13_EFF And we test with

if MB(RAMPS_13_EFF)

No one needs to know, or care, that we have assigned a number to it, or what number it is.

if MB(RAMPS_13_EFB) || MB(RAMPS_13_EFF) || defined(IS_RAMPS_EFB)

Compound expressions such as this are evil.

What you are really testing is some property that is common to these boards. Therefore, the test should reflect the property rather than enumerate boards that have it. Back in the headers we define capabilities which specify that a particular board has certain properties

defined(IS_RAMPS_EFB) and MB(RAMPS_13_EFB) should be the same property. I don’t know why we should have both.

[Wackerbarth]

On Jun 12, 2015, at 9:08 AM, Tom Bloor notifications@github.com wrote: That could cause an issue where two boards have identical features, but different wiring.

That is an issue only because we are not presently using a HAL that recognizes the possibility.

Hopefully, we will be developing such capability in the near future.

One issue that comes up repeatedly in software that “evolves” rather than being “designed” is that the abstractions are missing.

Code gets written on the basis of this or that INSTANCE rather than using a PROPERTY in the code and designating that particular instances have that property.

[AnHardt]

Except a build with make, you already never come in touch with the numbers.

[Wackerbarth]

And, even with make, you should not.

[thinkyhead]

@Wackerbarth The define IS_RAMPS_EFB is just a flag used in a few of the pins_THE_BOARD.h files, so that when they subsequently include pins_RAMPS_13.h they get the correct pin assignments for the fan and heater 1. It is not meant to be used anywhere else, ever. The boards which have the EFB pin assignments are: RAMPS_13_EFB, BOARD_AZTEEG_X3, BOARD_BAM_DICE_DUE, BOARD_FELIX2, and BOARD_MKS_BASE.

[thinkyhead]

the abstractions are missing

Much work needs to be done. The codebase has been in the process of moving in that direction bit by bit, as lots of preliminary work has been needed. Starting over from a completely new base with more use of classes might be a good idea. Maybe it makes more sense to start with Repetier as a base and build on that, since it seems so much better organized.

[Wackerbarth]

"The define IS_RAMPS_EFB" -- Doesn't RAMPS_13_EFB also set it?" You should not need to check for RAMPS_13_EFB here.

[thinkyhead]

The define IS_RAMPS_EFB -- Doesn't RAMPS_13_EFB also set it?

2295 will do that. Or we could add a pins_RAMPS_13_EFB.h file that sets IS_RAMPS_EFB and includes pins_RAMPS_13.h like other RAMPS variant boards do.

[thawkins]

I had a exchange of mail with dan newman about this initiative, dan is the lead on the sailfish firmware. Dan would very much like to see this initiative succeed as it would expand the range of options that MB or MB clone users would have. Currently the only free open software that is available is replicatorG and GPX, which can be awkward. Simplify3d opens things up a lot, but is not free, and Makerbot is activly shooting them selves in the foot with worse and worse releases of MakerWare, whilst activly tring to lockout clone printers.

Dan has however a number of personal commitments that would limit his time to contribute.

I hope that the following comments are taken in the constructive spirit that they are offered and are not viewed as undue critasism, MightyBoards are in a lot of different types of machine with different build components, dan is hoping to ensure that this initative does not make some of the same mistakes that where made on earlier sailfish releases.

It should be noted that sailfish does NOT use gcode, it uses a lowlevel binary format which is sent from a driver on the host, the driver converts the nominal gcode into this lowlevel format before transmission, or storage on sd card. The binary format is preparsed, and has all mm to steps transforms already done in the host computer, for that reason a Marlin port is never going to match sailfish for speed as it has to do far more work at the avr end. Tools like repG and gpx have this conversion process built into them.

From Dan:

The underlying issue with genuine MakerBot Replicator 1's is that they come with a 220 W power supply (9.2A @ 24V). Now, when cold the HBP draws 150W and the two extruders a combined 80W. Do the math. With no "safeguards", heating all three at once sags the voltage so much that the microprocessor resets: game over. And that's without even considering the stepper motors.

To deal with this, firmwares for genuine MakerBots have to first heat the HBP, and then the extruders. Reversing the order is okay; howver, it makes some sense to do the HBP first to allow for heat soak. MBI's firmware (and Sailfish on genuine MBI hardware) enforces this regardless of what the gcode calls for. One could instead tell people to just do this in serial in the gcode.

Now, MBI was trying to keep their options open so they also used digital potentiometers to adjust the stepper motor currents. As I understand it, they were contemplating using a slightly larger, external PSU. (The line they used also has a slightly larger unit but it cost over $100 qty 1 so they didn't use it. Keep in mind, they had already determined that they must use an external, fully enclosed UL & CE certified PSU.) And, of course, they could have just heated things first and then homed/enabled the stepper motors after heating up. But they didn't. (When asked, they had no explanation for that decision; I seem to recall the larger PSU as being 11.5 or 12A.)

The stock stepper motors use current limits of around 0.24A for Z and 0.72A for the remaining four, X, Y, A, B. That's a total of 3.12A or 75W. So, a 12A PSU, had they used it, would still not have enough wattage to heat everything from cold and have the stepper motors at their printing current limits.

But, if you have a bot with the more typical internal 350W PSU, you don't need to drop the currents; you don't need to use serial operation to heat the heaters from cold. However, owing to the digital pots and their default, startup values (64 out of 127), you have to talk to them over the bus and change their values (40 for Z and 118 for all others). The little Botstep stepper driver cards do not have a trim pot or other means of manually setting the default current limits. If you have Botsteps, you do need to use the digipots. Not necessarily in user-supplied gcode though: the firmware could just assert fixed values and be done with it (assuming an appropriately sized PSU or rational gcode mindful of the PSU's power).

But the digipots are there because MBI was keeping their options open as they developed the Replicator 1. Then, they just repeated their use on the Rep 2 line: easier to just "do it" than to stop and re-think it. After all, thinking can be harmful.

Vocab: Botsteps = stepsticks/pololo stepper plugin drivers, not the same size or format, but very simular concept.

From thawkins

Many of the MB clones have different psu's in them as outlined above, the FlashForges are 350W, but things like the ctc, wahoo, monoprice machines which are close clones of the MakerBot rep 1 dual have smaller PSU'S. to make matters worse some of them have unsafe heatbed resistances that if turned on full would overload the psu, the sailfish firmware uses low frequencey pwm to ensure the average power disipated is below the limits. To this end its important that the firmware stays up as its often the only difference between correct operation and a burnt out motherboard. Note also that some mightyboards have 1280's in them others have 2560's

More from dan on this subject:

Two examples of portability trumping safety are the watch dog timer (WDT) and the use of software PWM (soft PWM): 1. Marlin by default has the WDT disabled. If you pull the Repetier sources, the WDT is enabled out-of-the-repo. However, every config I've built with Repetier's online config generator has the WDT disabled. That may not be true for all Repetier configs so generated: I only have four data points. What's the big deal? I reckon you know: the WDT resets the processor should it hang and not periodically reset the timer. Marlin back a few years ago used to have it enabled but then the code went through some gyrations and these days it's turned off by default. I suspect that on some bot builds there were issues with it triggering when nothing was wrong other than the non-interrupt level code which periodically reset the timer was not getting any clock cycles. But having that sort of failsafe is just one of several things that can be done to improve the overall safety of the bot. Especially bots with firmware which also do2. 1. Soft PWM. It's far easier to do soft PWM. For different AVR pinouts you don't have to worry about whether heaters are on PWM capable pins or not or if they are scattered across different timers, thus using more valuable timers than you care to use. But, with soft PWM under firmware control you have a heater on 100% for brief instances. And if the firmware hangs during one of those instances, then it's locked on 100%. Fine if you have a functioning WDT -- worst case on an AVR is that it's on 100% for 8 seconds. But, if you don't have the WDT enabled, well you get the lockups-with-heaters-on that we see reported from time to time. With hardware PWM, once the print is underway typical PID-controlled outputs are around 15 - 30% (assuming sane PID tuning). And the PWM hardware continues to function even when the firmware is hung. Sure the heater is going on 100% for brief instances, but it's all under hardware control and locked up firmware cannot upset that: the harware continues to turn it on/off with a, say, 30% duty cycle. So, in the event of locked-up-firmware and no WDT, hardware PWM will generally be more safe since once a print is well underway the duty cycles tend to be modest, well below 50%. But doing hardware PWM is less portable. (And given some of the terrible pin assignments I've seen on some "reprap" electronics, next to impossible given you need some timers for other activities.)

I sure wish firmwares would do a release focused on safety.

A. Firmware always turns off all heaters at startup. (I think they all do this already.)

B. Get the WDT always enabled and working. Use the max. 8s timeout -- it's adequate and gives maximal leeway for builds that have slow initialization times.

C. Nice to have, but not realistic for firmwares too far down the maximize portability path: hardware PWM.

D. Inactivity timers on heaters to shut them off if left on for more than some prescribed time period with no new commands received (or no new do-something-other-than-report-your-temp-and-status commands). Makerbot firmwares use 30 minutes, but there's nothing special about that value.

E. Code to detect heater failure cases. MBI's firmware has some of this, but it's by no means something to brag about. I'd love to see a larger group hash out some sound algorithms for accomplishing this.

On the electronics side there's things which should be done as well

F. Ensure that the heater electonics defaults to an asserted OFF state. The old Gen 3 RepRap electronics didn't do that -- things floated and you could end up with a heater on until the firmware started and turned it off. Since it was a problem when loading new firmware and bad firmware loads, a modified bootloader was adopted which asserted the heaters off.

G. Thermal safety cutoffs of some flavor. MBI tried that with the Gen 4 RepRap electronics but their design had a number of flaws. See, e.g., http://softsolder.com/2011/06/07/thing-o-matic-thermal-runaway/. One of the recent Kickstarted 3D printers is putting purpose-built thermal fuses into each extruder. 3DS does likewise. (It's hard to use Joe Random thermal fuses since they are poorly spec'd and you really need to know their behavior when at, say, 200C for 12 hours.) •••

[thinkyhead]

Many good observations and suggestions. We have much to do.

you have to talk to them over the bus and change their values (40 for Z and 118 for all others)

There is DIGIPOT support in Marlin, so I assume we just have to follow your (Dan's) guidance and set the motor current at startup for Mightyboard.

Note also that some mightyboards have 1280's in them others have 2560's

We would probably support them as two separate board IDs (BOARD_MIGHTYBOARD_1280, BOARD_MIGHTYBOARD_2560) sharing a common pins file.

hardware PWM

It would be nice if we could abstract all the PWM-capable pins, whether hardware or software, into a common class, and let the low-level code decide which to use. Currently we don't have a great abstraction layer between pins and their functions, just direct assignments. So, more abstraction/indirection may help make this possible.

Inactivity timers on heaters

We have them for steppers, so why not heaters? Good question!

Code to detect heater failure cases

There has been a lot of focus on the thermal protection in recent weeks, making it enabled by default for subsequent releases and attempting to improve the algorithms. The new code still gives some false-positives, but it's about 90% there. Enabling WDT by default should probably be included as part of that initiative.

Firmware always turns off all heaters at startup.

As far as the software level goes, Marlin only sets the heater pins to OUTPUT mode in the temperature manager tp_init(). It doesn't call disable_all_heaters afterward in setup(), but that's easy enough to add…

Ensure that the heater electronics defaults to an asserted OFF state

I'm not sure how feasible a modified bootloader would be as a part of Marlin, given the number of supported boards. I presume that most boards today start up with all their pins in some known state, PWM disabled, etc., until the firmware starts up. So, which boards will truly need it?