RAMPS for Due!

Quote
ambrop7
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.

The problem is that it's not enough.Ok it's enough for most prints. But many reprapers report that printing from SDRAM makes better quality prints. If head path is very complicated and speed is high the gcode comand rate is too high and 250000(standart Ultimaker rate) is not enough. So native USB is a must. Yes?

Edited 1 time(s). Last edit at 12/01/2013 03:41AM by karabas.

Quote
karabas
If head path is very complicated and speed is high the gcode comand rate is too high and 250000(standart Ultimaker rate) is not enough. So native USB is a must. Yes?

I haven't had a single time where it wasn't enough. By the way, APrinter supports SD card printing (in a limited way), and if you're printing anything larger you should be using that. That is not to say native USB will not come eventually, but it's not a priority.

Also, if anyone really is hitting the limit with the serial, designing a more efficient protocol is an alternative solution. I'm pretty sure we can get at least 2x more out of the serial port, with efficient binary encoding and not waiting for an 'ok' for every single command. And the thing is, this would not only help serial printing on this particular board, but it would help serial printing on all boards with this firmware (or others if they implement it), and potentially also SD printing, if the protocol has a "stored" version.

Note that I am willing to improve APrinter in different ways, but I need concrete data that something really needs improvement (and see it for myself ), or I might end up wasting my time. So, anyone who can, please do test.

Edited 4 time(s). Last edit at 12/01/2013 06:29AM by ambrop7.

@karabas You should also be aware that the baud rate may not actually be the limiting factor, rather, the planning calculations may be. This is much more likely on AVR boards (you were experiencing your problems on AVR, right?). Planning usually involves expensive floating point calculations. And this is where Due does much better, with the high clock frequency as well as 32-bit arithmetic (it doesn't have a FPU though).

You have a *lot* of ram on the ARM parts. They also are pretty good at things like DMA to / from RAM for serial i/o. I suspect that a fairly big serial buffer would take care of any possible serial port speed issue. It's not speed challenged on average (no where near). The only time you might hit something would be in bursts.

Ok, so prove it:

250,000 baud is roughly 25,000 bytes/sec. In a minute you can run 1.5MB over the link (each way). If the link spends 1/3 of it's time waiting for / getting responses that's a very convenient 1 MB per minute. At least on the type of files I run, a gcode file in the 1MB range takes an 1 hour or more to print.I have a 1.8 MB file printing right now that should finish out in 2.5 hours. Could I pad it with a bunch of stuff to make that not be true - sure. On the files as the slicing program does them, the serial port speed is not an issue on average.

I got my ramps-fd from geeeteck... its going to need some work..

Quick review [dustsreprap.blogspot.co.nz]

Oh the supplied polly fuse is a X16 RF1500

Quote
Dust
Some of the pins are quite bent over. Its obvious this happened at the factory as the 4th pin from the right is far to low and has been soldered in like that!

But otherwise the bending of the pins looks very much like someone was carelessly detaching the board from a Due.

Which Firmware is used für the RAMPS-FD?
EDIT: Sorry found it (R2D2)
[github.com]
Have fun
angelo

Edited 1 time(s). Last edit at 12/02/2013 10:21AM by angelo.

I will produce 100 Radds Shield for arduino due
[www.dr-henschke.de]
[forums.reprap.org]

In 2 Weeks i have the first 5 Shield...
If it is ok, since the end off dec. 2013 100 RADDS Shields.
The Firmware ist Repetier:
[github.com]
It is work, but it was nice, if someone can help to perform and optimize the firmware.

Please PM me, if someone would like to have a RADDS Shield.
Have Fun
Angelo

Quote
angelo
Which Firmware is used für the RAMPS-FD?
Have fun
angelo

Reading though this forum turns up:
- Bobc's port of R2C2
- APrinter (developed by me)
- Perhaps some form of RepetierFirmware, see this post by bobc.

I have yet to test R2C2, I only know that my APrinter works reliably (as far as I can tell) on my improvised setup which should be pin-compatible with RAMPS-FD. So I'll just assume it works on an actual RAMPS-FD until someone tells me otherwise.

Note that R2C2 doesn't support SD card yet, so I have to selfishly recommend APrinter if you want reliable stand-alone printing.

Edited 1 time(s). Last edit at 12/02/2013 10:36AM by ambrop7.

Hi Ambrop7,
cool and thank you for this information.
Maybe i will test R2D2 and aprinter for the RADDS Shield, and maybe the firmware ist better then Repetier?
I think the 32bit more than overdue for the REPRAP Electronic.
Thank you
angelo

Edited 1 time(s). Last edit at 12/02/2013 10:37AM by angelo.

Quote
angelo
Maybe i will test R2D2 and aprinter for the RADDS Shield, and maybe the firmware ist better then Repetier?
angelo

I can't help you with R2D2, the port is being developed by bobc not me. But I can tell you that it's almost trivial to change the pin definitions in APrinter to suit RADDS. I can help you with that if you want.

Hi ambrop7,
do you have Interesst for a RADDS Shield to test it with your APrint Firmware?
If yes, so PM me and i will send you one Shield for free, OK?
Have Fun
angelo

Edited 1 time(s). Last edit at 12/02/2013 10:54AM by angelo.

Quote
ambrop7

Ok, I agree. Is it possible to port easely the code to discovery? I got this board an year ago by mistake...

BTW did you read this thread? About new future ultimaker board [github.com]
STM32F417 mcu.
Ethernet.
USB host for usb-stick
6x TMC260 stepper drivers

Edited 4 time(s). Last edit at 12/02/2013 02:48PM by karabas.

Quote
karabas
Ok, I agree. Is it possible to port easely the code to discovery? I got this board an year ago by mistake...
BTW did you read this thread? About new future ultimaker board [github.com]

Probably. But if you expect me to do it, I'd need the schematic (which doesn't seem to be available), and you'd need to give me one such board, as a gift

How did you manage to get this board in the first place? It doesn't seem to be released.

Note: porting APrinter to the board does not imply that there would suddenly be Ethernet support etc.. It may be a while before that happens.

EDIT: when you say "I got this board an year ago by mistake", which board is that, "discovery"? So not the future Ultimaker board?

Edited 5 time(s). Last edit at 12/02/2013 03:33PM by ambrop7.

Repetier for due firmware https://github.com/biocode3D/Repetier-Firmware-Due

I know it compiles.. but thats as far as ive gotten with it.

annother new board [www.reprappro.com]

But its the same ARM processor as the Arduino Due, so its firmware [github.com] should be able to be ported esily to ramps-fd

Quote
Dust
Repetier for due firmware https://github.com/biocode3D/Repetier-Firmware-Due

I know it compiles.. but thats as far as ive gotten with it.

I don't have a fully working Repetier for RAMPS-FD yet but I have pushed changes made to date to https://github.com/bobc/Repetier-Firmware. Make sure to select to "development" branch. This includes a config for RAMPS-FD and all latest upstream Repetier changes.

Homing probably should work. Heaters need work to invert the logic for the FETs, so word of caution - all FETs are turned ON by default so unplug heaters before loading firmware!

---

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
Dust
annother new board [www.reprappro.com]

But its the same ARM processor as the Arduino Due, so its firmware [github.com] should be able to be ported esily to ramps-fd

I've given it a quick look but it would need some work. Specifically many files are missing (and I haven't seen docs on where to get them). Additionally, the pin handling is messed up, and it's non-trivial to change pins. The problem is that even though the code is designed to be build with Arduino, it doesn't use the standard Arduino pin functions. Instead it defines a board-specific pin functions, including a board-specific pin table, which only has a subset of all MCU pins. I didn't bother myself with it further. Reference: google for SamNonDuePin.h which is one of the missing files.

Quote
Dust
annother new board [www.reprappro.com]

But its the same ARM processor as the Arduino Due, so its firmware [github.com] should be able to be ported esily to ramps-fd

I hope so, I've been watching their git repo. I haven't looked into details yet.

I think Duet is a good complement, it's an all-in-one board, although more expensive I think. Ethernet is a useful addition, I'm still hoping for a Due with ethernet.

I'm also hoping to get a Smoothie-RAMPS combo going as well.

---

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

Hi

The additional libraries for the RepRap Firmware are here:
[github.com]

I will ask Adrian to update the readme.

The main reason the pins handling as it is is because not all SAM3X8E pins are defined on the Arduino (or arduino defines them as a simple digital pin and does not expose the required peripheral function eg PWM). In the future we might combine them all into one replacement variant library. Once we discovered that we wanted to use pins that were not in the Arduino Due variant definition this was the best way to go as a start point.

The arguments that apply to all in one boards vs RAMPS/Sanguinololu boards with chip carriers apply and there are advantages and disadvantages to both. The good thing about basing it on the Due is that the firmware development on projects such as the RAMPS-FD can complement each other with the same base platform.

If you want to use the Ethernet part in a Due platform then there are 3rd party Due variants that expose the ethernet pins.

Cheers

Tony

blog.think3dprint3d.com

Edited 1 time(s). Last edit at 12/02/2013 07:38PM by T3P3.

Quote
T3P3
If you want to use the Ethernet part in a Due platform then there are 3rd party Due variants that expose the ethernet pins.

Do you have any specifics? The only ones I am aware of are TAIJIUINO Due which would not be compatible with RAMPS, and EtherDue which is promised "soon".

---

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
T3P3
The additional libraries for the RepRap Firmware are here:

Hey. Thank you for this information, I'll give it another shot.

As far as pins are concerned, in my firmware I use some advanced C++ template metaprogramming to get nice and efficient code; link. Don't mind the Context, Position and other boilerplate. Though this isn't exactly easy to integrate. It would require more template usage, such as type lists to make and work with a list of pins (using StepPins=MakeTypeList< FooPin, BarPin, BazPin > ) and to implement a helper function setStepPin(int index, bool value), index only being known at runtime.

On the other hand, why don't you just include all pins in your SamNonDuePin.cpp - preferably with the same numbers as Arduino, and add extra numbers for those that were missing? I don't think it's a good idea to require (mostly) duplicating this code for every possible board. You can still define board-specific aliases for pins, of course.

Edited 3 time(s). Last edit at 12/02/2013 08:21PM by ambrop7.

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

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.

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).

Quote
ambrop7

Quote
karabas
Ok, I agree. Is it possible to port easely the code to discovery? I got this board an year ago by mistake...
BTW did you read this thread? About new future ultimaker board [github.com]

Probably. But if you expect me to do it, I'd need the schematic (which doesn't seem to be available), and you'd need to give me one such board, as a gift

How did you manage to get this board in the first place? It doesn't seem to be released.

Note: porting APrinter to the board does not imply that there would suddenly be Ethernet support etc.. It may be a while before that happens.

EDIT: when you say "I got this board an year ago by mistake", which board is that, "discovery"? So not the future Ultimaker board?

No it's not Ultimaker board but well known Discovery stm32 board. I bought it thinking that it's easy to port marlin to it.

Ummmm .... errrr ....

I've been down the road with ethernet on an ARM. You *really* need some sort of an OS to make it do more than simple stuff. As soon as you get into a real TCP/IP "multiple packets in flight" situation things get pretty nutty with managing all the states. UDP you can do all day long with next to nothing. Simple send and forget TCP/IP (which isn't really TCP/IP) you can do easily. The real thing - not so much.

Hi,
this is a Topic for RAMPS-FD.
I Think, it is OK to speak here in general about the Arduino Due Firmware in this Topic.
For all PM writer, if you will have Information about the RADDS-Shield please show this Topic:
[forums.reprap.org]

At least some pictures and now please i answer only specific Question about the RADDS-Shield in the german Topic.




Have Fun
angelo

Edited 1 time(s). Last edit at 12/04/2013 04:14AM by angelo.

I'm gonna keep an eye on this, I have a ramps-fd from geeetech on the way. going to be using it on my udoo, (armv7 quad core) + ardunio due all one one board

Some updates...

Still waiting for a board from Geetech...I guess Santa is busy.

I have made further changes to Repetier for Due to handle inverted heaters, and I can now do some extrusion. 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.

There also seems to be a problem with power shutdown, after a few minutes idle the message "TargetExtr:0" is sent repeatedly on the comms causing pronterface to hang.

So I am a bit stuck with Repetier, but I have pushed all the changes I have made so far to my github [github.com] ("development" branch) if anyone wants to have a go. Watch out for some odd settings in configuration.h

---

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
uncle_bob
Ummmm .... errrr ....

I've been down the road with ethernet on an ARM. You *really* need some sort of an OS to make it do more than simple stuff. As soon as you get into a real TCP/IP "multiple packets in flight" situation things get pretty nutty with managing all the states. UDP you can do all day long with next to nothing. Simple send and forget TCP/IP (which isn't really TCP/IP) you can do easily. The real thing - not so much.

Well, that all depends on what you mean by "some sort of an OS". There is nothing magic about an OS, it is just software which you could equally write yourself, given time. (I guess preemptive multi-tasking is a bit magic ). 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. I guess it is also handy to have a common pool of memory buffers, but all the rest you typically find in an RTOS is really not essential.

I tried FreeRTOS but it really comes with a lot of baggage which is not very useful and quickly eats RAM. I believe the RepRapPro firmware just uses a simple cooperative multitasking scheme.

---

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