Project: Teacup Firmware

Using a FPGA to generate steps at a hardware level is definitely the best way to produce a low-jitter series of steps. Low jitter means, in theory, smoother, potentially faster motion and maybe better, more precisely made prints. It will definitely allow higher step rates to be generated. Whether or not this actually translates into the production of better objects remains to be seen.

The potential downsides of a FPGA, as I see them, are: the small number of people comfortable working with them, and the extra expense. If the quality of the resulting objects is noticeably better these issues will be moot. I'd love to see someone attempt to simply replace the Arduino with the Open Logic Sniffer board. Regardless, I think this is a very interesting project.

I have been attempting to make this firmware work with my Mega/Pololu stepper based Repstrap. After being unable to make a Z-axis move I think I tracked it down to the steps/mm being too high. Using a M8 threaded rod directly connected to a 200 step/rev motor at 1/16 microstepping makes my steps per MM = 2560. When the dda.c create function calculates the move distance it is always 0, since UM_PER_STEP_Z = (uint21_t)((1000.0/2450)+0.5) = 0. Taking that distance=0 into the move speed ends up locking/crashing the firmware some place after create.

I can see a fix using nanometers per step instead of micrometers, but that looks to have a big effect on the move speed logic and int32 limits.

Jeremy

Quote
Peter Stuge
I'm also a libusb maintainer, and I am quite allergic to using USB only as a dumb serial port. USB is a packet bus, and applications can usually benefit tremendously from exploiting that.

For my part I'd love to get rid of the serial port stuff either, but how would one go directly to USB with an ATmega processor? There's stuff like V-USB, but that looks a bit hackish and I'm not sure how this interferes with running the steppers.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
jv4779
UM_PER_STEP_Z = (uint21_t)((1000.0/2450)+0.5) = 0

Hmm. Well spotted. At the first glance I wonder how this could slip in, as when I started with FiveD on Arduino, STEPS_PER_MM was set to 3200 by default ...

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Triffid has just put a fix into the repository, so pulling sources again should help.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

just pushed a couple of patches which try to keep UM_PER_STEP as a floating point value until the last possible moment before final compilation. please test

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Best way to loose the serial port stuff is to go Ethernet but you will then loose everyone who has not got and doesn't need networking.

The benefit to serial is it is a lowest common denominator.

The really best route is to add other methods of communication in addition. Then you use the one you want.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

gcode is essentially a packet-based protocol - each line/command is a packet. With full access to the usb protocol (uno, arm, etc), we have the possibility of showing up as a more appropriate device without a baud rate and communicating with the main chip via super fast SPI. this would allow blazing fast comms without worrying about baud-related issues.

On the usb side, there are heaps of possibilities, least of which is using usb's built in flow control, and at best we could provide a total interface to the firmware's internal state.

There's also no reason you couldn't stick an xport or similar on instead if you like ethernet, or making your own with a shield and another arduino.


At the end of the day, we still need a microcontroller which can concentrate on the hard real-time tasks of generating stepper pulses and the not quite so critical task of managing temperatures with some sort of interface to something capable of turning a 3d model into a series of movements, and the more people that use and debug a particular method, the more reliable that particular method will become.

That's why at the moment I'm personally concentrating on lowering the barrier to entry and providing a platform for other efforts, rather than doing fancy things which only a few can or will use at this point in time.

I welcome patches for fancy stuff, as long as the basic firmware will still run on a '168.

ps: the hard real-time requirements of soft-usb will absolutely conflict with the hard real-time generation of steps, most likely to the detriment of the usb, so any usb solution will need either a hardware port and buffering, or a separate chip. In either case we should be able to easily drop a suitable call in between the main loop and the gcode parser.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Peter Stuge Wrote:
-------------------------------------------------------
> Hi. I just wrote a really long post about the work
> we are doing at Labitat, the hackerspace in
> Copenhagen, but then disgusting web technology ate
> my complete post. I absolutely detest web forums.
> Is there a mailing list

There is the main reprap-dev list Here
I would suggest having a read of the archives as there is a
lot of talk about electronics and firmware on there at the moment.

There's are also some people that are all ready working on code for the LPC1768.

Matt

Triffid _Hunter sir I really could'nt agree more.

There is a very real case for keeping the Host/Human Interaction separate from the Machine control. To do other wise is to invite problems due to the fact that the two areas have conflicting priorities.

A serial interconnect ( whether from Ethernet or USB ) is a very good common denominator and you have the ability to throttle the input stream to something that doesn't conflict with the timing priorities of producing smooth motion.

Given this (and conversations here in the electronics forum) it is worth considering keeping your firmware very much on the path it is and creating a parrallel work/effort to make a Host/HID board perhaps arduino based. To include Display, Keypad, SD Card, Ethernet & USB purely as a device that can then buffer and offer up a serial stream to the excellent machine control you are doing here.

So perhaps a second 168/328/uno as a Host/HID machine console. That is of course optional because your own firmware can be used without it via USB/serial. Being optional also allows for folk to start at a lower entry level and build up their machine/capability in stages.

I think Julie (Sheep) has recognized this sometime ago and has done some work towards something similar but using an AVR butterfly. I think it is posted up on Github.

It is interesting that folk stampeding towards micro-stepping as a panacea are beginning to realize some of it's limitations particularly vis a vis step rates.

Putting too much onto a single processor will only make this worse.

Thoughts for what they are worth

Edited 2 time(s). Last edit at 10/21/2010 03:52AM by aka47.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Just a note to the fans of the project: building with the Arduino IDE is currently broken.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

what is the IDE's problem this time? Is there a feasible way to hijack the IDE's toolchain without wrangling its convoluted build process?

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Well, one problem is, the IDE simply collects all .c files available, compiles them and links them together. Accordingly, it picks up the simulator code as well.

Another one is, it isn't happy with the ATOMIC_BLOCK macro:

In function 'analog_read':
error: 'for' loop initial declaration used outside C99 mode

This is Arduino 0018.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I think we should consider doing a release branch. FiveD on Arduino as of a week ago worked well for my needs, so release v0.9 should be fine. v1.0 could include Gen3 compatibility.

Over the recent days there were a lot of discussions on the reprap-dev mailing list about how to enhance the official FiveD firmware. Most of the problems these guys try to solve, e.g. pauses due to insufficient communications, are much better, if not vanished at all, with FiveD on Arduino already. So I try to advertise this firmware there.

Pushing big heaps of untested and partly obsolete changes (sorry for this opinion about the recent patchset introducing the simulator) out isn't helpful in this situation. For the above people source has to be reliable and reliability requires small patches at a time, together with extensive testing. To some extent, new features should be even avoided.

Please don't get me wrong, I consider this simulator thing an excellent idea and I'm more than happy about it. This gets us a lot closer to a look-ahead algorithm. Branching out a release should give us the playground needed for such work.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

okay, so let's revert master to a stable/release branch and move the recent stuff to a development branch.. how does that even work with git? I think a0543d33 is the commit to start off as our release candidate until we've tested the more recent stuff and decided which commits to include.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

It would probably be easier to create a new branch for the release code, since it will be older than what's already on master. Otherwise you'd have to rewind the master branch, and rewinding in a public repo is frowned upon. I think you want something like:

git branch release a0543d33
git push github release:refs/heads/release

created new branch "release-candidate" from commit a0543d33, please test newer commits and report which ones you think should be included. We'll branch again when we're ready to release and keep using release-candidate as a development branch.

I think we should eventually have a master branch that's a fairly stable, usable version of the firmware although I'm not entirely sure how to transition to that from where we are now.


I think the features in unified_timer and multi_temp branches should be in our first release although not necessarily the way I've implemented them. please have a play with them- I've written them while unable to do any useful testing so they're mostly guesswork.


What's the best way to maintain a release feature list, so we can keep track of what we still need, what's done and what's being tested?

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

The gcode parser in grbl is significantly simpler than ours- is it just because it's using strtod and buffering the line, or are there things for us to learn from it? Do we want to try buffering lines, knowing that it'll take slightly longer before a command can be executed?

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Given that the Gcode spec on the reprap wiki has error correction and re-transmit (Line number and checksum). It is a little dificult to see how to do non buffered line at a time reliably if the comms becomes a bit noisy/shaky.

When I have got a machine together and rehashed my touch probe work I think I would like to contribute some code for probing. the original probe/pen holder stuff is a little heath robinson and I have some ideas for better electronics etc.

[reprap.org]

The DIY board design for 644 and 1284 that I have published also has a cloning capability that I could do with expanding on. (if it works that is, just random hardware design at the moment)

[aka47.adsl24.co.uk]

This is the board that I will be using with this firmware to drive the Huxley I am building.

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Is this the place to ask questions about getting the "FiveD on Arduino" to run/compile? If it is I have the following questions:

- Should I use only one of the lines as Either HEATER_PIN Or HEATER_PWM

// comment out the ones you don't have
//#define	HEATER_PIN						DIO6
#define	HEATER_PWM						OC4A

//#define	FAN_PIN								DIO5
//#define	FAN_PWM								OCR0B

Would there be an expected difference in hardware? Either way I use a MOSFET (HUF75337) to control the on/off/pwm of the heater.

- When compiling in the Arduino IDE, I still get "ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {" as an error.
I tested on IDE 0018 and 0021, and did a fresh git clone just minutes ago
.... hmmm found an answer to this my self. Need to switch to a different branch. (Well, there are MANY new things to learn, in order to to keep up with the latest in development)

- How would I go about reading whats new in the source? Is there some kind of tracker? Issue/bug tracker?

- Might I suggest that optional names be mentioned somehow in the makefile, maybe like:

##############################################################################
#                                                                            #
# Change these to suit your hardware                                         #
#                                                                            #
##############################################################################

MCU_TARGET = atmega1280
#MCU_TARGET = atmega328p
#MCU_TARGET = atmega168 ?
F_CPU = 16000000L

Or there could be a link (or other clue) to a page that explains how to find the different options.

By the way, I am testing on an Arduino Mega, with a Rapatan Shield (using pololu stepper drivers and HUF75337 to manage extruder heater and bed heater).

I seem to recall reading somewhere that somebody-or-other had gotten this running on an ARM.

casainho, I think.
Where do I find the code? Have you gotten it working?

---

--
I'm building it with Baling Wire

MrAlvin:
you need to specify both heater_pin and heater_pwm if you want pwm output, otherwise the PWM will be generated but the pin will still be an input and no signal will reach your mosfet.
note that you must select one of the timer0 pwm output pins if you want pwm, and set heater_pwm appropriately.

If you set only heater_pin but not heater_pwm, you may use any pin but you will only have on/off, although you still get to use PID.

that comment should be made more clear- it refers to the fact that commenting out the FAN_PIN and FAN_PWM removes fan support.

As for keeping up with changes, this forum thread and git's own issue trackers and commit logs are about it

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Quote

- Might I suggest that optional names be mentioned somehow in the makefile, maybe like:

Excellent idea. Pushed that to master and release-candidate.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

What is the best way to submit patches? I am assuming that I am the first to try termistor temp control since it didn't work at all. My setup uses seperate enable pins for each stepper so I have a patch for that too.

Quote

What is the best way to submit patches?

Fork the thing on GitHub and send a pull request or put the result of a git format-patch here or into the Wiki. Some instructions: [reprap.org]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I got stepper pulses however they are very slow which means my void setTimer(uint32_t delay) should have some problem.

What are the delay units? us? ns? And why the code always do setTimer(dda->c >> 8); (dda->c / 256)??

If I get the stepper pulses working, then I will have the port finished for my ARM 32bits board :-)

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

I'm having a problem with the program space functions. Anything which uses pgm_read_byte or pgm_read_word doesn't work.

I noticed it when I was debugging my endstops (endstop code is commented out for some reason) and noticed the "M114" command. So I issued it, and got only "Nok" as a response. I thought that maybe something was wrong with the sersendf functions, but eventually decided that it's just pgm_read_byte that doesn't work. Serial_writeblock_P exhibits the same behavior, writes garbage.

Perhaps I'm compiling with an incorrect setting somewhere? -mmcu=atmega168 should be correct for the arduino diecimila. I looked at the assembly generated, found the header file that defines things (/usr/lib/avr/include/avr/pgmspace.h) and as far as I can tell it's doing what it should.

Any why are endstops commented out, anyway?

---

--
I'm building it with Baling Wire

I was wrong about pgm_read_byte. I undefined the "HEATER_PIN" so that debug stuff would fit, and M250 works fine, but M114 still prints only a ":". I don't know why yet.

Still don't know why endstops where disabled, but mine aren't working yet so maybe that's why? When I enabled the endstop code, sometimes the machine goes endlessly when given "G1X10F100". Must be missing the comparison current_position.X != dda->endpoint.X somehow?

---

--
I'm building it with Baling Wire

Quote

What are the delay units?

Clock ticks, or 1/16,000,000 seconds. You can adjust this by using the correct F_CPU.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote

Still don't know why endstops where disabled, but mine aren't working yet so maybe that's why?

Exactly. Endstop handling isn't completed or tested, yet. I'd check wether the bit representing the endstop actually changes as expected and if it does, review wether the comparison is done right. You can serial_writechar() from the interrupt.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY