Working on RAMPS-FD v2…safer, better.
Cool! I want to se it!
I don’t really see there being any need for Marlin/RepetierFirmware package any longer. We should really be doing our best to migrate existing and future 3D printer users to Smoothieware or the BeagleBone Black firmware (Redeem?)
I don’t like to dictate to people what they should or should not use, I think Open Source is all about providing choice and freedom for the users.
I like it!! The ramps seems a little outdated but this is a nice little refresh.
@ThantiK I agree. I think there is going to be an increased focus on the 32 bit processors
guys, which is your opinion about ReprapFirmware?
Anyway, why are we talking about firmware? This is a hardware development. You could run Smoothieware with RAMPS-FD, if you want.
if its 32 bit, its good! We need processors with FPUs though; but I’m biased because of working with DM.
My printer works already with modified RAMPS-FD and modified Arduino Due. The firmware is modified Repetier Firmware, with modified Reprapdiscount Full Graphic Smart Controller. I would like buy the V2
The fastest board I’ve found with a Mega shield connector compatible with RAMPS-FD is Cortex A5 from Atmel http://www.newark.com/atmel/atsama5d3-xpld/dev-board-sama5d36-cortex-a5/dp/07X2224
There’s also SAMV71, 300MHz cortex M7 with double precision FPU from Atmel.
Or even Seeed Arch Max, 168 MHz Cortex M4 with FPU.
There are race horses around, they just need saddling 
So this is v2revB? Why not just v3? Both v1 and v2 have kind of a bad name now due to shitty overseas companies selling them with known issues.
@ThantiK Smoothie doesn’t compile on the ATSAM8XE to my knowledge, which is what the Due has, and that’s what the FD - “for Due” stands for. I am pretty sure the LPC chips that currently run Smoothie don’t have enough IO pins for RAMPS-FD style boards anyway. (I couldn’t tell you what’s portable and what isn’t though.)
RepRapFirmware is good. Works on Due/RADDS now and wouldn’t be hard to put on RAMPS-FD. It’s non-Arduino-IDE and one build with a text-based config like Smoothie. Has some great delta features.
I’m in agreement that Marlin is old and tired. Repetier is still fine. You can’t eliminate them though. Some people will continue to want the hackability of working through the Arduino IDE.
I am a keen 3D printer and my experience with STM32’s leads me to suggest that as a good processor for a new board. There is the hackability (ya just gotta bundle an open source toolchain) and there’s plenty of grunt.
I would ask designers of these boards to stop unneccerily shoving electrolytics right up against hot bits though. Other than that the board rendering looks beautiful.
@Ryan_Carlyle v2 has never been on sale to my knowledge, so why do you think it has a bad name? I think someone else already did a v3. So maybe v4?
I can’t do much about bad manufacturing, since it is Open Source.
If a new name is needed, any ideas? I thought maybe RAMPS-NG ?
I think RAMPS-NG is good. I agree that the FD moniker may lead to some dismiss it. I see you just pushed the schematics to your repo. I hadn’t looked at it too much until now, in part due to what others had said previously. Firmware will be a limiting factor for now for any 32 bit platform. It’s not the hardware holding the platforms back, it’s the software/firmware and integration.
@bob_cousins Check this: http://www.geeetech.com/new-pololu-shield-rampsfd-for-arduino-due-3d-printer-controller-p-770.html Now that I’m looking at it, they’re calling it v1.2, whatever that means.
Word of warning to the community – Geeetech is really terrible about modifying open-source designs and not sharing sources. If you post an incomplete hardware design on GitHub, and Geeetech realizes it exists, there’s a good chance they’ll start selling it without bothering to check if it’s functional/safe/finished. Upon receiving complaints that it doesn’t work, they’ll unilaterally modify the design without respecting the OSHW licences. I’ve seen it multiple times with their boards.
I have a RAMPS-FDv2 board from OSHPark, and it needed modification and to work right (eg thermistor ref voltage circuit) and occasionally had weird hardware glitches that I could never pin down. For example, SD card reads from the GLCD would intermittently fail despite having shielded cables, and I had baffling issues with certain stepper driver sockets having inconsistent motion behaviors. (EG see https://github.com/repetier/Repetier-Firmware/issues/469) Couldn’t ever figure out whether the problems were in the RAMPS-FDv2, or some combination of the GLCD, GLCD adapter, or Due. All I know is that switching to RADDS and a different Due made all the problems go away.
What I’d recommend for any future board is to NOT try to be 5v and 3v3 compatible in the same shield. It makes everything more complicated and adds failure points that are difficult for end-users to troubleshoot (like level-shifter timing issues). Separate shields for separate voltage levels is a better approach.
Hmm, quite a bit of stuff to unpick here… V2 was also an unreleased beta, so if people are selling it on OSHPark they shouldn’t. It’s not just Geeetech who are playing that game then. No one told me they were selling v2 boards - nor that they had designed a v3.
The problem with uncontrolled use goes with Open Source, people need to be aware of that.
I don’t think I received any emails or issues, so if people had problems I wasn’t aware of them. I can only fix things I know about!
The analog reference problem I am aware of and have fixed.
Due is 3v3, LCDs are 5V, so there must be conversion, that is inevitable. RADDS decided to put an onboard level conversion for a dedicated LCD connector, I did not, which would explain that issue. If you use a 5V LCD with a 3v3 board, then expect problems. I have even less control of what addon boards people make or how they use them!
There is no level conversion involved in the stepper signals, they go straight from the Due to the steppers. If you had problems there, it is not due to the design of RAMPS-FD - probably a bad Due.
So from all the things mentioned, the only concrete issue is the analog reference which I’ve fixed, the other things are not related to RAMPS-FDv2.
I urge people if they do have issues, raise them on the github page for the project. It’s the only way they will get properly investigated and hopefully fixed.
BTW, the people selling RAMPS-FD on OSHPark also appear to be in violation of the Open Source license, because they have not published their modified source.
@bob_cousins the rumor going around was that you had 100% stopped working on the design, so there wasn’t much reason to report issues on Github. Glad to hear you’re back at it.
I personally think the Due ecosystem is nearing a dead end at this point. Arduino has stopped making them, so every new Due will be a clone, and the ATSAMX8E is kind of anemic for the stuff people are wanting to do on the advanced firmware side and for high-speed printing. ARM Cortex M3 based boards are already last-gen technology. Both the Smoothieboard and Duet are moving to faster processors for their next rounds of boards.