Quote
bobc

One issue that I nearly mentioned but didn't was the question of opto-couplers. It seems on the skynet boards, they run off 5V which is provided externally. The optos would sink about 12mA each at 5V, or about 7.5ma at 3.3V which is a bit on the high side for the Due.

The optos also add a small extra delay of 1-2us, which may need to be accounted for.

So I think there is a definite need for a header module with level converter and pulse stretcher. I would like to use the standard pMinMo 10 pin connector, but it takes up a lot of space, so might be tricky. A possibility is to use the 4 pin motor connector for enable/step/dir/gnd, and hope that no one will try to plug an external driver into a Pololu motor output.

These (mine) opto-boards are already in use by several customers for 3D printers.
I have 2 printers running these drives on arduino with my own Ramps version without problems.
The firmware in use is Marlin and it's step output pulse is 2µsec, the optocouplers stretch this as they switch on fast but release slower.
I don't think there's a need for a pulse stretcher exept maybe for firmware wich really uses 1µsec step pulses.

A resistor change might be needed to reduce the current for Due, the drives still work on 5V with 1K series resistor for the optocoupler.
Level conversion isn't needed for these opto-drives, just a recalculation for the series resistor.

Quote
bobc

Ok, that is useful info. I will order one of the boards for testing.

I will send you one for testing + one of those Pololu to PMinMO adapter PCB's, just need your address....

Hi bobc :
I got one RAMPS-FD from www.geeetech.com ,and also I get a copy of schematic from github ,when I try to testing repetier-frimware and finished some code-moding ,I found that geeetch.com use V1 issueA schematic which has lots of changes from issueB ,So would you pls send me a copy of issue A schematic? THX a lot!
And I have finished testing them0~3 ,all endstop . Now I has some problem on testing D8 D9 .Repetier-frimware define turn off as Arduino due D8 io at low level ,but the output turn on ,and that should be turn off , when Arduino due D8 io at high level the output turned off , I have check the IC 74HC244d, IO level is currect , mosfet is working good ,so I am foucs on the Q...(forgot the num) which is work as an swtich to controll MOSFET turn on/off .....
so I am checking what happened on earth now ....

V1 has the outputs inverted. This is a known issue and as such part of the reason for the redesign.

Basically Geeetech jumped the gun and started selling boards for a design that was not finished.

Oh ...... NO ..... OK then ,I get it , I will try to fix it then .....And I found the reason too , it seem to need few modification to fix it .when I fix it down then post the result ....

You can remove the drive transistor and some associated components to make the circuit to the way we have it now, and it "should" be fine.

I posted a bit about this earlier in this thread (read it all, it explains a bit), but there is a lot going on (on the PCB and personally for me atm) so I will need some time to figure out everything that needs to be changed.

bobc may have some details on what needs to be changed to get it going as well.

this is why I requested that someone who knows what is going on up dates the wiki with know issues and work around..

as there is now going to be some 1000+ people with version 1A boards needing help.

Edited 1 time(s). Last edit at 01/30/2014 01:43AM by Dust.

Yeah ,that's great ! I will try it tonight .
Geeetech use IRF3205 instead of IRLB8743PBF which bobc use in issueB , I checked the datasheet of two MOSFET .



For IRF3205 Vgs = 3.3V Ids is around 6A or less (see the picture above)



For IRL8743PBF Vgs = 3.3 Ids is around 20A or above

And I have check the current of my little j-head ,is 2A ,that mean THEORETICALLY direct driver is work for me with the geeetech board ... so ,good luck for me .....

BY the way I controll the heat bed with relay ,so direct driver is worked ...

You can access the v1A files via the following link RAMPS-FD Revision 1A

I made some modifications to Repetier firmware to support the inverted outputs on v1A, but I never got repetier working reliably. There was an issue with random shifts of the print head which I haven't figured out. My updated Repetier is here [github.com]. Apart from the inverted outputs the only other changes I made were to the configuration.h file.

I have been using the v1A hardware without modification, but being careful not to leave it with power on.

I recently received a Getech board, it has fuses which is good. I just checked and it has IRF3205, I hadn't noticed before. The IRF3205 is probably ok with the 12V drive circuit, it doesn't look very good for logic voltage levels.

---

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 finished testing , yeah! the borad seem working good with bobc ' firmware .After compare IRF3205 and IRBL8743 .Maybe add a 74hc04 in order to invert the logic level is a good idea .

I am working on making a version of this board for the BeagleBone (Cape-RAMPS, or CRAMPS), and am somewhat limited on pins (the BeagleBone Black looses a lot of I/O if you want to use the on-board flash and HDMI out).

I am trying to understand the expansion connectors: Aux2, Aux3, and Aux4

I see Aux3 is used for the extruder expansion board design, but notes on the schematic seem to indicate this is a standard connector. Are there other boards that connect to this header, or any sort of a standard for the header pinout and signaling?

And what are Aux2 and Aux4 intended to be used for? Are they simply connectors added to RAMPS-FD to make use of available extra signals, or are they somewhat standardized as well? Are there any designs in-progress using these connectors?

Finally, I'll likely have to move things around a bit to account for the dual-row BeagleBone headers. I assume I'd need to leave the relative placement of the Aux headers consistent if an expansion board for the RAMPS-FD is to be used on the CRAMPS design. Other than the Aux connectors, is there anything else that really need to have the same relative spacing (I2C headers, serial headers)?

Initially I tried to keep things similar to RAMPS, then realized they were too many differences (e.g. 3.3V vs 5V, SPI on different pins, etc) so just assigned unused IO to connectors as convenient. I then realized I could get compatibility with SDRAMPS (SD card module) if nothing else, so Aux3 can be used with SDRAMPS. Maybe with BBB an SD card extension is less useful.

The rest are pretty much up for grabs. I followed a similar pattern to RAMPS, but don't expect any compatibility. As there is no standardization between controllers, expansion boards like the LCD/SD controller have a specific interface board for each controller. RAMPS-FD has clearance around the connectors to allow an adapter card to be plugged in over the connectors.

So I would try to collect up unused IO (if any!) on some connectors and put them convenient location for connecting via IDC connector, and not worry too much about compatibility. I mean, it's nice if you've got it, but it can constrain the design too much, and in practice most of the extension boards are designed for 5V, so are limited use.



ETA: the 4 pin I2C headers use the same pin out as RAMPS, as do the serial connectors which are designed to be compatible with a 6 pin connector FTDI use. The location on the board is not important I think.

Edited 1 time(s). Last edit at 02/02/2014 09:33AM by bobc.

---

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

Thanks Bob!

I can keep the SPI header, and I'm trying to keep the BOM as similar as possible (hoping that someone who's building the RAMPS-FD might build a few of the BeagleBone version to see if they sell).

I'll assign what I/O I have to some other connectors and leave it at that. The SD card and LCD / Panel interface isn't such a huge issue with the BeagleBone since there's on-board SD/eMMC, USB, and HDMI. It's still potentially handy to have a small LCD or buttons or whatever, so I'll definitely pinout any free pins so they can be accessed.

Another question:

I notice the LEDs for the high-current MOSFETS are driven by +5V instead of +V_POWER, and I'm wondering why.

Typcical LEDs have very low reverse voltage ratings (it's 5V for the OSRAM LH R974-LP-1 pulled up by the DigiKey part number in the BOM), and typically don't include specifications for zener or avalanch mode. If +V_POWER is 24V, that puts 19V of reverse bias across the LED, well outside it's specs. Even at 12V the LED is seeing 7V reverse bias...outside it's specification, but not as likely to cause damage as the 19V probably would. I've seen LEDs that begin to conduct under reverse voltages of 7V or less, so this seems marginal even when running on 12V.

Am I missing something that makes this OK?

Edited 1 time(s). Last edit at 02/03/2014 02:36PM by cdsteinkuehler.

...and one more:

In trying to calculate a new operating point for the TLV431 used to clamp the ADC voltage (the BeagleBone has 1.8V Analog inputs), I thought I'd check the existing operating point.

It doesn't look like ANY current is flowing through the exsiting regulator. If the schematic indicated values are correct (R1002=10K, R1003=1.5K, R1004=1K), that's 12500 ohms for the three in series, which puts 2.4V across the 2.5K of R1003/R1004 (2500R * 12V / 12500R = 2.4V). The TLV431 would have to be a battery for OV_REF to get to 3.1V. Unlike the LED issue, this can be easily fixed with value changes.

Quote
cdsteinkuehler
Another question:

I notice the LEDs for the high-current MOSFETS are driven by +5V instead of +V_POWER, and I'm wondering why.

Typcical LEDs have very low reverse voltage ratings (it's 5V for the OSRAM LH R974-LP-1 pulled up by the DigiKey part number in the BOM), and typically don't include specifications for zener or avalanch mode. If +V_POWER is 24V, that puts 19V of reverse bias across the LED, well outside it's specs. Even at 12V the LED is seeing 7V reverse bias...outside it's specification, but not as likely to cause damage as the 19V probably would. I've seen LEDs that begin to conduct under reverse voltages of 7V or less, so this seems marginal even when running on 12V.

Am I missing something that makes this OK?

No, I think that is probably an error. I think someone mentioned it by I didn't pick it up. Thanks for spotting 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
cdsteinkuehler
...and one more:

In trying to calculate a new operating point for the TLV431 used to clamp the ADC voltage (the BeagleBone has 1.8V Analog inputs), I thought I'd check the existing operating point.

It doesn't look like ANY current is flowing through the exsiting regulator. If the schematic indicated values are correct (R1002=10K, R1003=1.5K, R1004=1K), that's 12500 ohms for the three in series, which puts 2.4V across the 2.5K of R1003/R1004 (2500R * 12V / 12500R = 2.4V). The TLV431 would have to be a battery for OV_REF to get to 3.1V. Unlike the LED issue, this can be easily fixed with value changes.

I've not used this type of device before, so I depend on advice given I think the values were suggested by uncle_bob, unless I misinterpreted what he said.

I'm confused by your comment though, the TLV431 isn't intended to generate 3.1V, but to sink current if the voltage on OV_REF exceeds 3.1V. That was my understanding of how the protection circuit is supposed to work anyway.

---

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
I'm confused by your comment though, the TLV431 isn't intended to generate 3.1V, but to sink current if the voltage on OV_REF exceeds 3.1V. That was my understanding of how the protection circuit is supposed to work anyway.

Yes, it's a standard shunt regulator (basically a fancy zener diode).

My comment relates to the fact it appers the output is supposed to be 3.1V, but the resistor divider (between the 10K source resistor and the 2.5K reference resistors for the TLV431) is set to generate 2.4V. So the TLV431 won't start shunting current to regulate the voltage until something else brings the voltage above 3.1V. The only thing that can do that here would be the thermistor lines themselves, via the protection diodes, but I don't think that's really what is intended.

I susepct OV_REF is supposed to be a regulated 3.1V rail, and I'm trying to point out that it's not going to typically be 3.1V with the bias resistors chosen.

Quote
cdsteinkuehler

Quote
bobc
I'm confused by your comment though, the TLV431 isn't intended to generate 3.1V, but to sink current if the voltage on OV_REF exceeds 3.1V. That was my understanding of how the protection circuit is supposed to work anyway.

Yes, it's a standard shunt regulator (basically a fancy zener diode).

My comment relates to the fact it appers the output is supposed to be 3.1V, but the resistor divider (between the 10K source resistor and the 2.5K reference resistors for the TLV431) is set to generate 2.4V. So the TLV431 won't start shunting current to regulate the voltage until something else brings the voltage above 3.1V. The only thing that can do that here would be the thermistor lines themselves, via the protection diodes, but I don't think that's really what is intended.

Yes, that IS what is intended, e.g if the thermistor input is accidentally connected to 12V.

---

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
Yes, that IS what is intended, e.g if the thermistor input is accidentally connected to 12V.

Then it seems like the circuit should work as designed. I'll have to review this to see what I can do for similar protection on the BeagleBone. The 1.8V ADC levels leave less room for protection, and I'd be worried about feeding back the 12V into the ADC reference voltage via the 1K pull-up as much as via the signal itself. Thanks for the explanation!

I'm far enough along in my design I've started a thread for the CRAMPS board (BeagleBone Cape version of RAMPS).

I would appreciate it if anyone here is willing to do a design review of the schematic, which is mostly complete. I still have some I/O pins to assign, which will be done based on the PCB layout which is in progress, but everything except the top sheet is now complete (pending any errors found).

Thanks again for the great design work on the RAMPS-FD!

OK, one more question about connectors.

I'm trying to figure out the latching 0.1" headers. The picture on reprap.org shows standard 0.1" pin headers. The PCB footprint and Digi-Key part number called out on the BOM (which doesn't seem to have been updated for V2 yet) calls out a vertical latching header (Molex KK series). The image bobc posted above and my V1 board from Geeetech have right-angle latching headers, which reverses the pins.

Which headers are intended to be used for the RAMPS-FD, the vertical or horizontal KK series, or just plain vertical/right-angle pin headers (no latching mechanism, so no polarity issues)?

I'm not real worried about the pin swap on the motor connectors (the stepper just runs backwards, fixable via configuration), but the Aux 12V header IS sensitive to polarity, and probably the two 12V FET outputs (FET5 and FET6), which seem intended to drive fans or LEDs. It would be nice if the pin1 on the schematic matched pin1 on the connectors for these headers at least.

I tend to build prototypes using ordinary 0.1" headers, it's cheaper and for motor connectors easier to swap direction.

The intention was to allow any type of connectors - latching/non-latching, polarised or not, or screw terminals, but anyway in practice it's impossible to prevent people using any type of connectors.

The issue of pin 1 is problematic, pin 1 is not well defined even for the latching 0.1" (KK) header. Molex mark pin 1 in opposite places on their drawings for housing and header. For right angle connectors, Molex have the plastic tab at the bottom, others have it at the top. If people fit screw terminals, then the orientation is moot, you can insert wires in any order.

Since the PCB layout allows many types of connector and orientations, and once people have the PCB, they can populate it with whatever connectors they want. Even if we were to publish a "standard" BOM, people do not follow it (e.g. Getech).

Therefore, without ability to control manufacture or use of the boards, I would rather not define any hard and fast rules for where pin 1 should be on particular connectors.

---

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
Therefore, without ability to control manufacture or use of the boards, I would rather not define any hard and fast rules for where pin 1 should be on particular connectors.

Understood, and thanks for the explanation.

I'll follow along and stick wtih the current footprints and try to include some clearly visible labling. But it's hard to make the labels easy to read and keep the board small at the same time!

Quote
bobc
There is an issue with homing, which doesn't always seem to work, and I get lots of position shifting during printing, even at low speed/accel. I couldn't find a combination of settings that worked. I suspect it may be something to do with step doubling, because there doesn't seem to be any motor stalls, the print head just goes to the wrong place.

Your Repetier symptoms are very similar to what I started getting on my delta after bundling my wiring together creating cross-talk from my extruder motor wiring into the endstops. The extruder would crash into the bed slowly, homing was unreliable and prints ended up tilted and with random level shifts. This was confirmed by disabling end stop checking during moves which fixed all the above.
you can quickly test this by disabling the function in configuration.h

#define ALWAYS_CHECK_ENDSTOPS false

I will probably go back and use shielded motor cables but as end stops should only be needed for homing I have left end stop checking off with no problems at all.

How close is the bom on github to the schematic? And what is the status of production?

I will be ordering parts soon according to answers of these questions.

I don't know about the state of production, but the BOM on github is for the previous version board, not the current schematic and PCB. I just had to go through this for my port of the design to a BeagleBone cape and I worked out orderable part numbers for everything (added as user attribute fields to the CRAMPS shematic and listed in my BOM files), but I can't guarantee I picked the parts intended for the RAMPS-FD. I'm pretty sure I picked parts that will work and I do generally know what I'm doing (I design electronics for a living), but everyone can make mistakes now and again, even me!

As cdsteinkuehler says, the BOM is not up to date. Hopefully we'll get to that soon.

Hello BOBC
,
GREAT JOB!
I have a multiples questions

1.http://www.geeetech.com/ sell the last version of this board?, where buy the last version?
2. Steppers modules A49xx present any issues with this board + DUE 3.3v?
3. Where find The Lcd Level converter?

Thank You =)

The newest version of this board has NOT YET BEEN TESTED or assembled.

Geeetech are currently selling the old version, which has KNOWN issues, so it's recommended not to buy it.

Once we've tested it, then we'll be able to say for sure that someone should manufacture it. The issues with the old version weren't noticed and Geeetech jumped the gun (so they didn't perform any testing before sending them out).

I would also beware of the Geeetech units, as they have changed some components from the ones we've specified (eg: MOSFETs for the heated bed & extruders, etc).

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

I have been following the project for a while, great work I will buy one for sure. The processing power of my current Ramps 1.4 is simply not enough.