Reprap Arduino Due Shield project - looking for helping eyes.

I don't think anyone is working on a shield for Arduino Due yet. So I am making one - so far I made the schematic, and placed everything on a 4" * 3.2" board and started routing.

Schematic Here: [docs.google.com]

There are no big deals with RAMPS, minor but workaround-able issues:
[*] The transistor stands in the air, it runs too hot then I would like it to be.
[*] I suspects the connector couldn't handle 15A nicely thats heated bed used.
[*] The transistor picked does not work well on 3.3V. It couldn't open the gate wide enough.
[*] Too few PWM output
[*] Polulu and A4988 is hard to source in my part of the world.

My design goal is - update and unveiled the power of SAM3X, which boils down to
[*] Potentially driving a dot matrix LCD (ST7565P, 128*64), or HD 47780
[*] Providing 5 output PWM: bonus - it connects to the PWM pins of the Due. (1*15A, 4*4A limited by connector and heatsink area)
[*] SD card support (Micro SD actually)

Unfortunately - Arduino didn't expose the high speed SD card interface. Nor the hardware Ethernet MAC interface.

Other features:
[*] Accept standard PSU for power. And CPU 4p pin for high current operation.
[*] 5V Standby - software power on/off.
[*] Speaker on PWM pin (Reminds me DOS-era)
[*] On-board DRV8811 - Tune-able Decay and VRef.
[*] Size - 4" * 3.2". As wide as the Arduino, but taller.

Comments, bug reports are welcome.

---

Plus, I bet no one is start working on a firmware for Due either.

As a programmer, I am too upset with the software architecture of Marlin. No offense to all the contributors, it works great and it gets the job done and more. With ARM, I think we have got some spare CPU cycles to make things neater. I am planning to put some sort of lightweight realtime OS inside (just for cooperate task management, nothing more). Then refactor the stuff instead of everything in a big Marlin.cpp or Pins.h.
The next thing I am going to build is a delta robot (Rostock Mini) - so I wish to put the calculation formula on-board also.

That's said - I might be too busy to complete all these in a time-frame that I am satisfied with.

If someone is starting a similar project, please let me know - maybe we could work something out together.

Sure, this has been discussed before, I have been working on it for a while, progressing slowly. Search for "RAMPS for Due". Also [reprap.org]

I am not getting the impression people are very interested in ARM/Due yet, people are still squeezing more life out of AVR.

I agree about porting firmware, it really is an opportunity to redesign from the ground up. Emulating Arduino-AVR functions on an ARM is a quick way to get firmware running, but is a fairly ugly kludge.

Wow. My google-fu must be not good enough, didn't find this page before! There are some philosophy differences between our designs, which is good - diversity is good. Good job.
Mine is trying to dump all the legacy 5V - actually it does, and not strive to keeping pin-out/physical compatibility with RAMPS, your does.

There are so many cheap ARM board out there - usually based on STM32, some are even cheaper than the Arduino Mega. However there are no de-facto standard design and hard to gain a critical mass. And now we have Arduino Due, albeit a bad design IMHO (No Ethernet, No high speed SD. I would wish for a Ethernet than JTag). AVR got the jobs done, but it is almost touching the limit. With ARM I hope a lot of opportunities - can't wait to see that come.

Yeah, I was trying to keep close to RAMPS compatibility with minimal changes, but I now realise there will be too many small differences to make it directly compatible. Given that the software will need major changes it is probably not much point. The RAMPS board is pretty crammed, it might be best taking a fresh approach, but I think I will try to keep it close as possible to the original. I have some more radical ideas but they would be best explored in a new project

You are right, the ARM arena is lacking a core design. It seems every week a colleague comes round with a new ARM announcement and says "hey have you seen this!" I've got a box full of dev boards that I have hardly had time to plug in.

It would have been great if Due had brought out the Ethernet. I've been looking at the mbed platform, it is showing more promise as a cross platform environment.

I know of a number of companies who are building boards that break out the SAM's on-chip Ethernet, and use one of the many unused on-chip SPI buses. Some of these sit over the chip itself (and have shield pass-thru so you can put shields on top of them), and some are replacements for the Due entirely (eg: using the on-board components yet keeping the Due shield pin out).

I've posted about many issues with the RAMPS design that need to be changed (many of these are changed on the RAMBo all-in-one design, but not all) that IMO are definitely worth having a look at. My specific pet peeve are the PTC fuses (they're useless and actually dangerous, especially when over their voltage and/or current range). The layout of some of the connectors can be an annoyance too (eg: just slightly too small clearance between some of them, such between Power and D8), and the cramped board style.

Thanks for your input, Cefiar. I should spend some time reading your historical post and learn from them.
It would be even nicer if you could sum them up for me again =)

So instead of PTC, you prefer good-old-day fuses, right?

I'd link to the forum post I recently posted in the RAMPS sub-forum about 24 Operation (look for a thread called 24V with Ramps 1.4 questions), as the forum thinks that this post is spam when I try.

And yes, I prefer either M205 or car automotive blade fuses. They're common enough and do the job. The blade fuses make particular sense as they're easier and easier to get hold of, and 15A is a fairly common value (which is good for a 12V PCB heated bed - as they tend to vary in current from 10A to about 13A due to track width tolerances). Another advantage is that you can remove the fuse and connect an Ammeter in place of the fuse (at least, as long as your multimeter can support the current). Provides a good diagnostic tool.

Other things are:

Connectors: Due to RAMPS cramped design, the connectors are all over the board, instead of purely at the edges. This is particularly true of the stepper motor connectors. Also, they're not locking type connectors, and no provision was made so you could use any sort of locking connector on the PCB (mainly by adding extra space around the connectors - which there isn't room for as the designed is cramped. Another example is the D8 and power connectors being too close, which means you can't use the Phoenix-style screw connectors used on the power on the D8/9/10 connectors as well, without chopping a piece out of one of the connectors.

Voltage inputs: As per RAMBo, it makes sense to have 3 voltage inputs. One that supplies the Heated Bed output, one that supplies all the other MOSFET outputs (eg: fans & nozzle), and one that supplies all the Motor driver boards. This way, you can run 12V on your hot end/fans and 24V on your motors and heated bed easily, or even have different PSU's for all 3.

Hope this helps.

Thanks for your input. It certainly helps.

I strongly agree with you about the connectors. Even with a hard made mega shield that I am using now I am using the phoneix-screw connector, or for all the extruder, sensor connections. (I use some other motor drivers module). Stick the screw driver on the PCB just for connecting/disconnecting is such an troublesome job. I don't understand why RAMPS couldn't make D8/D9/D10 a phoneix-screw capable, it doesn't take much more space than what it is currently using.
Last time I check the small size phoneix-screw driver is only capable to deliver 10A. In fact, I was using one for heated bed but get way too hot. I am looking for fitting a Mini Fit Jr (CPU/PCI-e style) plug for heated bed instead.

I see your point about pluggable and how easy an M205/automative fuses could be obtained. Though they have a large foot-print. I am going with Littelfuse 1808 SMD holder.

Seperated voltage - agree. I have the power input for logic, and Extruder/PWM/Motor input seperated. Can't do more with the cramped PCB though.

The main issue with RAMBo is that - it's quite of expensive to prototype/fab a 4-layer PCB. =P

Im also interested in this project.

I also believe having the stepper motor drivers on the board is not a good idea, I'm building a combined CNC/3d printer, and need a lot more current support, potentially up to 3 amps per winding. If the board can output buffered enable, step, direction, and speed lines for each axis, then the user is at liberty to chose whatever driver technology they want.

Speed lines are generally not used at the moment on most systems, but would allow dynamic alteration of the micro stepping resolution selectors. Potential allowing fast gross movements beyond what can be supported with standard micro controllers with a fixed micro-stepping resolution. I have been experimenting with this by hacking the accelstepper lib on a setup that has a bigeasydriver connected with its ms0-ms3 lines connected to digital outputs. Im using a 10 wire connector and plug to connect the bigeasydriver to a arduinoMEGA proto shield.

In fact without the drivers i suspect its possible to get everything onto a mega shield sized board with edge mounted connectors.

Re use of automotive parts, yes, more of that please, i live in a part of the world (philippines) where even normally common parts are extremely hard to find, and ordering from abroad can take anywhere between 4-8 weeks. Automotive parts are relatively easy to find, especially US parts.

Another difficulty (not directly relevant to electronics) , is it hard to get metric parts, like the US we use imperial/American standards, but unlike the US, we don't have the specialist or easy online sources that can provide metric parts when we need them.

I thought mainland US and UK is the only part of the world still using imperial widely, apparently I am wrong.

It's correct that without the drivers on board, everything will fit much more easily. However, my goal is to have them onboard to handle my scenario (and most common scenarios I believe).
That said - it's a shield, so anyone could grab the step/dir signals and every other pins directly on the headers. If space's allowed, I could make step/dir available on a seperated headers - I am still routing it and can't say for sure at this stage.

My vote for onboard drivers...

I think having on-board drivers (or an option for on-board drivers) is a great idea for "the masses". There will always be certain edge cases (as identified above) where the onboard drivers will not work.

I think the Smoothie board handles this well: there are onboard drivers but before the driver there is a breakout for step/direction/enable if you want to use an external driver (or if you blow the onboard driver). This way you can have a mass produced board with the edge cases being covered with plugs (only disadvantage is you need to pay for something you're not using)

I have a smoothie board in the mail to try out. The biggest disadvantage (IMO) is the 4 axis limit of onboard controllers.

Also, im not an expert, but what is the difference between SAM3X8E (Arduino) and LPC1769 (Smoothie)? I see both are cortex-m3 and I undertand that smoothie firmware was not a port, but a scratch-write.

[www.kickstarter.com]

Cefiar Wrote:
-------------------------------------------------------
>
> Connectors: Due to RAMPS cramped design, the
> connectors are all over the board, instead of
> purely at the edges. This is particularly true of
> the stepper motor connectors. Also, they're not
> locking type connectors, and no provision was made
> so you could use any sort of locking connector on
> the PCB (mainly by adding extra space around the
> connectors - which there isn't room for as the
> designed is cramped. Another example is the D8 and
> power connectors being too close, which means you
> can't use the Phoenix-style screw connectors used
> on the power on the D8/9/10 connectors as well,
> without chopping a piece out of one of the
> connectors.
>
> Voltage inputs: As per RAMBo, it makes sense to
> have 3 voltage inputs. One that supplies the
> Heated Bed output, one that supplies all the other
> MOSFET outputs (eg: fans & nozzle), and one that
> supplies all the Motor driver boards. This way,
> you can run 12V on your hot end/fans and 24V on
> your motors and heated bed easily, or even have
> different PSU's for all 3.

With UDOO, now on the horizon, I am looking again at RAMPS/Due. The RAMPS is cramped connector wise because it fits the layout "inside" the Arduino header pins. RAMBO is not limited by Arduino layout, plus has a larger board area.

It is difficult to route power tracks through the header pins, so they would need to be routed "outside" of the Arduino footprint. RAMPS extends the shield a small amount at the lower side. I think for UDOO this would overlap with some of its connectors, but I guess which ever way the board is extended it will cause problems for some people. My preference would be to extend the board at the upper side.

However, the requirements to add more connectors and at same time improve the layout appear incompatible, unless a much larger board is used. It would be possible to use surface mount headers, thus freeing up board space on the top, but I am wary of using SMT headers mainly because of mechanical strength. It is all to easy to rip pads off the board when de-mating boards.

If there are ways to improve the layout while retaining the Arduino footprint, I would be glad to hear them. I will try to post some possible designs soon.

I will also update the reprap wiki to capture the suggestions that have been made for improving RAMPS, and also provide links to the various designs that people are working on.

The attached image shows what I have currently, it is very similar to existing RAMPS 1.4.

@bobc

Maybe move to a 4-layer board with power and ground planes on the inner two layers? That should make it easier to expand the board footprint without interfering with the edge interface pins.

Of course that means moving to another software package or a paid version of Eagle.

Also, your board looks great!

---

- akhlut

Just remember - Iterate, Iterate, Iterate!

[myhomelessmind.blogspot.com]

he was using Kicad all along

4 layer is an option I could use with Kicad, but I would like to avoid it because it bumps up the cost significantly. With iteadstudio etc, it is cheaper to double the board area than go to 4 layers.

I don't think 4 layer helps me to route power traces (e.g. 1A/1B etc from stepper drivers) between the through hole pads to get the connectors outside the Arduino headers. Those headers create a fence which is hard to get through, which is I guess why RAMPS ended up like it is. They did manage to pack a lot of functions in there, unlike those Arduino shields which just have single stepper driver and nothing else.

Welcome to designer's dilema. That is taking decisions without being sure they are good. And never receiving confirmations that they were right ones, even later on. Doesnt feel so nice to be inside of that. It starts with you must ask yourself why u want this. Thats a key thing in how you choose to do it and how it will look like. You really need to figure this out before doing the board, very much depends on it. Including how happy you will be with the result.

RAMPS was made like that by a company which sold printers, and it was easier both for them and for users to have it like that. That was their motivation. If you plan on effectively doing a commercial product like that its probably similar. If you want it just for yourself or for a fairly small number of ppls, thats totally different, can go with diy and routing and wiring, and ofc is going to be hugely different.

Scrap anything from your mind and try choice like this. On one hand you have 5 stepper drivers, and on the other you have the required pinout. What do you choose: a) squeeze the stepper drivers on top of the pins, or use wires to connect. Now if you really start to think, does it really make sense to have the drivers sit on top of pins, or they are better of aside with some wires going to them? This kinda depends on what you want it for. Thats your answer to give to yourself.

If you ask me, i think stepper drivers have no business being there in the first place, they depend on the machine parameters, e.g. uC is capable to control 5kg mendel or 500kg milling machine, so the motor driver depend on physics and not uC, hence shouldnt sit on the shield. But again, thats just me and thats my answer i gave to myself, you need yours.

Imho, shields are highly overrated. And firmware developers have too many shields pinouts to sort out, and too messy.

Oh and i would change the 2N7002, coz i think its not a good choice for logic, smells of analog. I would check for a logic level one (@parametric search try Vds=16-20v).

That's useful feedback, thanks

(As an aside, Kicad doesn't support padstacks yet, so pads are replicated on all layers, which explains routing difficulty. Kicad is getting support from CERN, so hopefully will see lots of improvements in future)

There are a number of reasons for making a shield, some of which would not be my first choice, but RAMPS does remain popular. There are also people asking for "RAMPS for Due", so there is at least some interest. Personally my interest is to move to an ARM platform, and Arduino Due is about the only the platform likely to become a de facto standard, with the possible exception of mbed.

As for project goals, it is to create an open source design that is a balance of DIY friendly and commercial friendly, should anyone be interested in doing that.

I am pretty much a DIY and hands-on kind of person and plenty of bruises. But about board making, routing, component choice, etc, i find the commercial aspects and DIY to be irreconciliable. Its either DIY or the other, in pretty much every single aspect. I think its a line that needs to be drawn somewhere.

To make smth DIY, i think about the components i have or the ones i can actually buy, that can turn out quite limited. This is why you changed TXS10.. to 4050 isnt it - and that will happen much more. In fact i look for availability first then i check datasheets, otherwise i can spend half a day to find for 10 specific IC that are great and from them i can find none available to me (that still happens alot). And i would think about 3 different modes to use same thing even with different components and packages footprints. And i would go for single sided (if possible without big compromises).

These are just a few fundamental choices which affects everything, and which are totally opposite in a commercial board. Hence this is why i mean you need to decide, if you skip this step then you still want something thats needs to fullfill too many expectations, and wont have a chance to be happy with the result.

Edited 1 time(s). Last edit at 04/21/2013 09:17AM by NoobMan.

Oh and lets not forget about board size, the commercial is interested to have it small as it pays for it, the DIY the extra board space costs next to nothing and so diy is better off with something big enough to fit everything with big clearance and having extra space.

Anyway, you see all i said is coz i dont think you are stuck at routing, i think you need to decide which way to go between the above.

Btw, I am also trying to make and document some generic electronics, also in kicad, but i took the full DIY route, and this kinda makes many decisions to fall back to this one. At routing for example i have something like like 1.5mm min track width and 0.5mm min clearance, and many other choices fall back to this.

Ok, I have been playing with the layout a little, and I think I have something interesting. I've added a sixth stepper driver (color printing!) and an extra FET (will need another thermistor). Board size is extended slightly, most connectors are nearer the edge. I need to reposition all the aux headers (does anyone really use servos with RAMPS?)

ETA: also added third power input, and moved microstep jumpers out from under stepper drivers.


RAMPS-FD-v3 by donotdespisethesnake, on Flickr

Btw, the white outline is 10cm x 10cm, which is limit for cheap boards. I know, another arbitrary constraint

Couple of things to mention : this new board should be compatible with both Arduino Mega R3 and Due, although I don't expect people to rush and buy this board, it should run with Mega and later ppl can upgrade to Due.

If people want to do the reverse, i.e re-use RAMPS 1.4 boards with Due, then the RAMPS-RIB interface board (or similar) will be able to do that as near as possible. Therefore I think it is worth expanding the envelope a bit with RAMPDS-FD, even if it is less of a straight replacement for RAMPS 1.4.

Edited 1 time(s). Last edit at 04/21/2013 03:54PM by bobc.

bobc Wrote:
-------------------------------------------------------
[...]
> (As an aside, Kicad doesn't support padstacks yet,
> so pads are replicated on all layers, which
> explains routing difficulty. Kicad is getting
> support from CERN, so hopefully will see lots of
> improvements in future)

Try this to see if helps: with mouse over pad, press E to edit, at Clarification choose the pad name, then at layers change from ALL to only where you want it, you can even select None.

Edited 1 time(s). Last edit at 04/21/2013 09:41PM by NoobMan.

Bobc,

That's the sort of layout I was thinking about.

Perhaps expand the top side of the board so that there is more room for the FET's and that edge connector? Additional reasons below:

I was wondering if we could move all the extra connectors to the middle of the board, parallel to the large expansion connector on the back? This way, people who want them could put ribbon cable on them (since they're 3.3v signals, not stepper voltage) and run it flat over the middle of the board to the expansion connector (ie: out the right side). This means they don't foul the airflow too much, which was part of my issue with the position of the motor cables on the standard RAMPS. If you need more space in the middle to put in those extra connectors, you should be able to push the top 3 stepper drivers upwards a bit to give you some more room.

Something you could also try is putting the end-stop and thermistor outputs in the top right corner of the (larger board), above the expansion header? With the board being larger there's no reason to not use that space, and if it gets the commonly used connectors out of the middle, it will definitely make connection easier. You may need to move the stepper row slightly to the left to get the traces through the gap. Apart from being the most commonly connected parts, they're the ones that, due to pin config, are the most troublesome to avoid.

Other things worth noting:

You've put Z on the bottom right. Does it need to be there? Could it be at the top? If so, could you put more room between the pair of connectors, so that locking connectors can be used? This might remove some of the excess size on the bottom edge, which means it'd would fit in better with something like an UDOO, especially if we can make the bottom right corner dead space and cut it off the board entirely (makes room for the UDOO LVDS & SATA connectors).

Are the XYZ steppers all on the same port on the Arduino Mega/Due? This might be a hard push (routing wise), but specifically on the Mega it means you could probably drive this using the Grbl firmware easily (from memory, it is really hard to get Grbl to use 3 axes that aren't all on the same port, due to the way the code was written to use AVR port writes). It also means that with something like a Mega, when you're moving 3 axes at once (eg: Rostock/Delta requires all 3 motors to move at once, unlike a traditional XY platform machine like the Mendel variants), you want them all moved at the same time, rather than one lagging slightly behind the other two (might only be 2-3 clock cycles - tho depends on the code). Even the Due has "ports" like the AVR's do, but I don't know if they're even remotely the same arrangement, or how much an effect it would have. Will have to sit down and see if we can find some that cross over or if it's necessary on the Due.

Anyway, just my 5 cents (I don't use 2 cents, they're uneconomically viable).

Thanks for your 5c, I stopped using small coinage too

Here is latest iteration:

RAMPS-FD-v3_2 by donotdespisethesnake, on Flickr

Here is a reverse view

RAMPS-FD-v3_2-rev by donotdespisethesnake, on Flickr


I think I got most or all of your suggestions. X Y and Z are on same port, both Mega and Due. I'm not sure Z really needs two connectors, but there is probably space for two. There is still a bit of jiggle room, the board could be extended to add a 5th FET, or alternatively trimmed back slightly. Possibly there is excess space at the centre, but I still have some components to place.

I added 3 blade type fuses, don't know if that is overkill.

This version is nearly compatible with Mega, with the exception of SPI which appears to be on completely different pins. The simplest thing may be to add a second SPI connector.

I also have an idea to create an expansion board which could add 4 stepper/extruders

That looks great! That bottom edge should give enough room to get access to connectors on the UDOO.

I personally don't think you need two board connectors for Z (you can run both cables into a connector, or make up a Y-cable), but that's just my opinion.

FIrmware-wise, you might want to take a look at Adrian Bowyer's firmware developments: [github.com]

droftarts: Thanks for letting us know about that.

Even if it's not the firmware that gets used in the long run, that could prove very useful for testing in the short term to ensure that everything works appropriately.

bobc: I'm assuming that the 2x4 connector up in the top right corner is for 4 thermistors?

Something we might want to consider here is putting a 1N746A (3.3V, 0.5W Zener diode) across each. This will limit the voltage into the Due to a max of 3.3v, if the hot end voltage comes in contact with the thermistor. I just checked, and the diodes are about 4 cents AUD each. To protect the Zener & the Due from long-term over-voltage, we should probably put a 100-150mA fuse (0 ohm resistor style - I've seen these for about 35 cents AUD) in series with the thermistor (between the Due input/pull-up resistor/filter cap end and the thermistor input). This way, if the thermistor input does short to a >3.3V source somehow, the 0 ohm fuse will blow if the current dissipated by the Zener is too high, protecting the Due. Another alternative is to put a small resistance in, that will dissipate that voltage, but that is not as good a solution, as it will definitely affect the reading out of the thermistor (though only slightly), and may not provide protection against larger voltages.

There are also PTC fuses like the Bourns MF-R005 (100mA trip current), which "may" be useful. As I've stated I don't trust PTC fuses much, but at least these are rated to 60V (well above any voltage we'd expect on the input). They are about 41 cents each AUD (cheapest I've seen). I don't know if the PTC will trip fast enough (5s to trip at 100mA, less at higher currents). It also adds 10 Ohms into the circuit, which is unlikely to be an issue but you never know. You can see the spec sheet at: [www.farnell.com] (top entry).

All up, for 4 thermistor inputs, we're adding a total cost of about $1.50-2.00 AUD in components to the board with 0 ohm or PTC fuses. Either way, a worthwhile cost for protection IMO (assuming it will work).

That said, I haven't compared this cost against how much it would add if we were to use Thermocouple inputs instead, though I assume it would cost more, simply for the support circuity. I also don't know if that would provide any protection from higher voltages reaching the Due. If a chip is involved then I suspect it might take the burden, rather than the Due, but even then it depends how the chip will fail.

Notes:
1. Since the Zener 3.3V, 0.5W, this gives 151mA at full rating. So that's the max we can expect the Zener to bypass if there is a fault. Outside of faults, we need to make sure the thermistor itself doesn't blow the fuse in normal operation. The thermistor will probably get down to 100 ohms at 300 Deg C (the EPCOS axial ones are about this from the spec sheet). Add in the minimum voltage divider of 1k (RAMPS is usually 4.7K, but 1K gives better resolution at higher temps, so some people may change it), and you get 1.1k, across 3.3V, which is 3mA of current pulled through the fuse. Even if we assume the thermistor input shorts to ground, that still leaves 1K in circuit, which is 3.3mA - well within the 100-150mA rating of the fuse.
2. I chose the 3.3V Zener entirely on it's 3.3V rating only. If the Due can take slightly higher voltages, then perhaps we should use a 3.6V or 3.9V Zener to avoid the Zener tripping too close to 3.3V (eg: due to tolerances). I also have no idea if having the Zener in parallel with the input will skew the results from the thermistor at all, due to any extra current it might pass below the threshold voltage.

Edited 1 time(s). Last edit at 04/26/2013 09:36PM by Cefiar.

droftarts Wrote:
-------------------------------------------------------
> FIrmware-wise, you might want to take a look at
> Adrian Bowyer's firmware developments:
> [github.com]

That looks great! When will it be ready?

Taking a clean start is probably a good idea, it would be good to have some firmware that is well abstracted, portable and easily configurable. I'm not sure that this RRP firmware goes in that direction, but at least it is a start. Smoothieware is interesting, but I think too tied in to a specific platform.

Should we infer that RRP are working on a Due based controller? It would be useful to know more of the plans at RRP, otherwise it is hard to factor in what they are up to.

Talking about fuses, sry for looking like im trying to defuse you.

Classic fuses arent that good either, even "ultrafast" are actually slow ones and have times much longer than whats needed, nowadays ICs are so fast that IC will burn first, and follow on that failure mode if its on short, then the fuse will burn after, if it will burn - at all.

PTC fuses are less fuses and more of current limiters of long time, can work at overcurrent for hours or half a day or sometimes more. It can effectively single handed control a short for quite some duration. PTC is the fuse you want to have in your airplane.

Zenner is rather useless there. The short that could happen on heater block is with +12v direct from psu, and clearly zenner isnt up to the job, probably will burn out faster than a fuse. Actually lets say thermistor has 2 legs and there is a 50% chance the short will go to adc terminal and otherwise will go the the ground thermistor leg. In last case is not too much of a stretch to think that pcb tracks wont handle so much instant and will raise the gnd potential and at least some of the current will choose to go from raised gnd troguh the protection zenner because this time zenner is forward biased into the uC!

To reliably clamp the voltage of a 40Amps smps psu from 12v to 3.3v, thats something better not try. Huge power clamp. Not flower-power zenner. Even for 100-500 miliseconds thats enough to reliably burn some fuse, you would need a big power device with a huge radiator. Pointless to say its not the way to do it, and not the place either. Big clamps and stuff of sorts you do it at power input, not far away into the board. And there is something else to think about. To what end? If you sink that much current you will burn the pcb tracks. A short like that isnt an instant impulse transient, its classic meltdown short, keeps coming and cant dissipate easily. There is nothing on either pcb that would deal with it or sink it. You can divert it instead, yes, but still it will burn anything else it meets, thermistor leg, pcb tracks, etc. Bottom line, the system is toasted, either way.

You can protect against low currents at 5v. But direct V+ to gnd short of a high current psu, thats a different league. You could like add electronic fuse circuits on all thermistor legs, but thats a whole lot of complication and will be a board with lots of heatsinks and probably bigger than the shield itself. Not worth as trouble/gain ratio.

So please do it like the arduino guys and rest of world did it: give fair warning - and cross your fingers, hope for the best.
And thats it. If you think it through all in all, thats a very good solution, really

Edited 1 time(s). Last edit at 04/27/2013 05:20AM by NoobMan.