RAMPS for Due!

Quote
Cefiar
If you include wireless options, then there is the DigiX. Mine is apparently in the post somewhere.

Ha, I had forgotten I had one of those on pre-order as well.

Quote

Re: EtherDue - Yes still "coming soon". I help out on the Freetronics forum so I will be trying to get my hands on one to see if it can be used with the RAMPS-FD. Big issue will be the height of the Ethernet socket, but another row of headers should be able to solve that.

The UDOO has some elevated headers to get above the heatsink, but I have found it difficult to find a cheap source for them.

Quote

Q: Did anyone get around to trying RAMPS-FD on a Mega? I know I was going to try this, but between work and travel, I've had bugger all time to do it. While I know it's not really the goal, if it works on both that definitely means that firmware won't stop boards being sent out and used by people (and it'd be nice to have an alternative to RAMPS that I can point people at).

I guess the answer to that is no... I have now got an official Mega2560, so I might have a look at that soon. As I have been working with Repetier I may try that.

---

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

Quote
bobc
In practice all that is really needed is some concept of cooperative multitasking and event driven architectures, which is really bread and butter stuff for embedded programmers.

And even multitasking is not strictly required. In my APrinter firmware, I'm doing just fine with main loop plus interrupts. Yes, it certainly could be used to reduce response times, particularly with network stuff, but from my experience you can do pretty amazing stuff without it, especially with a fast CPU.

Oh, and let me just emphasize that my firmware, as far as I can tell, will work on RAMPS-FD, out of the box, with no issues, no pins should need changing. This includes homing, not losing any steps, inverted heaters and SD card (over SPI). From what I can tell, SD-RAMPS will work (the level shifter doesn't mind 3.3V inputs).

I would appreciate it very much if someone with a RAMPS-FD actually tested it, because I've only been testing it on an improvised setup with a RAMPS wired to a Due (my RAMPS-FD is yet to arrive). It is easy to build, and the github readme explains the build process clearly.

Edited 1 time(s). Last edit at 12/11/2013 05:19PM by ambrop7.

One of the nice things about the ARM world is that it's hard to tell the players apart. One of the ways they try to stand out is by throwing in this and that. One of those things are some fairly good RTOS versions. Free is not quite the same as open source. On a practical basis, It's not a lot different than being tied to the Arduino empire. I have no objection to good code that I don't have to write my self .... (that's not meant to suggest I write good code, only that I like free stuff...).

I have finally received my RAMPS-FD from Geetech. My observations so far are:

- It's a bit dirty and missing jumpers (particularly for microstep configuration), as was observed by Dust. No pins were bent.
- Bed heater (D8) and first two extruder heaters (D9, D10) work (haven't tested D11). I've installed a heatsink to the bed mosfet (the one from RAMPS). It's running pretty cool; heatsink temperature slightly above 50C. Compare that to >100C for my RAMPS1.4 without a fan.
- FET5 and FET6 work. HOWEVER, they are fully activated in the default state of the respective pins on the MCU (I think it's high impedance). This pretty bad; my fans go crazy every time I reprogram the chip (they're very powerful, and normally only run at 15%).
- The first 5 steppers work (I don't have a sixth driver).
- X-min, Y-min, Y-max, Z-max work.
- Z-min does NOT work; it always reads as closed. I'm fairly confident it's a problem with the board because the same setup except for the RAMPS-FD worked before. Don't know about X-max.
- THERM0-THERM2 work (haven't tested THERM3).

But it the end, it's printing . This is with my APrinter firmware, using the default RAMPS-FD config (except for broken endstop).

Obligatory picture (and video):

Well done ambrop7

ambrop7:

Re: Z-min - Check for a short under the resistor packs next to the 4050 (the one nearest the E0-MOT connector - RP801). My guess is that there is either excess solder, or a short under the resistor pack (the tracks are a bit weird there - will clean them up - Have cleaned them up. Have already raised the issue on Github and just provided a patch too!).

Re: FET5/6 - Can you tell me what the default output on the MCU pins that feed FET5/6 is? We have 2 free pullup/pulldown resistors over near the 4050 (one on RP801, one on RP802), so maybe we can pull the lines the appropriate way to stop this behaviour?

FWIW: I'm doing some work on RAMPS-FD and submitting patches up to bobc. Cleaning up a few component placements, etc. Basically tackling a lot of the issues that are up on Github at the moment. Admittedly, I did raise most of those issues, so thought I may as well try and fix as many as I can.

Edited 1 time(s). Last edit at 12/13/2013 02:44AM by Cefiar.

@Cefiar

I've just checked the datasheet for the default pin state. I/O pins are set to input by default, with pull-up resistors *enabled*. That explains why FET5/6 are being driven. The datasheet also specifies the pull-up resistance to be somewhere between 50k and 150k. So, if a 10k pull-down resistor was added, that would ensure that in the worst case, the voltage will be 3.3*(10/(10+50))=0.55V which I believe is low enough to turn off the FETs.

If you can, go for a pull down that's less than 1K ohms. It still won't pull enough to bother the regulator. The lower you go, the less likely odd events are to turn on the FET's.

FWIW: If you're going to load firmware, it's probably advisable to remove the ESTOP jumper while you do so.

This should tie all the outputs down appropriately and stop anything from being driven.

Having Joe typical user abort a firmware upload and have the switches on probably isn't good "feature". I'd vote for making it as idiot proof as possible.

Truth in lending ... there's an ARM board on the bench at work that does some *really* odd stuff while being flashed....

True. It was more a comment for "try this for the moment", and probably a good idea all round anyway for anyone playing with this version (which was pretty much a first run). And yes, while it's a a bug, it's not a hugely high priority one.

I've just pushed some more changes at bobc, so with any luck that should remove a few more bugs from the Github issue tracker.

Next thing I'm going to try and do is more component rearrangement and general clean-up to make some room on the board for the thermistor protection stuff.

Quote
uncle_bob
If you can, go for a pull down that's less than 1K ohms. It still won't pull enough to bother the regulator. The lower you go, the less likely odd events are to turn on the FET's.

The FETs are driven via a buffer (74HC125 in this case), so only a weak pull down is required between the SAM and the buffer. The regulator on the Due does not have a lot of headroom, it's worth saving mA where we can, they all add up.

I plugged in an LCD controller and the voltage dropped quite a bit. I haven't measured the overall current draw, so I wonder how close to the limit we are. We have added several bits of logic, plus stepper driver etc over RAMPS.

On the subject of E-stop, I've noticed that when activated it prevents motion on Y, Z and E0, but not X, which is a puzzle. Maybe an issue with my board, I wonder if anyone else has noticed the same thing?

---

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

Going through the schematic, I'm having a tough time finding the supply and ground connections for U1 and U2. I'm going by the pdf version, so it may be a bit out of date....

I've checked my E-stop and it works for all the hardware I use, including X stepper.

I've just discovered that my E0-dir is broken. The extruder would always move in the same direction. I've moved the same stepper driver to the E2 slot and it works there.

Quote
uncle_bob
Going through the schematic, I'm having a tough time finding the supply and ground connections for U1 and U2. I'm going by the pdf version, so it may be a bit out of date....

Those are hidden pins which automatically connect to VCC and GND. You can toggle display of these in the schematic editor.

---

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

ambrop7: E0-Dir and Z-Min run next to each other, and are on the bottom of the board, next to Pin 21 of the Due.

Can you check that they actually put those tracks on the board (it's possible they removed them accidentally), or that they haven't been damaged somehow by their manufacturing process?

If this is caused by them putting in too large a hole, I suspect other issues as well, such as Y-Min (on the other side of the hole) and Therm-2 (top of board).

If you can confirm there's an issue, I'll see what I can do to re-route these tracks and clean up some more space around the hole. Being exceedingly close in our tolerances around things like holes is a sure way to lead to problems. I'll probably just see what I can do anyway, but if we can definitely confirm that is an issue I'll bump it up my priority list.

Quote
bobc

Quote
uncle_bob
Going through the schematic, I'm having a tough time finding the supply and ground connections for U1 and U2. I'm going by the pdf version, so it may be a bit out of date....

Those are hidden pins which automatically connect to VCC and GND. You can toggle display of these in the schematic editor.

.... which works less well in the pdf version..

Are those two chips running off of +3.3 or +5V? I'd guess U2 is 3.3, but U1 might be something else. If so a 74HCT part might be a better thing to use.

Quote
uncle_bob

Quote
bobc

Quote
uncle_bob
Going through the schematic, I'm having a tough time finding the supply and ground connections for U1 and U2. I'm going by the pdf version, so it may be a bit out of date....

Those are hidden pins which automatically connect to VCC and GND. You can toggle display of these in the schematic editor.

.... which works less well in the pdf version..

Are those two chips running off of +3.3 or +5V? I'd guess U2 is 3.3, but U1 might be something else. If so a 74HCT part might be a better thing to use.

They both run off IOREF, which can be 3.3 or 5V.

---

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

If you will be (in some cases) driving the inputs with 3.3, but running a 5V supply, you might consider a two resistor level shifter to keep the switch points happy. A switch point of 2.5V + 20% of 5V can get you into trouble.

The idea is to be able to use them at 3.3V on a Due (where it'll all be 3.3V), and 5V on a Mega (where it'll all be 5V).

And yes, I know we haven't tried it on a Mega yet. We'd like to try and keep Mega compatibility. This would give people who are currently buying/have RAMPS a new option (without those PTC fuses), that at a later date they could upgrade the whole lot simply by replacing the Mega with a Due.

I'm still waiting on some connectors, so once they arrive I'll be looking at whether it really does work with a Mega.

In the meantime we're pushing ahead with little changes here and there. In absence of detailed info about ambrop7's board issues, I cleaned up around the hole near Due pin 21 a bit anyway, and did a bunch of other changes that have increased the ground plane size a lot.

Bob and myself have been discussing optionally making the board a little bit bigger (pulling it closer to 100mm x 100mm - it's ~ 89mm x 100mm at the moment) to fit in some extra stuff.

Quote
Cefiar
ambrop7: E0-Dir and Z-Min run next to each other, and are on the bottom of the board, next to Pin 21 of the Due.

Can you check that they actually put those tracks on the board (it's possible they removed them accidentally), or that they haven't been damaged somehow by their manufacturing process?

If this is caused by them putting in too large a hole, I suspect other issues as well, such as Y-Min (on the other side of the hole) and Therm-2 (top of board).

If you can confirm there's an issue, I'll see what I can do to re-route these tracks and clean up some more space around the hole. Being exceedingly close in our tolerances around things like holes is a sure way to lead to problems. I'll probably just see what I can do anyway, but if we can definitely confirm that is an issue I'll bump it up my priority list.

I've been checking the connections, and found that Z-min is broken between the buffer and the Due (buffer to endstop header is ok), even though the trace is there. All other endstops are ok, and so is Therm-2. And E0-dir was even easier to test, trace present, but broken. See picture. I suspect that both breakages are under the Due header (where you can't see it...).

I'm wondering if there should be pullups/pulldowns for *all* heaters, as well as stepper enables, in front of the tri-state drivers (not just for FET5/6 which are active-high, unlike everything else). Because guess what happens if the Due is not connected, or VCC fails. Yes, everything is turned on, due to pulldown/pullups on the other side of the drivers.

EDIT: yeah pullups won't quite work if VCC is not connected. But I'm still wondering why my FET1-4 turn on when Due is unconnected. My reasoning is if there isn't any voltage on V_GATE there's nothing to turn on the (big IRLB ) FETs... Or maybe it got some voltage from those LEDs in reverse or something.

Edited 2 time(s). Last edit at 12/16/2013 02:07PM by ambrop7.

Hi ambrop7

Regarding the tracks, I've re-routed that area, but not by much. My guess is the tracks aren't broken, but that the holes weren't plated through (or they've damaged the plating) so that soldering one side doesn't give electrical contact to the other. If you're lucky, you could prise off the plastic on the header and do a tiny soldering job on the pins underneath, then push the plastic down again.

The only other thing that would make sense is the via's not being plated through. You'd have to remove the solder mask at the via's to confirm that (if you haven't already).

I was going to test things regarding the output states when nothing is connected, as I suspected that stuff may be on by default, but hadn't gotten to that yet.

That said, the pull-ups/pull-downs are supposed to kick in when the tristate buffers are "disconnected" in Z mode, so I'm guessing that the tristate buffers are actually somehow loading their outputs when they're not powered. We may need to reduce their value if this is the case.

Either that, or they've not populated the pull-up/pull-down resistors on your board.

Will do some digging.

Quote
Cefiar
That said, the pull-ups/pull-downs are supposed to kick in when the tristate buffers are "disconnected" in Z mode, so I'm guessing that the tristate buffers are actually somehow loading their outputs when they're not powered.

I think the issue is that with VCC unpowered, the pull-ups don't do anything. So if we assume that the DMN2075U will be closed, then the gate of the IRLB8743PBF is in a questionable state, being connected to VCC with a 10k resistor. I think something is causing VCC voltage to be high enough to open the IRLBs.

Actually the pull-up in most cases goes to the +VGATE line, which will definitely drive the FETs.

I think we may need to bite the bullet and either switch to P-channel FET's in place of the DMN2075U's, or go for a proper gate driver.

About the broken connections, I don't really care, just good that we know it's a manufacturing defect and not something with the design.

On another matter, I've been having problems with the ADC ever since. There is very high variance; for example I can see the ADC reading jump from 82/1024 (235C) to 88/1024 (230C), in less than half a second, then back. From what I've observed, it's caused by FETs being switched. So for example if I only drive one heater it's going to be kind of okay, but if I drive two at the same time, after they've stabilized and running at partial power, there is higher variance in readings.

My theory is that as FETs are turned on/off, the (12V) supply voltage changes, and so do the 5V and 3.3V. The 3.3V change, due to the capacitor in parallel with the thermistor, causes the ratio of thermistor voltage to 3.3V supply voltage to change (which is what the ADC is measuring). The error lasts while the capacitor charges/discharges. Anyway, in my setup, I observe:

- With bed OFF: 12V:14.62V 5V:4.99V 3.3V:3.26V
- With bed ON: 12V:14.18V 5V:5.05V, 3.3V:3.32V.

And yet I'm only seeing a 2% voltage change, while 82-->88 is much more (7%). Plus, considering these voltage measurements are for switching the bed, and ADC measurements were done while the bed was off an only extruder heaters were running, there has to be more going on.

Has anyone else had such problems? It could be that my (SainSmart) Due is defective. Because they did use a different 3.3V regulator then in the official Arduino (AMS1117 instead of NPC1117). I've ordered an original Arduino but it'll be a while before I get it.

Quote
Cefiar
Actually the pull-up in most cases goes to the +VGATE line, which will definitely drive the FETs.

I think we may need to bite the bullet and either switch to P-channel FET's in place of the DMN2075U's, or go for a proper gate driver.

uncle_bob gives me a thought. If we used HCT logic for the buffers and drive them from 5V, they will output 5V and accept either 3.3V or 5V as input. The advantage is that we may be able to drive the big FETs directly, and more importantly drive them with positive logic. That means we can pull the gates to 0V, so if 3V or 5V are not present the FETs will be off.

---

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

Quote
bobc

Quote
Cefiar
Actually the pull-up in most cases goes to the +VGATE line, which will definitely drive the FETs.

I think we may need to bite the bullet and either switch to P-channel FET's in place of the DMN2075U's, or go for a proper gate driver.

uncle_bob gives me a thought. If we used HCT logic for the buffers and drive them from 5V, they will output 5V and accept either 3.3V or 5V as input. The advantage is that we may be able to drive the big FETs directly, and more importantly drive them with positive logic. That means we can pull the gates to 0V, so if 3V or 5V are not present the FETs will be off.

That makes a lot of sense, and removes a whole lot of components (4 DMN2075U's and all their associated resistors). It does mean we're not pushing the FETs as hard as they could be, but it'll be a lot better than just using 3.3V.

We could then lose the 12V regulator and put in a reasonable 5V supply to take the load off the Due completely. We could even power the Due's 5V directly off it, which bypasses any issues with the Due's on-board regulator.

Another advantage: By moving all the pull-ups to pull-downs, it will definitely reduce all the VCC tracks running everywhere for them.