RAMPS for Due!

Cefiar Wrote:
-------------------------------------------------------
> FWIW: I personally prefer the 5.08" pitch
> connectors, but that's because I use the pull
> apart style connectors that are specced for the
> default RAMPS power input on my outputs too.
> Having connectors with the easy disconnect setup
> (for me) works well, and means removing the board
> from the printer doesn't require screw/unscrewing
> the cables (which leads to eventual failure of the
> screw part of the connector, especially the
> cheaper ones).

Yes! The 3.5mm pitch connectors also have plug and socket too e.g. [uk.rs-online.com] They seem to combine best features of the 5.08 connectors with a decent size reduction.

FWIW they are used on the Smoothieboard , though I wouldn't use them for heated bed or power inputs.

ETA: I think I am quite close to freezing the design, otherwise it will keep growing forever! There can always be a Rev 2...

Edited 1 time(s). Last edit at 09/22/2013 08:48PM by bobc.

Re: 3.5mm sockets: Good good. That neatly addresses my concerns.

Re: Freezing the design: I'm happy with what we've got at the moment, from the schematic view. I haven't looked at the board at all yet, but I don't think that'll be much of an issue.

That said, you added 2 more FET drive outputs. Are you planning to put them on the same E-Stop isolation circuitry that you put the rest of the FETs on? Just asking as I've not seen that in the schematics I saw, and I know you have 2 more free resistors/HC125 drivers available.

Also some more notes:

1. You have 10 Ohm resistors on the gates of Q205 and Q204 (fed by FET4_BUF and D10_BUF), while you don't have them on Q501 and Q502 (D8_BUF and D9_BUF). Also if you do put Q901 and Q902 (D11-FET5 and D2-FET6) behind the spare E-Stop buffers, you probably want to make sure they're fed the same way (also watch the output bias from the buffers for these - ie: are they to be active high or active low drive, and just what are they planned to drive - a load or another FET?).

2. RP1, RP2 and RP3 don't seem to have values. I'd assume they're 100K or some common value, but it'd be good to have it listed.

Cefiar Wrote:
-------------------------------------------------------
> That said, you added 2 more FET drive outputs. Are
> you planning to put them on the same E-Stop
> isolation circuitry that you put the rest of the
> FETs on? Just asking as I've not seen that in the
> schematics I saw, and I know you have 2 more free
> resistors/HC125 drivers available.

There are two spare drivers. I was thinking they would be used for cooling fans, but they could be used to control an external relay for a heater or motor, so it seems logical to include them in the e-stop.

Cefiar Wrote:
-------------------------------------------------------
> Also some more notes:
>
> 1. You have 10 Ohm resistors on the gates of Q205
> and Q204 (fed by FET4_BUF and D10_BUF), while you
> don't have them on Q501 and Q502 (D8_BUF and
> D9_BUF). Also if you do put Q901 and Q902
> (D11-FET5 and D2-FET6) behind the spare E-Stop
> buffers, you probably want to make sure they're
> fed the same way (also watch the output bias from
> the buffers for these - ie: are they to be active
> high or active low drive, and just what are they
> planned to drive - a load or another FET?).

Plan was to use them for cooling fans, led etc e.g. 12V 150ma. I have added them following the same pattern as other mosfets, except they will be active high.


> 2. RP1, RP2 and RP3 don't seem to have values.
> I'd assume they're 100K or some common value, but
> it'd be good to have it listed.

Fixed!

Nice. I just tried to pull from your git and it said it was up to date, so I'm guessing you've not pushed yet.

Did you address the resistor stuff around all the FETs (the inconsistency with the inline gate resistors)?

I think I fixed everything including gate resistors.

I've just pushed latest version, update schematic, pdf, board layout, PCB render.

The autorouter is now struggling a bit

I realised that the SPI connector IS in the same place on the Mega and Due, I was looking at a clone board. Although I liked my previous scheme, it would duplicate connections, so now there is one connector with SPI. Unfortunately the Slave Select signal is on different pins. On the Mega the SPI signals are available in two places, so it doesn't gain much.

So I am hoping it will work OK with Mega, although I haven't tried that yet. I had to abandon the idea of keeping connectors compatible with RAMPS, so accessories like LCD panels will need rework. There is one issue, which is that the heater connectors will short out on the USB connector without some insulation in place.

Now I think it is a question of jiggling things around to get a nice board layout, although there are a few tempting gaps...

There may be some opportunities to reduce BOM cost and number of unique parts.


RAMPS-FD by donotdespisethesnake, on Flickr

The USB on the Mega is a pain anyway. I've had ordinary RAMPS boards short to that connector (scratched the protective layer) and cause all sorts of weird issues, as it's almost exactly at board height. If people wanted to use it with a Mega they could always put longer pins on and not populate the SPI connector (which isn't needed for the Mega).

Aux3 is probably the killer for board compatibility since it's:
1. Got 2 extra pins.
2. The pins remaining 8 pins are now in a different order.

While E1 and E2 use pins the average LCD/encoder use, there are a number of spare pins there that might be usable to get the same effect.

I am sure adapter cables could be made. The issue will be the SD card, as too long a cable to the SD card leads to data corruption issues.

Hmm, I think I can do some jiggling to improve compatibility. Hopefully some RAMPS accessories can be used without modification on Mega/RAMPS-FD at least.

AFAIK none are 3.3V compatible, so I will design some 3/5V compatible versions which can work with Mega or Due. In some cases an adapter card could be used, but things which depend exactly on the RAMPS layout may have problems.

I wonder if there is a list of popular accessories, I will have a look through the wiki.

ETA: The autorouter is still running! It sure likes "optimizing".

Edited 1 time(s). Last edit at 09/24/2013 06:00AM by bobc.

In case of the *extra* mosfets i would discard the 2 resistors the inline with gate and the pulldown, again, not needed there, the gate capacitance is too low to bother and uC pin is smart enough unless it says "open collector" or special stuff like that, then it does not need any special treatment.
Also, I would take the gate resistors from the gates of 2N7000 away, arent needed there. What those do, is limit the peak current at charging and discharging, and uC again, normally doesnt need that. However such a resistor may be needed inline with the gate of big fets. For the voltage given, they need to limit the peak current through drain-source of 2N7000 itself coz that one needs it (has otherwise no protection), for the value given in its datasheet absolute peak current.
For big fets, the gate charge is done through 10k resistor, luckily they are voltage devices and that would work in some range of ~100khz (not sure but make better math for it). Perhaps for a small gain make the resistor 1k or otherwise could use a p-fet for that high side charging. There are even complementary p and n small signal fets in a 6-pin or 8 pin packages. Although from this point there is only one step for a fet driver which is a bit smarter than a fet pair.

I agree with NoobMan for once!

The 10 Ohm resistors on the gates of the 2N2007's don't really need to be there. This is because unlike normal, we're not driving these from a uC, but driving them from the HC244 and HC125, which IMO should be able to handle more current per pin.

However, we definitely need the pulldown/pullups on the outputs of the HC244 and HC125. These pull the gate when the output of the HC244 or HC125 is in tri-state mode (output disabled) because we've hit the E-Stop. If they're not there, the gate on those FETs will hold their voltage till they internally discharge, which isn't desirable.

Huh, what HC244 or 125? Didnt noticed and now i'm lost. Sry i was just looking in the output page only. But thats interesting, i wouldnt of used that tbh. The uC pin outputs 3.3v, if the 2N7000 doesnt open fully with that, i would find another fet with lower vgs(th) which would work with 3v logic instead. Imo, thats better than putting it though a buffer. Thats another matter. But anyway, and in any case however, i would put inline gate resistors for the gates of big fets.

Consensus, excellent! Duly removed.

I have done some jiggling to improve compatibility with RAMPS on the Aux 3 and 4 connectors. Aux 4 now has same pins as RAMPS. I've moved E1 and E2 signals to pins that are mostly unused by LCD shields. (I found an overlap with a Reset switch, I guess that most be a soft reset because there is no reset signal on the connector).

Aux 3 is slightly more of a compromise, but it should be electrically compatible at least. I have added 3 extra signals the Due has, but these are duplicates of SPI signals on Mega. Aux3 has a full time 5V pin. I *think* this will allow at least some of the SDRAMPS boards to work with Due without modification.

Unfortunately there will need to be a firmware modification for Mega : Due has SS signal on different pin, so it was a question of optimising for Due or Mega, and I chose to favor the Due. I guess I could add a jumper to select this pin, yes, now I think of it maybe that is a better option.

I've moved the Aux3 connector on the board so that an SDRAMPs board could protrude outwards. I think it should be fairly easy to create an adaptor for existing LCD shields, I will look at that later.

I've pushed latest mods to the github. The autorouter now gets stuck in a loop, so I will need to help it out.

I appreciate everyone's help, if you have any further improvements please let me know!

NoobMan: The buffers are entirely for the E-Stop functionality. They're not there specifically as gate drivers of any sort, but they will definitely do more current than any output from the Due will.

Regarding the 2N7002's though, I agree that they don't provide a decent gate threshold (we'd almost be better driving the IRLB8743's directly). That said, you could replace them with FDV303N's or something of a similar spec. [www.fairchildsemi.com]

Only issue is that from e14 (whom I'm using for reference only cos it's easy for me to search their site), they're twice the cost of the 2N7002's. No idea about other suppliers, but I'm guessing at least 1.5x the cost or greater.

I think the 2N7002 was chosen on cost rather than anything else, so I had a browse for some alternatives. There seem to be quite a few available with better performance at reasonable price.

Some candidates: DMN2075U [uk.rs-online.com], BSH108 [uk.rs-online.com] These parts are also available on my other reference supplier, Digikey.

I found a couple of cheapish integrated gate drivers, FAN3111CSX [uk.rs-online.com], MCP1416 [uk.rs-online.com] which might be a last resort.

To just replace the fet, DMN2075U looks quite powerful, may not even need resistor inline with the gate of big fets. It could easily drive other outputs like fans, by himself: 3.5-4.2A continuous, 27A peaks.

For mosfet drivers, FAN3111CSX datasheet table says 47nF load 1kHz, which is unusually high for a gate and for associated 1A rating, but i think its a mistake they forgot a dot mark, the graphs say 4.7nF, not 47nF - and this is kind of a turnoff for me at least, but otherwise that one should work out. Its a matter of choice and I personally would go with microchip ones, but not that one in particular, looks kinda underpowered, they have a wide selection and i would choose ones with higher current peaks. However if you want to go with mosfet drivers, its sort of design choice and would have to change quite a few things so dunno how much you like to do that.

I will go with the DMN2075U then, I am not sure that Element14 group sell them, but they have an alternative which looks similar, TSM2314.

I have done a little more tinkering, I replaced the 74HC07 buffer when I realised it was open drain with 4050.

I have been looking at schematics for SD card and LCD adapters. The schematics available I find almost illegible so I have re-captured some of them in Kicad. I started work on a RAMP-FD LCD adapter shield. I think it just needs a different connector layout and a level converter and it should work ok.

This weekend I hope to get some gerbers done!

Does anybody know?
Can baudrate of arduino due be greater than 250000?

karabas Wrote:
-------------------------------------------------------
> Does anybody know?
> Can baudrate of arduino due be greater than
> 250000?

That's a good question. The Due has two USB ports, the "Programming" port goes via another Atmel chip so the baud rate is limited by the chip to chip rate, I'm not sure what the max is for that.

However the "native" port goes straight to the Due, and so the data rate is only limited by the USB. In tests that comes out up to 850 kbytes/sec, although that will depend on speed of host etc. Anyway it is a lot faster

bobc Wrote:
-------------------------------------------------------
> karabas Wrote:
> --------------------------------------------------
> -----
> > Does anybody know?
> > Can baudrate of arduino due be greater than
> > 250000?
>
> That's a good question. The Due has two USB ports,
> the "Programming" port goes via another Atmel chip
> so the baud rate is limited by the chip to chip
> rate, I'm not sure what the max is for that.
>
> However the "native" port goes straight to the
> Due, and so the data rate is only limited by the
> USB. In tests that comes out up to 850 kbytes/sec,
> although that will depend on speed of host etc.
> Anyway it is a lot faster
Great!
BTW What device does appear in OS when the board connected to PC? generic usb device,modem, serial port, etc?

I believe it appears as a serial port.

Yay!

Finally got the v1 release candidate done. Had a few last minutes change to increase board size a little to get nice connector spacing and a few other tweaks. Final layout doesn't look too bad, routing got a little cramped.

I will continue some checking over the next few days, if anyone wants to have a look over please do. All design files should be fully updated now, so if you see any discrepancies please let me know.

Files are in the usual place [github.com]

The rendered image is not very accurate but gives you the idea:


RAMPS-FD by donotdespisethesnake, on Flickr

Are you up positively for some observations?

I notice you've changed the end-stop pinouts, so the signal is in the middle as well, so hopefully that won't be a point of confusion. Does any other board do it that way? I'm not fussed either way.

NoobMan Wrote:
-------------------------------------------------------
> Are you up positively for some observations?

Positive suggestions are always welcome Bear in mind I am not an EE, so if the design looks amateur, that's because I am!

Cefiar Wrote:
-------------------------------------------------------
> I notice you've changed the end-stop pinouts, so
> the signal is in the middle as well, so hopefully
> that won't be a point of confusion. Does any other
> board do it that way? I'm not fussed either way.

Yeah, that is one part where I had to decide between compatibility or Improvement. Having power next to ground seems like a crazy idea to me, perhaps there are reasons I don't know, but I suspect the reason was to make the PCB routing easier not to benefit the user.

The number of people who say the printer resets when it hits the endstop suggests it is easy to get wrong, especially with these unpolarized connectors.

With the +/S/- setup, you can use a 2 pin connector and switch between +/S and -/S, without rewiring the connector, and without risking accidentally connecting +/-.

it seems to be better, and more logical to me, although it may be incompatible. Although I have realised I am missing pullups on the endstop inputs, since now there is a buffer and we can't rely on pullups in the Due.

The decision I think was due to the slightly easier routing (originally they were trying to keep it single sided), but also because people were using optos a lot rather than microswitches. If you put an opto (or Hall-O) in backwards when the signal is centre, you fry the opto/hall effect sensor by putting the supply back to front.

On a board with proper silk screening it shouldn't be a problem, as you should be able to really see which end is pin1, and therefore +V.

To get around any issue with +V and Gnd being shorted, we really need a polarised or keyed connector, which unfortunately takes up extra real-estate.

Given that polarising the connector is expensive in board real-estate, keying is about the only choice, but you need to add an extra row. You could simply provide a 4 pin 2.54mm/0.1" pitch header, with pin 2 missing completely from the connector/board. just provide a 2x6 pin (12 pin) connector for Gnd/Signals and a 1x6 pin (6 pin) for +5V at the correct distance away (5.08mm/0.2" gap between centres) for a 4 pin header. If people don't need the +5V (which most won't, since they'll mostly be using microswitches) they don't even need to put the 1x6 pin (6 pin) header on the board if they don't want to.

This would of course make the board bigger again (by 2.54mm/0.1"), but since you're cramped for room this might give you room for the pullups/pulldowns for the buffers somewhere.

Cefiar Wrote:
-------------------------------------------------------
> The decision I think was due to the slightly
> easier routing (originally they were trying to
> keep it single sided), but also because people
> were using optos a lot rather than microswitches.
> If you put an opto (or Hall-O) in backwards when
> the signal is centre, you fry the opto/hall effect
> sensor by putting the supply back to front.

Ok, that makes sense.

> Given that polarising the connector is expensive
> in board real-estate, keying is about the only
> choice, but you need to add an extra row. You
> could simply provide a 4 pin 2.54mm/0.1" pitch
> header, with pin 2 missing completely from the
> connector/board. just provide a 2x6 pin (12 pin)
> connector for Gnd/Signals and a 1x6 pin (6 pin)
> for +5V at the correct distance away (5.08mm/0.2"
> gap between centres) for a 4 pin header. If people
> don't need the +5V (which most won't, since
> they'll mostly be using microswitches) they don't
> even need to put the 1x6 pin (6 pin) header on the
> board if they don't want to.

I really like that idea! I managed to add the pullups without requiring extra board size (I think), but it might be worth it just to get that header arrangement. For the moment I leave it as it is and maybe add it later.

One other change, I swapped diode D103 1N4004 on the Arduino VIN to SMT type already used on the board.

After trying to beef up the power traces, I am struggling with routing again. Perhaps someone can give me pointers to best practice.

In order to get different track widths, in KiCad I use net-ties to separate nets. I then allocate the nets to appropriate net classes with different track widths. That works great. But in the case of the grounds, I really want to add a single ground zone and join all the grounds together. I can't overlap zones, so I add zones and abut them, after turning off DRC. But the router won't allow GND to connect to MOT_GND for example.

The freerouter seems a little buggy, in that it connects pads to a zone, but does not ensure that the zone is actually contiguous, so I unconnected islands.

I'll try using a single ground, and see how that pans out.

Status : Rev A Released

I have sent the gerbers to iteadstudio, so I should get boards back in a week so!

I have made a few changes to improve layout and routing but nothing major I think.

I was comparing RAMPS-FD with RADDS, and RADDS has a number of nice to have features : SD connector, EEPROM, piezo beeper. I am not sure whether these features belong on the CPU board or a shield, they are somewhat generic. However, the Due does not have them. I would also like to see Ethernet on the CPU board... We could also think about software microstep selection and current limit control...

RADDS retains RAMPS concept of motor connectors spread across the board. I think what I found is that keeping to the Arduino footprint makes things pretty difficult, it's a lot easier to start with a blank square and work inwards, then power traces can be laid where you want, rather than snaking around rows of pins.

I think if RAMPS-FD was extended it would need to go to a 4 layer board. Or maybe there is some other way I haven't thought of. Some one suggested a "wing" style; perhaps two (or 3) shield boards that extend outwards, though I am not sure of the mechanical support there.

Apparently there is a Repetier port for Due, yay! That should be easy to adapt for RAMPS I hope.

I've got some of Digistumps DigiX's on the way, which have EEPROM & Wifi/Mesh on-board.

Freetronics (an Australian company) are getting ready to release an EtherDue (Due with Ethernet on-board - pretty sure there will be an EEPROM as well).

And there's the UDOO and a few other systems that combine a Due with a processor. Some have an EEPROM, while some don't.

Maybe the easiest thing might be to make a tiny EEPROM add-on for RAMPS-FD (like the SD card adapter that fits RAMPS)? That way, you can add it if your board doesn't have an EEPROM.