Project: Teacup Firmware

PS_ON_PIN is for people who want to have the Arduino turn the PC power supply on and off.

Pin descriptions for the thermistor are built in structures in config.h - there can be multiple heaters, so it can't be a simple pin assignment #define.

Vik :v)

elmom Wrote:
-------------------------------------------------------
> Could someone add the commented out
> programming baudrate of 115200 for atmega2560,
> and a switch to use stk500v2 versus stk500v1, as
> that is what Arduino Mega 2560 default bootloader
> requires. So, I got the gcode parser loop working
> inside that particular board, improved the wikipage
> docs about that.

Are you talking about changes to the Makefile? I suppose we could add a program-yourchiphere target or something..

is this the objects.reprap.org wiki? great, I'll pull that into README which it was originally a copy+paste of


VikOlliver Wrote:
-------------------------------------------------------
> I Note there are plans for a second heater. Are
> there any plans for a second extruder? I've found
> enough pins and bolted one on, so I'm game for
> experimenting
>
> Vik :v)

Plans, yes.. implementation? nothing apart from rudimentary handling of T-words. You'd have to add something to M6 in gcode_process.c that alters the extruder step and dir pins that the dda uses, I suppose they would have to be held in a volatile struct of some sort instead of hardcoded to make them runtime-switchable. Don't forget to queue_wait()

Andrew Diehl Wrote:
-------------------------------------------------------
> Silly question. what is:
>
> #define PS_ON_PIN
>
> in config.h?

That's the pin I connect to my ATX psu to turn it on and off as necessary. leave it out if you don't have such a thing, and report here if that throws errors

> Also, where are the pin definitions for the
> extruder heater, thermocouple, and anything
> else not a stepper motor? I've been looking
> around in the code all day but wasn't able to
> find it. It's probably right in front of my nose...

config.h:

4. TEMPERATURE SENSORS
...
//                 name       type          pin
DEFINE_TEMP_SENSOR(extruder, TT_THERMISTOR, AIO0_PIN)
...
5. HEATERS
...
//               name      port   pin    pwm
DEFINE_HEATER(extruder,	PORTD, PIND6, OCR0A)

No need to specify port for temp sensors- we know it's either analog port or the SPI bus in the case of max6675.

Remember to check the appendix at the end of config.h when putting in your heater so you get the correct pin/port/pwm mapping for your chip

---

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

Triffid_Hunter Wrote:
-------------------------------------------------------

> I'm considering merging input-float branch as it
> doesn't seem to use much more code space, perhaps
> via an ifdef or something. Please post objections
> here!

Will this still fit on the 168 chip? It's getting pretty cramped in here already.

I printed my first bigger object with 5DoA on gen3 electronics The print went almost perfectly, the only thing I noticed was a slowdown/stuttering with circles.

The attached patches are based on the intercom-protocol branch, some should also apply to master.

I also nothiced there's a lot of noise on the intercom line if the extruder controllers h-bridges are active with pwm say >50. In some "unlucky" cases almost no packets get through with correct checksum. Its even worse, some wrong packets have a correct checksum by chance. If you disable the h-bridges the noise is gone instantly. I'm no noise expert, but it seems like this is a bug in the extruder controller 2.2 design. I ended up with controlling the z-axis with my extruder controller, and the extruder stepper with the z-axis driver. As a nice side effect I can now retract my extruder stepper 3 times faster

Edited 1 time(s). Last edit at 02/20/2011 10:40PM by Markus Amsler.

great news markus! I'll put that in my blog in a bit, beat me to it if you want first dibs

ps: git-am says all those patches are failing although they look ok to my eyes, want to try for a pull request?

---

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

passing --ignore-whitespace --ignore-space-change seemed to help, pushed

---

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

What are people using to generate the G-code for printing with 5D on Arduino? I cannot seem to find the option to enable relative positioning for E in Repsnapper or Reprap Host software. I can find an option in Skeinforge but it doesn't seem to have any effect.

the skeinforge one works for me, and RepG uses skeinforge as its backend.. what gcode are you ending up with? skeinforge->dimension->enable, and E always relative (whatever it's called) should do the trick nicely

---

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

Yup that's the option I enabled. The Gcode has m101 and m103 commands and the E values seem very high.

M101
G1 X60.48 Y52.96 Z0.54 F240.0 E522.48
G1 X62.16 Y53.8 Z0.54 F240.0 E37.566
G1 X62.16 Y26.0 Z0.54 F240.0 E556.08
...
G1 X80.64 Y31.96 Z0.54 F240.0 E119.28
G1 F798.0
G1 E-10.0
G1 F240.0
M103

If I disable speed->add flow rate m101, m103 and the E values go away.

I can't find 'Dimension' on the version of Skeinforge used with RepG.

I was hoping to use something simpler than skeinforge for my first few test prints.

Edited 1 time(s). Last edit at 02/21/2011 01:43AM by spaztik.

Can anyone confirm for me that input-float branch is actually smaller than master, even after the rebase I did today?

---

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

Oh never mind, gcc's math is enormous, using avr-libc's math library makes a huge difference

---

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

Congrats on the new integer code.

Skeinforge has the option of outputting integer gcode. To do so, pick the "Gcode Step" plugin in the "Export Operations:" radio group in the export tool. Alternately, you also have the option of outputting binary by picking "Binary 16 Byte".

I do not know what format is being used for integer or binary gcode, so the output format may have to be changed. If anyone makes a new export plugin for a different format, please email or message me and I will add it to the export plugins. If someone posts an example integer gcode that works with the new 5D integer firmware, I will modify an existing plugin.

Hi enrique,

does skeinforge specify what output format it's using? "G22 - steps as units" would be a good one.

Can the binary format supply E-words in the I or J parameter space? Does it use network byte order? Is there some more comprehensive documentation than the html that comes with skeinforge, apart from the source itself?

I'm interested in adding support for both of these formats, particularly if the binary format can supply E and distance (sqrt((dX^2)+(dY^2)+(dZ^2))) rather than I and J which I've never seen used.

Calculating distance on an atmega is problematic, my firmware uses a linear approximation, since doing a square root on an atmega takes a rather long time.

How are S and P words supplied in the binary format?

Can it have a checksum so we can detect wire errors, rather than an 'end-of-packet marker?

---

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

Hi Triffid Hunter,

> does skeinforge specify what output format it's using? "G22 - steps as units" would be a good one.

No. Skeinforge uses only millimeters internally, and the output for both "Gcode Step" and "Binary 16 Byte" are just integers. You can change the "Step Length" and Offset for plugins from the display windows, which can displayed by clicking on the plugin button.

> Can the binary format supply E-words in the I or J parameter space? Does it use network byte
> order? Is there some more comprehensive documentation than the html that comes with
> skeinforge, apart from the source itself?

Have you seen the documentation at the top of the "Binary 16 Byte" file, which can also be brought up in the browser by clicking on the help button? In case you haven't it follows at the bottom of this post.

> Calculating distance on an atmega is problematic, my firmware uses a linear approximation,
> since doing a square root on an atmega takes a rather long time.

I agree that the microprocessor should not be calculating the square root. I pointed this out when the 5D was first made, suggested that duration be used instead to avoid those calculations, and was ignored.

In order to output the duration for the Gcode, I made the "Gcode Time Segment" export plugin. It outputs the duration, as a Dcode, so that the microprocessor doesn't have to waste time calculating square roots. No one has reported using it yet, but eventually the firmware should use something like that, and you could be the first to implement that firmware

> How are S and P words supplied in the binary format?

From the record structure, which is reprinted below, the first letter of each binary record is the letter of the code.

> Can it have a checksum so we can detect wire errors, rather than an 'end-of-packet marker?

There is no checksum in the record. In my opinion, that should be independent of the binary format. Whatever error checking is used should work for binary or ascii.

Cheers,
Enrique



==Record structure==
BinArray(0) = AscW(Inst_Code_Letter)
BinArray(1) = cInst_Code

X Data
sInt32_to_Hbytes(iXdim_1)
BinArray(2) = lsb 'short lsb
BinArray(3) = msb 'short msb

Y Data
sInt32_to_Hbytes(iYdim_2)
BinArray(4) = lsb 'short lsb
BinArray(5) = msb 'short msb

Z Data
sInt32_to_Hbytes(iZdim_3)
BinArray(6) = lsb 'short lsb
BinArray(7) = msb 'short msb

I Data
sInt32_to_Hbytes(iIdim_4)
BinArray(8) = lsb 'short lsb
BinArray(9) = msb 'short msb

J Data
sInt32_to_Hbytes(iJdim_5)
BinArray(10) = lsb 'short lsb
BinArray(11) = msb 'short msb

BinArray(12) = FP_Char
sInt32_to_Hbytes(iFP_Num)
BinArray(13) = lsb 'short lsb

BinArray(14) = bActiveFlags

BinArray(15) = AscW("#")End of record filler

Byte 14 is worth a few extra notes, this byte is used to define which of the axes are active, its used to get round the problem of say a line of code with no mention of z. This would be put into the file as z = 0 as the space for this data is reserved, if we did nothing, this would instruct the machine to go to z = 0. If we use the active flag to define the z axis as inactive the z = 0 is ignored and the value set to the last saved value of z, i.e it does not move. If the z data is actually set to z = 0 then the axis would be set to active and the move takes place.

time is no use to us, we have acceleration which throws most time calculations out the window, especially ramping acceleration. distance is far more useful, and skips the square root directly without assuming what the firmware is planning to do with the result.

I did read that breakdown of the binary format, and I'm still unclear on a number of points.. if I send something like M130 S1 P7.9, does this really take 3 binary blocks, 48 bytes? How are large XYZ values and floating point values transmitted in only two bytes? How can the firmware detect the boundary between one multi-block command and the next?

---

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

Hi Triffid Hunter,

> if I send something like M130 S1 P7.9, does this really take 3 binary blocks, 48 bytes?

That would be up to whatever is processing the M130 command. You could put the first two values into the slots for x and y. The record format is for a movement code, but something processing an Mcode can use an alternate record format, as long as it starts with the command letter and number and the entire thing is 16 bytes long.

> How are large XYZ values and floating point values transmitted in only two bytes?

If the precision is 0.1 mm, then 65,536 gives you a 6.5 m table. If the precision ever goes higher or a giant reprap is made, a three byte format would have to be used.

> How can the firmware detect the boundary between one multi-block command and the next?

Each of the blocks is 16 bytes. If some command requires more than 6 fixed point numbers, than it must be broken into smaller records.

Don't sweat it. There's no visible difference between running at 19200 baud and 115200.

Vik :v)

Triffid_Hunter Wrote:
-------------------------------------------------------
> another way to make the endstops more reliable is
> to put a buffer at the end-stop end of the cable.
> That way, the signal wire can have a low impedance
> at both ends. suitable capacitors will lessen
> motor noise while still allowing signal to get
> through.
>
> As far as firmware goes, jgilmore thanks for the
> in-depth exploration of end-stops and related
> issues. I think moving the end-stop check out of
> dda_step and into the main loop is a great idea.
> that will also make adding counters for spurious
> signal rejection easier.
>
> One of the patches I want to make soon is some way
> to keep the main loop spinning without accepting
> new characters from the host. There are a couple
> of ways to do this, and I haven't decided which I
> like the best. There are a few functions which
> would use this feature, dwell and wait-for-temp to
> name just a couple. If the end-stops are checked
> in this loop, we could simply spin it really fast
> when homing as a very simple implementation of
> what you suggest.


Triffid,
was the end stop checking you mentioned above ever get moved into the main loop?
Seems I still have to do some work on my end-stops. I rewired this weekend and included the end-stop wiring inside the Cat5 cable with the stepper signal. wasn't thinking when i did this but really introduced some noise on my end-stops. gonna move the signal out and shield it. but was looking at the code again and was thinking that it would be nice just to have a value that is a definite state of the end-stop instead of checking its momentary pin read.
thus,
if (!(min_x_end stop && X_DIR == 0) || !(max_end_stop && X_DIR ==1) Step X

Quote

it would be nice just to have a value that is a definite state of the end-stop instead of checking its momentary pin read.

Don't see how moving this to the main loop would solve anything. If you start to do some integrating thing, like "endstop is really at a stop if it says at least five times in a row so", you can do that integration just as well at stepping time. Doing it from the main loop would require to check almost as fast as the stepper steps, adding a substantial load.

In my application, I rely on endstops working exact to at least 0.01 mm or better[*].



[*] That's with PCB milling: create an "endstop" by contacting the raw PCB to mass, then add a wire clamp from the endstop pin to the mill bit. Works beautifully. You have to remove the clamp before starting the spindle, of course.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

well I've moved the homing and endstop stuff into home.[ch], triggered by G161/G162 which seemed to be what most people wanted. I suppose we could put similar logic back into the step routine wrapped up in a define of some sort, preferably in the interruptible section somewhere.

ps: project has been renamed 'Teacup' by popular vote on the IRC channel, primarily for disambiguation purposes but also because I've been wanting to change the name for a while. Hope you all like it

---

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

well I've moved the homing and endstop stuff into home.c, triggered by G161/G162 which seemed to be what most people wanted. I suppose we could put similar logic back into the step routine wrapped up in a define of some sort, preferably in the interruptible section somewhere.

ps: project has been renamed 'Teacup' by popular vote on the IRC channel, primarily for disambiguation purposes but also because I've been wanting to change the name for a while. Hope you all like it

---

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

You might want to change your signature.

done, thanks

---

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

Quote

I'm considering merging input-float branch as it doesn't seem to use much more code space, perhaps via an ifdef or something. Please post objections here!

Sure you have put in a few nice ideas there. Here are a few points a nitpicker might see as an "objection", after glancing over the code:

- Storing the intention of a line of G-Code has gone from 36 bytes (*TARGET and a few) to 128 bytes (words[32]).

- A line buffer is introduced which not only costs another 64 bytes, but also prohibits processing commands as they come in. Everything is done in one chunk after the newline, creating a load-blob.

- The string to float conversion is delegated to the libc's strtod(). Is that reliable? Is that fast?

- Float to integer conversion is done with an implicit cast. How well works this one?

- Imperial units are dropped. Doing the same on the pure integer version would rub out a lot of stuff, too.

- The "self brewed" fixed point maths counts just 35 lines and is always accurate to the (stepper motor) step, while floats loose accuracy.

- Last, not least, we had a very long journey to get that integer version fixed. Not only maths issues, but also many in logic and flow of the code. Now every single math operation is checked against overflow, quite a number of people report success. Is it really a good idea to start over with mostly untested code now?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

hm you raise fine points. I'll leave that branch separate for now. Can we make gcode_parse easier to read? Even I get lost in it!

---

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

That G-Code parsing algorithm is amazing and to be honest, I don't see apparent opportunities to improve it on a large scale. Advancing in small steps has worked well for me and I still have a few small cuts in the queue.

Another thing could be to get rid of three optional macros at the top of gcode_parse.h (and their alternative code paths): ASTERISK_IN_CHECKSUM_INCLUDED, REQUIRE_LINENUMBER and REQUIRE_CHECKSUM. Apparently, nobody needs them?

The denominator for decfloat_to_int() could be reduced to be either 1 or 1000, replacing the uint32_t with a flag. The contents of that flag is available in next_target.option_inches already.

That said, 1000 could be replaced with 1024, allowing bit shifts instead of divisions or allowing the compiler to optimize this way.

The multiplicand could be stored in a variable (swapped in G20/G21), reducing 4 lines when handling X, Y, Z or E to one line.

So far some ideas, neither of them ist tested to actually enhance something.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I use REQUIRE_CHECKSUM and did use REQUIRE_LINENUMBER for managing the checksum. LINE NUMBER is used regardless if this is set or not. REQUIRING it makes it hard to swap back and forth from the gui's to mendel_talk so i commit it out now. Still use the N values and it works fine. never had to use the ASTERISK_IN_CHECKSUM_INCLUDED as both replicatorG and repsnapper do not include them with the checksum. not sure what does.
If we got rid of these would we just process the checksum if it exists? that would be my suggestion.

is anyone using I2C with this firmware to talk to other controllers? going on vacation for 10 day and can only take small projects along. so i was going to start fiddling with a LCD I have and a second Arduino 328. if not I2c any other suggestions?

Reporting a bad incompatibility: The firmware sends something like "rs N2 Expected***\nrs 1\n" which breaks the more naive host-side parsers. Is that message really necessary? At least remove the "rs" from the error message.

Traumflug Wrote:
-------------------------------------------------------
> - Imperial units are dropped. Doing the same on
> the pure integer version would rub out a lot of
> stuff, too.

we drop G21 support? sure, I don't think anyone uses it

> - The "self brewed" fixed point maths counts just
> 35 lines and is always accurate to the (stepper
> motor) step, while floats loose accuracy.

don't be fooled, this is real (yet crude) floating point- we have a clearly defined mantissa and exponent. fixed point is when we use a base unit less than 1 (eg the 0.25 degree temperature stuff)

> Another thing could be to get rid of three optional
> macros at the top of gcode_parse.h (and their
> alternative code paths): ASTERISK_IN_CHECKSUM_INCLUDED,
> REQUIRE_LINENUMBER and REQUIRE_CHECKSUM.
> Apparently, nobody needs them?

we can ditch asterisk_in_checksum_included since that was only present while we were working out the exact algorithm, the other two I'd like to keep, especially if we can clean them up a bit since they're reliability features and don't take much space.

> The denominator for decfloat_to_int() could be reduced to be
> either 1 or 1000, replacing the uint32_t with a flag. The contents
> of that flag is available in next_target.option_inches already.
>
> That said, 1000 could be replaced with 1024, allowing bit shifts
> instead of divisions or allowing the compiler to optimize this way.

that does kinda break the floating point a bit- if these values are so common, perhaps we can test for them in decfloat_to_int and have blocks to speed up common cases rather than optimising the entire function for them?

I think we can see some improvement by munging exponent and denominator together, eliminating common factors or whatever

> The multiplicand could be stored in a variable (swapped in
> G20/G21), reducing 4 lines when handling X, Y, Z or E to one line.

sure, do it, unless we remove G21

elmom Wrote:
-------------------------------------------------------
> Reporting a bad incompatibility: The firmware sends
> something like "rs N2 Expected***\nrs 1\n" which breaks
> the more naive host-side parsers. Is that message
> really necessary?

no, this is a bug. remove lines 358 and 363 of gcode_parse.c (both request_resend()) until I can get this into the repository

Architect Wrote:
-------------------------------------------------------
> is anyone using I2C with this firmware to talk to other
> controllers? going on vacation for 10 day and can
> only take small projects along. so i was going to start
> fiddling with a LCD I have and a second Arduino 328.
> if not I2c any other suggestions?

you could try plugging our new intercom into the I2C or SPI modules and adapting it for your purposes, although I don't think that'll be particularly helpful with putting useful information on a LCD. It will however show you how to put hooks into the code to fire at particular times and gather information; grep -HnC3 for things defined in intercom.h to find where they are

I think SPI will be more noise immune, but takes more I/O lines than I2C. You could always wrap things up in an ifdef and try both

---

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