RAMPS for Due!

This is a very interesting and quite surprising development! I had hoped a manufacturer would pick up the design, just not yet I would be somewhat amazed if they built 2000 boards without checking for production readiness, but it is fair to say they must have a different business model to what I am used to.

For the record, I've had no contact with Geetech. They have obviously not followed the BOM too closely, there are PTCs instead of fuses, I guess the PCB layout is unchanged.

For anyone buying the Geetech boards, unless Geetech did some in-house testing I am not aware of, you should be aware that the design is not fully proven and so they should be regarded as experimental prototypes. There may be some hardware mods required to get all the features working.

However, for $30 a piece, I am tempted to buy some to do some stress testing.

---

What is Open Source?
What is Open Source Hardware?
Open Source in a nutshell: the Four Freedoms
CC BY-NC is not an Open Source license

Looking at the pictures, I would seriously doubt it!

They've populated all the standard fuse positions with PTC's.

There is a reason we've moved away from PTC's (as has RAMBo), and they obviously don't care that when exposed to the wrong conditions, they are NOT SAFE.

For an example of what happens when you try and draw too much current through a MF-R1100 11A/16V PTC running on 24V, I present this pic of a RUMBA that belongs to a friend:


In this case, he hooked up a 12V heated bed while he had a 24V PSU connected, so he was drawing about 20-25A.

He literally saw that it caught fire, and it produced a huge amount of smoke. Sure that would have set off a smoke detector, but how much of the printer would have been damaged IF it was in a printed box and he wasn't actually watching the printer at the time.

In something that has to run hours on end, and in many cases in some sort of unattended fashion, this is UNACCEPTABLE.

So please, if you have any brains, don't give people who sell electronics with MF-R1100 PTC's on them any money if they claim that they will work at 24V. Those PTC's are only rated for 16V. They're making a quick buck at the expense of YOUR safety.

PS: For what it's worth, I have registered an account and left a comment asking that they stop selling them with PTC's on them, and the reason that they were removed from the design. If they're smart, they'll change them over.

Edited 2 time(s). Last edit at 11/17/2013 05:28PM by Cefiar.

I can't read any markings on the PTCs but it is possible they have used devices rated for 24V. Still, it is a pity because it was a design intention to move away from PTC fuses.

Apart from that, I guess those boards would work on 12V, and it is not hard to replace the PTCs with the intended fuse holders. It would certainly be more cost effective for me to buy their boards and rework them rather than building them myself.

---

What is Open Source?
What is Open Source Hardware?
Open Source in a nutshell: the Four Freedoms
CC BY-NC is not an Open Source license

I'm planning on buying one to use with 24V.
Will replace the PTC fuses on day 1.

Let's also see if they changed anything else or just the fuses.

For 30$, it worth it.

They replied to my comment saying they're going to change them, which is a good thing. Once they do I'll amend my post above.

bobc: For the 11A rating, there are NO PTC fuses available from Bourns that have a rating greater than 16V, which is the whole problem - they simply don't go that high. And you can't run them in parallel or series easily to share the current or voltage rating, due to the way they work internally.

MF-R1100 PTC = ?
Got a link?

...... and if you run them above their voltage ratings they explode .... and if you run them inside their voltage rating they may explode (eventually) .... and their trip point varies with air flow ... and ...

dump them

Quote
Cefiar
They replied to my comment saying they're going to change them, which is a good thing. Once they do I'll amend my post above.

bobc: For the 11A rating, there are NO PTC fuses available from Bourns that have a rating greater than 16V, which is the whole problem - they simply don't go that high. And you can't run them in parallel or series easily to share the current or voltage rating, due to the way they work internally.

Great! Did they say if they are going to rework existing stock, or make the change to future builds? IOW, if someone buys one today, will they get fuseholders or PTCs?

It's not important, but other people make PTC fuses apart from Bourns, e.g. TE. They look very similar, and I don't know what make they might have used.

---

What is Open Source?
What is Open Source Hardware?
Open Source in a nutshell: the Four Freedoms
CC BY-NC is not an Open Source license

A2: Here's the spec sheet for the Bourns MF-R1100 - [www.mouser.com]

uncle_bob: My view exactly.

bobc: Didn't really say but they definitely sounded like they wanted to make it work right, so I don't know about existing stock (or how many they have on hand). Will find out from the first people that buy them.

Also, Re: other suppliers apart from Bourns, like TE.

The biggest I've found is 15A, but it's also 16V, "AHRF1500" ($1.40 ea at Digikey in Qty's of 1, $0.78 ea in Qty's of 1000): [www.te.com]

There are 10A ones that go to 32V though, "AHEF1000" ($1 ea at Digikey in Qty's of 1000, smallest they do): [www.te.com]

This matches up with my previous research. Over 10A, they are all 16V. It seems that a lot of the suppliers are recommending these things for automotive applications, which is why suppliers don't seem to worry too much about voltages higher than 16V. There's a lot smaller current range above that voltage in the DC components.

The annoyance here is that the AHRF would only be suitable for 12V systems, and the AHEF1000 would only be suitable for 24V systems (as the current draw at 12V is just slightly too much). Having a different component for each voltage is a real annoyance, and one we've tried to stay away from with RAMPS-FD. The linear reg to feed the Arduino (with a jumper) is the only concession to that we've made so far, and even then, that's a bit of a hack.

BTW: For a cost comparison, the fuse holders we're using at Digikey are $2.84 ea in Qty's of 1, or $1.28 ea in Qty's of 1000. So the PTC's are cheaper than just the fuse holders, let alone the extra cost for the fuses ($0.83 ea in Qty's of 1, $0.37 ea in Qty's of 1000), so you can see why people used them originally.

I noticed a cheaper fuse holder at Digikey [www.digikey.com] which we could consider for a Rev B. This is a similar type to the one used on RAMBo.

I was thinking that Geetech could reduce inventory by using the same component, but if you look at their RAMBo [www.geeetech.com], it has a fuse directly soldered to the board! I think Geetech are not quite getting the point

---

What is Open Source?
What is Open Source Hardware?
Open Source in a nutshell: the Four Freedoms
CC BY-NC is not an Open Source license

As long as you do not want to go over 20A that's a fine part to use. It's Nylon, so there's probably not a lot of margin in the part for operation at higher current.

From what I understand, the max fuse we're suggesting is 15A, so that should be fine.

Their new announce at Aliexpress is showing the blade fuses already.
And cheaper than the site.

[www.aliexpress.com]

They don't have the best connectors on the board (the disconnectable kind) but very glad they've changed to the fuses.

I realize that this is *way* to late (sorry about that!) - is there enough room around the big FET's for heat sinks? You can always use top clips. I'm wondering about wrap arounds.

(yes there's a pattern here .... 20A fuse comments .... heat sinks .... liquid nitrogen cooling of pc board traces ....)

There should be enough room around Q201 for an ordinary U-shaped bolt-on heatsink (Q201 is the FET for the heated bed). Something like [www.digikey.com.au] or [www.digikey.com.au] for instance. Note that these are guesses and I wouldn't recommend anyone buy them solely on the fact I've quoted them here - do some research on their dimensions before you buy anything.

Just watch that the bolt and/or heatsink isn't long enough to touch the FET next to it, as the case is the FETs Drain, which goes to the load in our setup. Shorting the Drain on Q201 to the Drain on Q203 (which is the one next to it, and is for Extruder 1) would mean switching on either will switch on both. You'd end up with weird behaviour and lots of current through whichever FET was active.

FWIW: Those FETs can really pull a fair bit of current, and they've got a very low Rds(on) which means a lot less heat during switching than compared to some other FETs used in say RAMPS. The FET specified has a max of 30V, but I wouldn't suggest running them over say 28V.

Note: The connectors on all outputs, with the exception of the heated bed, are 3.5mm pitch, and most of those connectors tend to have a rating of 6-8A, so I wouldn't suggest trying to draw more from them. The 5.08mm connectors used on the heated bed and on the voltage inputs are usually rated between 12-15A, so once again, unless you can find better connectors, this might end up being your limit. Also, if you're planning to draw more current, might be worth getting the boards made with a heavier weight copper clad than the usual 1oz.

Going to 2 ounce copper is the easy part. That's a standard enough process that the added cost is quite low in any sort of volume.

Connectors are always odd beasts. They are temperature rise rated and a lot depends on what the starting temp is for that rating. If they are rated for under hood auto use, you'll probably get a lot more out of them on a room temp / possibly forced air application. I've seen 25A connectors run quite successfully at 100A that way.... I've also seen a lot of connectors melt when the same math worked the other way around. None of that may apply in any way at all to these specific connectors. They may be running as hard as they can at 15A on an open board in a normal environment. No I would not expand the board for bigger connectors. They are not a bad part.

Just to be clear on where I'm going with this. There are 8"x12" and 10"x 12", 12V heated beds that get up around 20A or so. Yes 24V would be a *lot* better idea. No, I haven't bought one, 24V isn't that hard to do. There are others who might flip the same coin and make the 12V decision.

Edited 1 time(s). Last edit at 11/22/2013 10:57PM by uncle_bob.

Hello. Thank you very much for this board; I've ordered one from Geeetech.

In the mean time, I've been porting my APrinter firmware to run on the Due. For testing, I've wired it manually with a RAMPS1.4 and my firmware is already working nicely in that setup. The pins in the default config should be the same as RAMPS-FD, except maybe for the heaters, since the firmware can't yet use the FET that needs to be inverted.

Now I'm trying to get the SD card working. Am I assuming correctly that a card can be directly connected, without a level shifter or anything else, to the MISO/MOSI/SPCK/SPI_CS1 pins on the SPI header of RAMPS-FD? I see that the SPI_CS1 ends up on SPI0_NPCS1 (PA29) so it seems I'll need to use SPI0->SPI_MR=SPI_MR_PCS(0b0001)|...;

P.S. Geetech have indeed informed me shortly after my order that the board won't work with 24V due to wrong fuses.

Edited 2 time(s). Last edit at 11/23/2013 07:48PM by ambrop7.

ambrop7: Fortunately, if you've got any skill with a soldering iron, you can easily buy the necessary fuse holders and replace them yourself (assuming that the board isn't modified in any other way). Good to see that they mentioned this though.

Okay, SD card with APrinter/Due works now. Hopefully the RAMPS-FD will fix my spaghetti problem

Quick update... I have been massively busy with work so not a great deal of progress.

The hardware is still working ok, at least no smoke. I am waiting on a board from Geetech to see what they are like.

Software wise:

@ambrop7 : great to see some software development, we will need it!

The firmware linked to on the Geetech wiki is the RepRapPro firmware for Due but not for RAMPS-FD! I have no idea what hardware RepRapPro are using with Due. The RRP firmware is being actively developed, I might have a look at it when it has settled down.

I got the Repetier port for Due partially working after fighting with the config for a bit. The inverted heater FETs need some low-level changes in Repetier, and Repetier has some unusual homing behaviour which doesn't suit my printer. Repetier is on hold for the moment while I sort out a more typical Reprap printer, I've got a Vergia Alu (Prusa Air variant) and an Ordbot Hadron part-built.

I have ported firmware I worked on for R2C2 electronics to Due, which is what I am using for testing. A preliminary release is available at [github.com]. This firmware does not compile with the Arduino IDE! You will need GNU ARM compiler and tools, the ARM compiler in Arduino IDE is quite old and doesn't compile the code. To download the firmware requires bossac utility, which is in the Arduino IDE release. I will write up some notes on how to build and download soon!

The R2C2 firmware is designed to be configured by SD card, I don't have that working on Due yet, and it needs the add-on SDRAMPS board for that to work with RAMPS-FD.

---

What is Open Source?
What is Open Source Hardware?
Open Source in a nutshell: the Four Freedoms
CC BY-NC is not an Open Source license

Oh, I've fixed the inverted heaters problem in APrinter. I don't think there's anything now preventing it from running on a real RAMPS-FD.

@bobc If you find some time could you give APrinter a test on your board? All the instructions are here, including building for Due/RAMPS-FD. You need Linux and the latest gcc-arm-embedded compiler (link in instructions).

Quote
ambrop7
Oh, I've fixed the inverted heaters problem in APrinter. I don't think there's anything now preventing it from running on a real RAMPS-FD.

@bobc If you find some time could you give APrinter a test on your board? All the instructions are here, including building for Due/RAMPS-FD. You need Linux and the latest gcc-arm-embedded compiler (link in instructions).

Does your code use advantages of the arm?
Why only 250000?

Quote
karabas
Does your code use advantages of the arm?
Why only 250000?

I have simply implemented the HALs that my firmware depends on (e.g. GPIO, serial port, ADC, timers, SPI). Due to faster CPU and more RAM, it allows much faster max stepping speeds and larger buffers, but otherwise the firmware behaves the same as on AVR.

Hardware my firmware does *not* make use of, at least in its current state: 12-bit ADC (works in 10bit mode, will be fixed soon), native USB port, fast MMC/SDIO interface (as opposed to SPI), nested interrupts... And there is nothing bad about this, I simply didn't need to use it to achieve the target functionality. It is unwise to "use'' some hardware/feature because it's there without a clear benefit. For example I don't benefit at all from allowing nested interrupts, it would just complicate interrupt handling and introduce bugs.

About baud rate, I just chose 250000 because I didn't see a need for more. It is configurable anyway. But it's limited because we're talking about the programming port, not the native USB port.

Edited 1 time(s). Last edit at 11/29/2013 08:09PM by ambrop7.

Quote
ambrop7
Oh, I've fixed the inverted heaters problem in APrinter. I don't think there's anything now preventing it from running on a real RAMPS-FD.

@bobc If you find some time could you give APrinter a test on your board? All the instructions are here, including building for Due/RAMPS-FD. You need Linux and the latest gcc-arm-embedded compiler (link in instructions).

Quote

With the board connected using the programming port, press the erase button, then the reset button, and finally run flash-rampsfd.sh to upload the firmware to your board.

The erase button is pretty much inaccessible with the RAMPS-FD attached, but the command "stty -F /dev/ttyACM0 1200" will erase the Due and put it into the bootloader.

---

What is Open Source?
What is Open Source Hardware?
Open Source in a nutshell: the Four Freedoms
CC BY-NC is not an Open Source license

I have not used the AVR version of the ARM ADC. On other flavors of ARM, the ADC is quite good. Running it in 16 bit readout mode is well worth the effort on some ARM's. You can get ENOB's in the 13-14 bit range.

Quote
bobc
The erase button is pretty much inaccessible with the RAMPS-FD attached, but the command "stty -F /dev/ttyACM0 1200" will erase the Due and put it into the bootloader.

Yes, I read that in the Arduino docs, but for some reason it's not working optimally on my Due (SainSmart) board. The 1200 baud will put it in bootloader, but after flashing, it won't reset, despite bossac sending the reset command. No matter what I do with my baud rate after setting it to 1200 (restore immediately, restore after flashing), I need to physically press reset in order for the firmware to start. But since reset is accessible on the RAMPS-FD, yes, I'll update the instructions.

I also have a similar problem, when the board is powered on, sometimes (~20%) the firmware also will not start, it will just stand still, with L led on, until I press reset. Anyone seen something like this?

Quote
uncle_bob
I have not used the AVR version of the ARM ADC. On other flavors of ARM, the ADC is quite good. Running it in 16 bit readout mode is well worth the effort on some ARM's. You can get ENOB's in the 13-14 bit range.

On the AT91SAM3X, the ADC is 12-bit only, and can also run in 10-bit mode, which is what I do, since I haven't bothered fixing the thermistor tables yet.

When you fix the thermistor tables, think about some sort of "transparent" fix. There are vendors out there supplying tables for their thermistors, but not flowing them upstream. Why they do this - I have absolutely no idea. How to implement such a thing (or if it's worth it) - that's up to you.

Quote
uncle_bob
When you fix the thermistor tables, think about some sort of "transparent" fix. There are vendors out there supplying tables for their thermistors, but not flowing them upstream. Why they do this - I have absolutely no idea. How to implement such a thing (or if it's worth it) - that's up to you.

The problem is that the thermistor tables are generated with a Python script. You need to know the number of bits at the time of generation. As long as I am to stick to generating tables, the best I can do is ship separate 10-bit and 12-bit tables, and if the user has a different thermistor, he'll have to regenerate the right table with the right parameters (I'm using the usual NTC model with R_25C and Beta along with constant R1).

On the other hand, I could try to get rid of tables and instead calculate temperature with a formula, in floating point. This wouldn't be so bad because I do the heater power calculations in the main loop anyway. Only problem would be the heater PWM interrupt where I always check for over-temperature, and for that, I'd need to inverse the formula and precompute how the configured temperature limits translate into ADC readings.

But still, this is not a critical problem, a 10-bit ADC really is enough, with proper control you can get pretty close to keeping the temp around +-2C.

Also, I've experimented with generating the tables at compile using template metaprogramming, but it kills the compiler

Edited 2 time(s). Last edit at 11/30/2013 03:46PM by ambrop7.

Tables are nice to take care of a variety of issues. I have yet to see a thermistor that actually follows the "official" curve out to the sort of precision some people seem to expect. That said, storing beta / beta temps and nominal resistance / nominal temp would be a *lot* more flexible than the tables. There's a narrow range in which we actually care about accuracy. Fit the numbers so they work over that range. Outside that range, let it do what ever it does. You could store the real value of the pull up resistor as well.

This would be a break from the past, but the past is gone once you dump 10 bits. If you get a 16 bit ADC tomorrow, it will work with that. If I was doing that, I'd pre-calculate a few often used values at boot (min and max temps for sure). That way you are not hitting the calc routine all the time for the same diata. I'm not sure if a simple table near the control loop set point would be worth it or not. As you pointed out above, just because you can does not mean you should.