Project: Teacup Firmware

Hi Markus,

whats the practical upper limit in STEPS_PER_MM?

I have 1/256 microstepping drivers with 51200 steps per rev. - so when using finer threaded rods this could be an issue

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

The new hardwired limit will be 12 bits, so 4095. At one point you have to multiply these 12 bits with the desired distance held in 20 bits (good for 1023 mm at 0.001 mm accuracy), so 32 bits is just enough.

The funny thing is, just a moment after I found out how to squeeze the required maths (mm to number of steps conversion) into the 32 bit constraints, a number of people pop up with larger STEP_PER_MM numbers. Some 6400 and now 51200. I'm pretty sure there are only three ways out:

1) Go 64 bit maths: avr-gcc has this already built in, but it requires another 7kB program memory just for the libraries. And it's probably very slow.

2) Reduce the microstepping. There isn't much point in having a resolution higher than 1000 steps/mm due to the mechanical limitations.

3) Squeeze 51200 into 12 bits (plus a bit shift to the left). You can got the distance, but only in multitudes of 16 steps. Same effect as 2), but with the processor working harder.

Now, these 20 bits could be reduced in favour of the 12 bits, but you'd loose distance accuracy. There is no point in having 20000 steps/mm if you can only accept distances accurate to 0.1 mm or only distances of up to 8 mm. This is where the official FiveD firmware most likely fails with it's floating point maths as well. You get the distance, but only coarse.

Also there's a speed limit. I can only guess here, as obviously nobody measured yet how many pulses/s FiveD on Arduino can squeeze out of the ATmega, but it might be as low as 10 rpm maximum.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Question on PINS,
my Arduino had 13 Digital outs, 6 of them are being used for X,Y, Z. I found that if I use ports 0,1 there are issues that i believe have to due with those being used for communications. I had originally plugged my Z stepper into DIO1 and DIO2 and it was acting very peculiar. The Config file says for the 328p not to use DIO9 & DIO10 because those are being used for timers. that leaves me DIO8, DIO11, DIO12 for Extruder Driver and End Stops. I beleive I might have had some issues with 11 & 12 as well can't remember. So my question is What PINs are anyone successful with for the Arduino Duemilanove 328p? can Analog PINs be used to drive the steppers? my testing doesn't seem to suggest this but I also think I burnt out a couple Analog PINs on another project and when i got the digital to work i keep using those. any help is appreciated!

I use "analog" pins to drive my steppers without issue - they have all the same digital stuff as any other gpio pin, except A6/A7 on the smt package.

you can use the timer pins for gpio (eg stepper signals or on/off heater) without conflicts, just can't use them for PWM.

---

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

Hello,

sorry, I have not read the whole thread, so I am sorry, if this topic already occurred.

I realized, that the G02 and G03-Codes (CW and CCW arcs) were not implemented in the FiveD_on_Arduino - GCode-Interpreter. I need this codes for my project, so I adapted them from the reprap gcode-interpreter 1.3 (I think). Is anybody interested in my modifications? I could make/send a patch, but where to? I am relatively new to git... And the code more or less quick & dirty...

Kind regards, Felix

Felix Wrote
-----------------------
> I realized, that the G02 and G03-Codes (CW and CCW
> arcs) were not implemented in the FiveD_on_Arduino
> - GCode-Interpreter. I need this codes for my
> project, so I adapted them from the reprap
> gcode-interpreter 1.3 (I think). Is anybody
> interested in my modifications? I could make/send
> a patch, but where to?

fork, change, pull request

---

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

Hello,
I am trying to get the firmware on Gen7 electronics but I have some trouble with the z-axis.
It moves very slow and at the beginning of a move it moves for a second the wrong way.
I changed the pins of the z-axis with the y-axis and moved the z-axis motor with y-commands and it works perfekt, so no hardware problem.
I attached the current version I am working with. It is not the current release AFAIK.
So has someone any idea?

I found one more problem: The extruder position seems to integrate each step. When I extrude 5mm, he extrudes 5mm, when I extrude 5mm again he extrudes 10mm and so on.
As far as I know the Host software produeces absolute positions for the extrusion, but it seems like the firmware uses relative positions.

yes, this firmware always uses relative position for extruder even when set to absolute, otherwise extruder numbers overflow very quickly. Most of the code generators have an option to support this

---

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

Is there a option for the RepRap Host Software?

And what about my Z-Axis problem described one post above?

The Z-axis problem sounds like a "current too low"/"trying to step to fast" thing. You might try adjusting the current pot on the Z-stepper, or giving it a very, very low feedrate to see if it responds correctly to that.

I.E. G1 Z10 F1

Also, disable acceleration in the firmware. It assumes (incorrectly) that the speed is shared among the axies. This means that if you're doing:

G1 X10 F600
G1 Z1 F20

it will attempt to "deaccelerate" from F600 to F20 in 1mm of Z movement, which is of course going to cause problems. Come to think of it, this feature sounds like a dead ringer for your problem. If you don't want to disable acceleration in the firmware, you could try adding a dummy low-feedrate move before each Z move. However, since it tries to maintain the same speed when doing acute angles, I don't think that the acceleration code currently provides value.

The acceleration really needs to be calculated per-axis, and that on the host side. I've been toying with the idea of adding an explicit "starting feedrate" to sent gcode.

G1 X1 E1 F600 D300 ;Start at 300mm/s, constant acceleration to 600mm/s over 1mm's distance.
G1 X9 E8 F600 ; normal constant speed movement
G1 X10 E1 F300 D600 ;Starting at 600mm/s, slow down to 300mm/s over 1mm travel distance.

Might be overkill, though I don't know a better solution. It would allow the calculation intensive (but not real-time) task of path planning to occur on the computer instead. It would be even more fun to get arc codes in there - replace sharp corners (which the plastic doesn't follow and the axises can't follow) with a slow down, arc, and speed back up. With a bit of (host-side) calculation, the entire maneuver could be done while precisely respecting the different maximum acceleration values for the different axises.

---

--
I'm building it with Baling Wire

Quote

G1 X10 F600
G1 Z1 F20

it will attempt to "deaccelerate" from F600 to F20 in 1mm of Z movement, which is of course going to cause problems. Come to think of it, this feature sounds like a dead ringer for your problem. If you don't want to disable acceleration in the firmware, you could try adding a dummy low-feedrate move before each Z move.

The idea of this RepRap-style acceleration is to move the responsibility for accelerated/decelerated movements into the GCode generator, so the behaviour you describe here is what's actually expected. The unfortunate thing is, GCode generators like Skeinforge apparently can't deal with this responsibility and forget to add this "dummy feedrate". No idea why this isn't fixed in Skeinforge, everybody just recommends to disable acceleration, which is kind of counter-productive.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Can also try a different acceleration manager, traumflug's ramping method could be what you need

---

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

Working to get 5D running with repsnapper and I have come across this issue with the checksum
this line of code :
N111 G1 X12.8 Y19.2 E1.8 F500.0*6
give a rs signal with a bad checksum something like 38

adding a space between the F500.0 and the * it then ran
N111 G1 X12.8 Y19.2 E1.8 F500.0 *6

(in repsnapper it keep requesting this line over and over so I copied this line and ran it manually in mendel_talk )

now, repsnapper originally put a space there and in a different test case I found that taking out the space
made 5D correctly calculate the checksum
so I modified repsnapper to not put a space between the command and the *

not sure were to go with this one, leave the space, take out the space recompute the checksum in 5D for both cases?

another issue I'm trying to figure out is why 5D gets the queue to empty as outputted by the DEBUG_POSITION i.e. 5/5E and stays there. obviously repsnapper did not get the last "ok" either because of serial comm issues or whatever (I like to twist all my wires together on my breadboard its obfuscation electronica! :-D ) what I have now is a check in the mendel.c file in the "ifclock(CLOCK_FLAG_1S) " statement. I check to see if the queue is empty and if so I resend the 'ok'.
if we are in a print job and the dda queue goes empty, isn't this an issue?
Thanks for the great work so far. I am very encouraged in the progress so far. I figure buy the time i have my hardware all complete I should be done going over all the firmware and all the repsnapper code. then on to Skienforge.
Thanks all and Happy New years!
-Trout

one last issue, any idea how or why the firmware after processing 20 or 30 lines sends a resend command that must have been processed already?

23:06:19 Send >>Received: ok with parameter **************************************
23:06:19 Send >>SendData: N704 G1 X11.8 Y14.3 E1.8 F500.0*11
23:06:20 Send >>SendData: N705 G1 X10.3 Y14.1 E1.6 F500.0*12
23:06:20 Send >>Received:rs 702 Expected checksum 89 with parameter 702 Expected checksum 89
23:06:20 Send >>SendData: N702 G1 X12.1 Y11.4 E0.0 F500.0*12
23:06:21 Send >>Received:rs 677 with parameter 677
23:06:21 Send >>SendData: N677 G1 X13.4 Y14.9 E0.5 F500.0*6
23:06:22 Send >>Received: ok with parameter **************************************
23:06:22 Send >>SendData: N678 G1 X13.2 Y16.0 E1.1 F500.0*1
23:06:38 Send >>Received: ok with parameter **************************************

this is from the repsnapper logs

one more thing,
cuz I had an idea from that last post

N677 G1 X13.4 Y14.9 E0.5 F500.0*6
rs 0 Expected checksum 38
rs 677

so.... I'll keep pecking as I have gotten a few stls to completely process in repsnapper with no tinkering.
I like tinkering... and breaking things...

Edited 1 time(s). Last edit at 12/30/2010 09:26AM by Architect.

another issue related,
can anyone explain this out put?

19:13:25 Send >>Receivedos: 5120,3680,64,0,2000
19:13:26 Send >>Receivedst: 5120,3680,64,32,2000
19:13:26 Send >>Received:Q7/7E
19:13:26 Send >>Receivedos: 5120,3680,64,0,2000
19:13:27 Send >>Receivedst: 5120,3680,64,32,2000
19:13:27 Send >>Received:Q7/7E
19:13:28 Send >>Receivedos: 5120,3680,64,0,2000
19:13:28 Send >>Receivedst: 5120,3680,64,32,2000
19:13:29 Send >>Received:Q7/7E

This is without the sending Of OK when Queue is empty. i.e. Q7/7E
I'm thinking the driver is going from 0 to 32 with the extruder
but never moving. thusly, never finishing the line and not sending the OK.
just a thought but I need to resolve this.
-Trout

Put the ending space back into repsnapper here is the calculated checksum line results
Start
ok
N24 G1 X16.0 Y20.5 E1.6 F500.0 *30
rs 0 Expected checksum 62
rs 24
//Manually removed the space by hand
N24 G1 X16.0 Y20.5 E1.6 F500.0*30
ok

movement ensued.
so sometimes the checksum wants the space sometimes it doesn't this tells me its somewhere else in the code

I think I resolved the checksum issue.
changed the types of checksum_read and Checksum_calculated to shorts from unsigned char
thusly when checksum_calculated is XOR with a ' ' (space char) it is a short XOR with a short instead of a char Xor with a short.. or something like that. I'm not a C programmer. anyways this seems to be working now.
the code change was in gcode_parse.h

short checksum_read;
short checksum_calculated;

-Trout
moving on to the empty Queue issue I have.

Based on reading the wiki article concerning this firmware I assumed that it currently capable of running a reprap in conjunction with the reprap host software. However, after reading this thread I get the impression that the firmware is almost but not quite ready to use with the reprap host software. So, is the firmware currently capable of running a reprap in conjunction with the reprap host software or should I plan on using the floating point based fived for arduino mega until this firmware is complete? If it is capable of working with the reprap host software, which branch of the firmware should I be using?

Thanks,
--Jim

aka47 Wrote:
-------------------------------------------------------
> On Bootloader versus programmer.

My board have that addressed, using USB bootloader that works as a USB Mass Storage Device on PC, just like a USB flash drive. User just copy-paste the firmware to board :-)

Read more here: [reprap.org]

---

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

[www.3dprinting-r2c2.com]

Quote

However, after reading this thread I get the impression that the firmware is almost but not quite ready to use with the reprap host software.

The problem is, RepRap Host is a moving target. FiveD on Arduino used to work with this host, but then the host changed. I'm unsure about the current state.

Quote

So, is the firmware currently capable of running a reprap in conjunction with the reprap host software or should I plan on using the floating point based fived for arduino mega until this firmware is complete?

This depends on what you want to achieve. Using floating point FiveD won't enhance or fix FiveD on Arduino.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thanks.

My immediate goal is to get the Mendel I've been constructing working with some sort of gui interface. Once that is achieved I'd be interested in working on new firmware, but at the moment I want something that is known to work. Trying to debug firmware and stepper drivers and mechanics all at the same time - that way madness lies.

madscifi Wrote:
-------------------------------------------------------
> Thanks.
>
> My immediate goal is to get the Mendel I've been
> constructing working with some sort of gui
> interface. Once that is achieved I'd be interested
> in working on new firmware, but at the moment I
> want something that is known to work. Trying to
> debug firmware and stepper drivers and mechanics
> all at the same time - that way madness lies.

I have my port of this firmware working, however there was a lot of parts not working. Now, for example, I have homing working using the endstops and I do not look to them while printing, to avoid the problems I had.

Go with RepRap firmware! it is tested and working! in 2 months or less I will release my board and it will have this firmware working. Also will be easier for you to develop on it because it have the debugger.

---

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

[www.3dprinting-r2c2.com]

well F'ing !a
spent all new years weekend trying to get repsnapper to work with this with line numbering and checksumming.
Could not for the life of me figure out why it wasn't working we'll the problem was staring me for 14 hrs right in the face it seems. repsnapper send "\r\n" after the code line. fair enough thats normal. 5D checks to see if it has a 10 || 13 and processes the new line. problem is it reads 10 then processes the line as it is reading the 13 char which screws everything up when it comes around to check and tries to reprocess the line which may or may not be all there and blows up.
So far I have the process working as I see it it correct sequence. btw I could not see where this code originally keeps lines in the dda queue in order especially if there was a checksum error. so I have it doing that now.

YAY! I feel much better, now I can make progress on my actual machine and start testing speeds. I have 2 pololu steps at 1/16 steps using normal Mendel gears and a T5 belt, I also have my z axis and extruder on a 1/8 step Sparkfun "easydriver" can anyone who has done the work in their config tell me what they have their STEPS_PER_MM and MAXIMUM_FEEDRATE are set at? I'd appreciate the help in getting caught up here.

Thanks all,

><,'>

Architect Wrote:
-------------------------------------------------------I
> have 2 pololu steps at 1/16 steps using normal
> Mendel gears and a T5 belt, I also have my z axis
> and extruder on a 1/8 step Sparkfun "easydriver"
> can anyone who has done the work in their config
> tell me what they have their STEPS_PER_MM and
> MAXIMUM_FEEDRATE are set at? I'd appreciate the
> help in getting caught up here.

That's the same setup as me, here are my config file: HBox_RepRap_Electronics#Configuration

Edited 1 time(s). Last edit at 01/04/2011 07:26PM by casainho.

---

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

[www.3dprinting-r2c2.com]

thanks,
The Z steps is huge but thanks I'll give this a go to start out with and reference.

Quote

repsnapper send "\r\n" after the code line. fair enough thats normal.

"\r\n" is a Windows-ism and all firmwares, including the official FiveD are developed on Unix-like OSs so far.

Quote

5D checks to see if it has a 10 || 13 and processes the new line. problem is it reads 10 then processes the line as it is reading the 13 char which screws everything up when it comes around to check and tries to reprocess the line which may or may not be all there and blows up.

The additional \r or \n is treated as an empty line. Empty lines are discarded and responded with a "ok". How can this "blow up" anything?

Quote

I could not see where this code originally keeps lines in the dda queue in order especially if there was a checksum error. so I have it doing that now.

There's no point in adding commands with a checksum error into the queue. Looking at what you wrote further above, Repsnapper dosn't calculate the checksum correctly, as a trailing space character clearly changes the checksum value.

Quote

can anyone who has done the work in their config tell me what they have their STEPS_PER_MM and MAXIMUM_FEEDRATE are set at?

These two values entirely depend on your mechanics (pulley diameter, microstepping, etc.). Adjust STEPS_PER_MM until the measured movement matches the commanded movement. Valid range is between 0.001 and 4095.000. Any MAXIMUM_FEEDRATE works, as long as your mechanics can keep up with the speeds.

Not to forget, Jacky2k fixed a serious variable overflow error just yesterday and it'll take a few days until this fix will apeear in the Github Repo: [forums.reprap.org]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

it seems my giddyness in my forum posts comes accross as a script-kiddy and noobish. sorry for that.
I'll blame it on the beers and posting, not to mention my horrific ability to communicate with the outside world.
I am doing my work on a "Unix like" Os, I am running repsnapper from my Unbunto machine.
As a side note, I use windows to see what the weather is going to be like outside and do my day jobs as a application architect, its about all that is good for. I use my various macs to
a impress the ladies (doesn't really work except for the iPhone)
b listen to NPR or Ozzy depending on my mood, as I never wanted to learn Obj C.

So, I'm still curious as to what that thought process was for handling the resending on a corrupt line?
as I see it, here is the work flow I've seen with repSnapper and this firmware. obviously using the command line to send gcode might be different as well as other hosts.

1 repSnapper sends up to 4 lines of Gcode the way I have it configured. the number of lines sent is configurable in the host from what I can tell. I set it to 4.
Example work-flow:
N0 - N3 comes in from the host. It is picked apart char by char and the first 2 lines are fine and "ok\n" are sent and the TARGET for each is put in the DDA queue for processing. meanwhile, repsnapper, on receiving the OK for each line sends another line. now in the receiving serial buffer in the firmware we have lines N2-N5.
Line N2 has a bad check-sum( I have fixed both repsnapper and 5D in my code to correctly compute the check-sum, the methods are identical now, excluding any spacing. its a hack I know..)
so 5D sends a "rs 2" to the host instead of "OK"
the next line 5D processes will be N3 because its in the buffer already.
from what I can tell because "N3 >= next_target.N_expected" Line N3-N5 will be processed and if the check-sum is fine it will be the next line put in the buffer.
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.

So what is the thought about this?
is there something I am missing in the code that guarantees the correct order of each line being processed when there is a check-sum error and a line is resent? i haven't gone through all of the dda queue code yet.

as I have it now, I compare the last line requested for a resend to the incoming line and toss the current line if it isn't what I expect. this guarantees to me that they will be processed in order, I've had to reduce my comm down to 57600 from 115200 to minimize check-sum errors (I still have a rats nest of wires in my breadboard). But i want to be sure I understand the original intent.

-trout

hm, so host sends line\xd\xa, firmware responds ok ok, host thinks it has received line after that as well? maybe we should drop \xd before gcode parsing? I think that would work best

as for flushing the queue when there's an error, it never occurred to me that the contents of the buffer would simply cause a cascade of further errors- flushing the serial buffer on an error makes sense to me, just have to make sure that we set the comment flag so it ignores everything until the resent line starts coming through. Comment flag is reset after parsing, so will have to move things around a bit. Will also have to remember to manage xon/xoff correctly when flushing the buffer

---

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