Project: Teacup Firmware

Quote

the problem being that the DDA_QUEUE will process N0, N1, N3-N5 skipping N2 until it is resent by the host. in which case the host seeing a "rs" request resets the line numbers it is sending to start with the "rs" request line. In effect resending lines N2-N5. if each of these lines are check-sum correct, then the dda will process all of it in this order. N0-N1,N3-N5,N2-N5 which I image would turn out to be a blob on the real print.

OK, so Repsnapper assumes the firmware would actually sort lines by their line number. It's the first time I've heard of such a feature and I'm a bit wondering what might be the use of sending four lines "at a time" (in parallel?). Especially as in serial communications, informations are never sent in parallel.

Regarding implementation, that's certainly possible, but not without performance penalty. A trivial implementation would be to ignore further lines until N+1 comes along, but then there are GCode generators which send line numbers in steps of 2, 5 or 10, so N+1 would never arrive.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

That's what i think i have implemented for repsnapper, it also sends -1 lines as well which I had to process differently.
I will check what I wrote tonight as i am getting a new 6 pack of beer and plan to code. interesting about the +2 line numbers 5D (at least the code source I have) increased N_expected to N+1 so that is what I assumed was the norm.

my next thought was to also go in and put a reasonably check in place as well. The night before last my Arduino for no apparent reason sent a Start after 4k+ lines of code during testing, then later on it sent a rs 0 after 2k lines. I'm thinking about storing the last processed and printed target line number somewhere to check after system failure and on resend request for faulty request checking and maybe pausing restarting commands later. I also just ordered a 128x64 LCD so I would like to know what line was just printed from the DDA QUEUE on screen. ...

Edited 1 time(s). Last edit at 01/06/2011 12:06PM by Architect.

I am going to copy release-candidate-triffid over master to reduce confusion for new testers- can any of you think of a reason why that's not a great idea?

---

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

Quote

I am going to copy release-candidate-triffid over master to reduce confusion for new testers- can any of you think of a reason why that's not a great idea?

I think reducing the number of branches is indeed a good idea.

On my part I plan to add the fixes made by Jacky2k (see the Gen7 Electronics thread) onto the release-candidate branch, then publish this as Release 0.7. This release is then known to work completely (with heater, extruder, etc.) on at least one set of electronics in combination with RepRap Host.

There are quite a number of people apparently using FiveD on Arduino successfully now (including me), but all these combinations of electronics and firmware are somewhat unknown and fail on slightly different combinations. Even minor incompatibilities tend to drive people away pretty quickly, so publishing known-to-work combinations seems essential.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Architect,

N_expected is N+1, because it's the lowest line number the next line should have. The next line number can be higher just as well.

All that line numbering is fine and dandy, but I've yet to hear about a mechanism for recovering from mismatching line numbers. Currently, FiveD on Arduino simply sends an error back and ignores that line, but neither RepRap Host nor any firmware can deal constructive from such a situation, AFAIK. Once numbering is messed up, the build fails.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

merge was messy, and lots of history vanished because I have little to no idea of what I'm doing.. anyway, done now, have fun all

---

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

Traumflug Wrote:
-------------------------------------------------------
> There are quite a number of people apparently
> using FiveD on Arduino successfully now (including
> me), but all these combinations of electronics and
> firmware are somewhat unknown and fail on slightly
> different combinations. Even minor
> incompatibilities tend to drive people away pretty
> quickly, so publishing known-to-work combinations
> seems essential.

Even for me, because I want to keep updating my port for ARM of this "FiveD on Arduino".

---

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

[www.3dprinting-r2c2.com]

Uh-oh, did I delete two months of the master branch now?

What happened? I started to commit Jacky2k's patches to the release-candidate branch. As I want to get these fixes into the master branch as well, I tried on this also, but messed up severely (too much changed in these two months).

So I fixed my local release-candidate branch and pushed that. However, not only this branch, but the still messed up master branch was pushed as well *ARGH*. Unintentionally, of course. Lots of nonsense in the Repo.

here and here I learned one can take back a push as long as nobody else pulled the new commit, yet. So I did:

git checkout master
git reset --hard master^
git push origin +master

My messy commit went away indeed, but if I recall correctly, there was more stuff visible two hours ago than that what's available now. Could somebody please verify the master branch's commit log seen locally with the one on Github?

Thanks.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I'm anxious to try this firmware and have been messing with it for a couple hours but have hit a snag installing the release-candidate-triffid branch. It seems to compile without problem but then throws this error:

Binary sketch size: 12597 bytes (of a 63488 byte maximum)
avrdude: ERROR: address 0x820003 out of range at line 790 of /tmp/build8661438443058193548.tmp/FiveD_on_Arduino.cpp.hex
avrdude: write to file '/tmp/build8661438443058193548.tmp/FiveD_on_Arduino.cpp.hex' failed

I've been able to install other firmwares including the gen3 branch. Any assistance is appreciated.

traumflug, check upstream now, I applied your patch to my locals and forced a push

sliptonic, I've had a couple of people show me that error recently, seems to only occur with arduino IDE. I have absolutely no idea what it's about. closest thing I can find is the eeprom contents that hold the heater PID values. Why avrdude would be choking on eeprom data when it's supposed to be writing flash I don't know. Another possibility is the fuses. warrants further investigation by those who can actually reproduce this

---

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

Try commenting/ifdef'ing out all of the code in the fuses.h file and rebuilding the project. That should fix the installation problem you are seeing, at least until a better solution is found.

II am just starting, I have downloaded the git followed the instructions on http://reprap.org/wiki/FiveD_on_Arduino and getting this error when compiling on arduino-0021 and arduino-0022

Any ideas? would be great
Max

simulation.c:28: error: expected ‘)’ before ‘cond’
simulation.c:39: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘sim_interrupts’
simulation.c: In function ‘sei’:
simulation.c:42: error: ‘sim_interrupts’ undeclared (first use in this function)
simulation.c:42: error: (Each undeclared identifier is reported only once
simulation.c:42: error: for each function it appears in.)
simulation.c:42: error: ‘true’ undeclared (first use in this function)
simulation.c: At top level:
simulation.c:53: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘direction’
simulation.c:54: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘state’
simulation.c:61: error: expected ‘)’ before ‘pin’
simulation.c:95: error: expected ‘)’ before ‘pin’
simulation.c:100: error: expected ‘)’ before ‘pin’

Quote
Triffid_Hunter
traumflug, check upstream now, I applied your patch to my locals and forced a push

Thanks a ton, Triffid. Lesson learned.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

avrmax,

the master branch (default) currently doesn't work with the Arduino IDE, AFAIK. Try the release-candidate branch, i.e. issue a "git checkout release-candidate" before compiling.

If you want to use the master branch, adjust the Makefile to your environment and compile/upload with Make.


P.S.: I just fixed the "Simple Installation" in the Wiki, the git command sequence given was incomplete.

Edited 1 time(s). Last edit at 01/08/2011 06:00AM by Traumflug.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thanks, that sort of got it going...

I checked out the release-candidate branch, and got the error below on arduino-0022 and with make!
greping around a bit looks like DIO15_WPORT is declared in arduino_644.h and not in arduino_168_328p.h
so I changed my Makefile back to atmega644p and make works, but not arduino-0022, so I downloaded the http://sanguino.cc and installed the software, restarted the arduino ide and changed to the sanguio board and everythings compiling fine!

So I am left pondering...
Is FiveD brocken for arduinos or do I need to get a sanguino to use FiveD?
Or can FiveD be fixed for 168 arduino?
Or ...

Max

mendel.c: In function ‘io_init’:
mendel.c:37: error: ‘DIO15_WPORT’ undeclared (first use in this function)
mendel.c:37: error: (Each undeclared identifier is reported only once
mendel.c:37: error: for each function it appears in.)
mendel.c:37: error: ‘DIO15_PIN’ undeclared (first use in this function)
mendel.c:37: error: ‘DIO15_DDR’ undeclared (first use in this function)
mendel.c:38: error: ‘DIO18_WPORT’ undeclared (first use in this function)
mendel.c:38: error: ‘DIO18_PIN’ undeclared (first use in this function)
mendel.c:38: error: ‘DIO18_DDR’ undeclared (first use in this function)
mendel.c:39: error: ‘DIO20_WPORT’ undeclared (first use in this function)
mendel.c:39: error: ‘DIO20_PIN’ undeclared (first use in this function)
mendel.c:39: error: ‘DIO20_DDR’ undeclared (first use in this function)
mendel.c:41: error: ‘DIO21_WPORT’ undeclared (first use in this function)
mendel.c:41: error: ‘DIO21_PIN’ undeclared (first use in this function)
mendel.c:41: error: ‘DIO21_DDR’ undeclared (first use in this function)
mendel.c:44: error: ‘DIO19_WPORT’ undeclared (first use in this function)
mendel.c:44: error: ‘DIO19_PIN’ undeclared (first use in this function)
mendel.c:44: error: ‘DIO19_DDR’ undeclared (first use in this function)
mendel.c:47: error: ‘DIO23_WPORT’ undeclared (first use in this function)
mendel.c:47: error: ‘DIO23_PIN’ undeclared (first use in this function)
mendel.c:47: error: ‘DIO23_DDR’ undeclared (first use in this function)
mendel.c:48: error: ‘DIO22_WPORT’ undeclared (first use in this function)
mendel.c:48: error: ‘DIO22_PIN’ undeclared (first use in this function)
mendel.c:48: error: ‘DIO22_DDR’ undeclared (first use in this function)
mendel.c:49: error: ‘AIO6_WPORT’ undeclared (first use in this function)
mendel.c:49: error: ‘AIO6_PIN’ undeclared (first use in this function)
mendel.c:49: error: ‘AIO6_DDR’ undeclared (first use in this function)
mendel.c:67: error: ‘DIO16_WPORT’ undeclared (first use in this function)
mendel.c:67: error: ‘DIO16_PIN’ undeclared (first use in this function)
mendel.c:67: error: ‘DIO16_DDR’ undeclared (first use in this function)
mendel.c:68: error: ‘DIO17_WPORT’ undeclared (first use in this function)
mendel.c:68: error: ‘DIO17_PIN’ undeclared (first use in this function)
mendel.c:68: error: ‘DIO17_DDR’ undeclared (first use in this function)

I commented out everything in fuses.h and it did get me around the problem above. I got both the extruder and host parts to build and install from the release-candidate-triffid branch. ( Looks like this was merged with master this morning and I'm up to date.)

Now when the host resets, nothing happens. The stepper drivers don't power up and there's no lights on the controller. From repsnapper, I can connect to the host and issue a M115 and the host will reply with the firmware version and status but nothing else works.

I've been through the config.h files and the Makefile thoroughly and they match my hardware to the best of my understanding. But can't shake the feeling I'm missing something basic.

avrmax Wrote:
-------------------------------------------------------
> So I am left pondering...
> Is FiveD brocken for arduinos or do I need to get
> a sanguino to use FiveD?
> Or can FiveD be fixed for 168 arduino?

168 and 328 don't have a DIO15 port! only 14 DIO (DIO0 - DIO13) and 6 analog.

I personally use this on a '328, as that's all I have!

sliptonic Wrote:
-------------------------------------------------------
> I commented out everything in fuses.h and it did
> get me around the problem above.
thanks for that, I'll have to work out how to disable fuses for those who don't need them


note to all, release-candidate-triffid, release-candidate and master have now all been merged, may be some mess left over but it should make things simpler in the long run

---

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

Triffid, Traumflug, other devs, you want to look into [github.com], it's the future of host side comms. They are especially interested about the current APIs and the best possible API. And issues about line numbering, resends etc.

already contacted Ralith about a firmware-level compatibility layer module thingy to close the loop

---

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

Traumflug Wrote:
-------------------------------------------------------
> the problem being that the DDA_QUEUE will process
> N0, N1, N3-N5 skipping N2 until it is resent by
> the host. in which case the host seeing a "rs"
> request resets the line numbers it is sending to
> start with the "rs" request line. In effect
> resending lines N2-N5. if each of these lines are
> check-sum correct, then the dda will process all
> of it in this order. N0-N1,N3-N5,N2-N5 which I
> image would turn out to be a blob on the real
> print.
>
> OK, so Repsnapper assumes the firmware would
> actually sort lines by their line number. It's the
> first time I've heard of such a feature and I'm a
> bit wondering what might be the use of sending
> four lines "at a time" (in parallel?). Especially
> as in serial communications, informations are
> never sent in parallel.
>
> Regarding implementation, that's certainly
> possible, but not without performance penalty. A
> trivial implementation would be to ignore further
> lines until N+1 comes along, but then there are
> GCode generators which send line numbers in steps
> of 2, 5 or 10, so N+1 would never arrive.

I don't think RepSnapper assumes any sorting, just that the firmware would flush it's buffer on every resend request. Maybe it shouldn't assume that though.

Triffid_Hunter Wrote:

>168 and 328 don't have a DIO15 port! only 14 DIO (DIO0 - DIO13) and 6 analog.
>I personally use this on a '328, as that's all I have!

As "168 and 328 don't have a DIO15 port"
Is it compiling ok on a 328?
If it is, what is the diff between the checked out release-candidate and your compile?
Or what can I be doing wrong...

Having never got it to compile, and not knowing if it is a state to compile on a 168,
any help to get it to compile much appreciated.

avrmax Wrote:
-------------------------------------------------------
> Is it compiling ok on a 328?
> Or what can I be doing wrong...

I started this project on a '168, and now test on a '328. All testing on '644 and '1280 has been done by others.

It compiles fine for '328 with a valid config, so show us your config.h

---

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

Great thanks got it to compile.

1. changing the first MCU_TARGET = atmega168 in the Makefile,

2. I missed the comit out GEN3 and TEMP_INTERCOM (don't know yet what I will use for my temp sensor) in the config.h

< #define GEN3
> //#define GEN3

< #define TEMP_INTERCOM
> //#define TEMP_INTERCOM

---

Then I got this error on arduino-0018 and arduino-0022:

Binary sketch size: 12043 bytes (of a 14336 byte maximum)
avrdude: ERROR: address 0x820003 out of range at line 756 of /tmp/build6774123432817503196.tmp/FiveD_on_Arduino.cpp.hex
avrdude: write to file '/tmp/build6774123432817503196.tmp/FiveD_on_Arduino.cpp.hex' failed

3. So changed /dev/arduino to ttyUSB0 yes I should do it the other way round and create a udev rule like:

SUBSYSTEMS=="usb", ATTRS{product}=="FT232R USB UART", ATTRS{idProduct}=="6001", ATTRS{idVendor}=="0403", NAME="%k", SYMLINK+="arduino", MODE="0660"

one line in new file /etc/udev/rules.d/10-local.rules from http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1206629607
But I have always been a bit lazy for that sort of thing...

4. Changed PROGBAUD = 19200

#PROGPORT = /dev/arduino
PROGPORT = /dev/ttyUSB0
# atmega168
PROGBAUD = 19200
# atmega328p, 644p, 1280
#PROGBAUD = 57600

5. Change in fuses.h

#if defined (__AVR_ATmega168__)
FUSES = {
  /*    .low = FUSE_CKSEL3 & FUSE_SUT0,                                                                                                                                 
        .high = FUSE_SPIE
N,                                                                                                                                             
        .extended = FUSE_BOOTSZ1 & FUSE_BOOTSZ0,                                                                                                                        
  */
};

6. Yikes! error
avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.

found in covered in [www.arduino.cc]
Wrong avrdude used changed FiveD Makefile to :

#AVRDUDE = avrdude
#AVRDUDECONF = /etc/avrdude.conf
AVRDUDE = /home//arduino/arduino-0022/hardware/tools/avrdude
AVRDUDECONF = /home//arduino/arduino-0022/hardware/tools/avrdude.conf

Yippee! Got 100% with $ make program

7. got the sender.sh waitfor: No such file or directory
just removed the waitfor line seemed fine!

So Now I just need to figure out how to test the arduino side of things.

Thanks, feels like I am slowly going in the right direction now...

thanks for the comprehensive overview of first-time pitfalls, with solutions! good luck in your explorations

---

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

Can you upload your makefile here? I'm just about to the point that I need to work on it too. Unfortunately, I'm lazier than you said you were. I'd rather start from one I think will work for me!

Been working on my hardware and not software the last few days and i know this topic has been beaten here badly but i need some rudimentary understanding. Are the OPTO sensors hard kills to the motors or are they only used in the firmware to kill the motor when they have been activated. i ask cuz i am debating whether to use them or not. and to ask it a different way when the OPTO's are activated do they cut the signal to the motor or in the firmware is the signal processed and the steppers stopped?

- nutty questioned but as i haven't seen anything in the firmware that would help me understand I thought i would ask here before I start thinking about coding for it.

-trout

If you look at the Stepper Motor Driver 2.3r1 schematic you see that that the MIN and MAX signals are simply passed to the 10 pin connector going to the Motherboard, ergo they are only inputs to the firmware and it must act when the signal changes.

Edited 1 time(s). Last edit at 01/12/2011 11:56AM by rhmorrison.

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

thanks for the pointer. Where stands any development on using the opto stops in the latest master version of the firmware?
Is anyone currently working on a solution? if not I will put it up on my todo list.
thanks,
Karl

Well I have got down to the following changes, this seems ok to compile on with a168 and upload,
read the udev rule for /dev/arduino in the Makefile and set up /dev/arduino

Only 4 changes needed to the Makefile:

MCU_TARGET = atmega168
AVRDUDE = /home/USER/arduino/arduino-0022/hardware/tools/avrdude
AVRDUDECONF = /home/USER/arduino/arduino-0022/hardware/tools/avrdude.conf
PROGBAUD = 19200

Didn't use sender.sh used func.sh and did not bother with the fuses.h because it's an arduino with boot loader on it.

That's it, "seems!" to be working
Thank for everything, quite amazing how much works gone in to this...
Now I just need to build some hard ware for it to drive!

Edited 3 time(s). Last edit at 01/12/2011 12:30PM by avrmax.

AphoticJezter Wrote:
-------------------------------------------------------
> ...
> signals would show worse gaps than I was seeing
> with the official firmware, albeit only 2ms
> instead of 4 but far more often. I traced this
> down to the TICK_TIME (which surprise surprise was
> set to 2ms), and changing this to 250 US
> eliminated the jitter in the step signals however
> ...
> This looks like a bug in the timer code, but I'm
> not dead set on using this branch if there is
> another that may work better.
> ...
> Just some relevant detail on my set up:
> STEPS_PER_MM = 315.0 (for x,y and z)

Hey again,

As per my previous post I had the triffid_release_candidate branch hacked so that the 2ms pauses in the stepper signals were gone. I did eventually get this working, and have made quite a few successful prints using this firmware.

I recently pulled a copy of the master branch after the recent merge (pulled hash 719a9d32b5b9ddbee2d339d8e4c6fe93ee2e1ac3) but I'm still seeing the same 2ms pauses as with the triffid_release_candidate. My earlier solution was a bit of a hack, but am I really the only one seeing this issue?

It looks like a bug in the new clock code that was introduced in the triffid_release_candidate branch, but I'm not really sure how I'm exposing it nor why changing the tick duration seems to work around the issue.

Any ideas?

Jes