Project: Teacup Firmware

Hello, has anyone tried to send multiple accept pacakets back to the reprap host? send println(ok\nok\ok\ok) for example. it speeds up the short moves dramatically and still supports reprap host. just curious. thanks.

sorry for spelling issues. using dirty keyboard...

Does this mean you're actually using FiveD on Arduino in production? That surprises me, as on a first test, this firmware already choked on the initial N0 T1, as the firmware in it's current state doesn't send back an OK in this case. But see next post ...

Anyways, if such nasty hacks indeed speed up things, there is something wrong in the communications protocol that should be fixed.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

As mentioned in the previous post, while being a very promising firmware, FiveD on Arduino failed on pretty basic things here. Unknown commands were ignored, but not the number following the command, so a N1 T1 was interpreted as N11. The confirming OK was sent on G and M commands only, resulting in a hanging host software on other commands. Also, M and G commands weren't reset, so once a M105 was done, the firmware would send back temperatures on every following command. Last not least, I refined line number counting a bit.

One thing left is errorneous checksum calculation. Host still chokes. I hope this follows soon.

I tried to post the patch on github's issue tracker: [github.com]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Have the GCode stuff running now. Next thing will be to hook up a stepper.

Still looking for a place to upload patches ;-)

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I am interested in your work because of the chance for great speed improvement using only 1 arduino. Although i think that the 'mega' will become users choice in the next year because of lcd and sdcard support.



I am actually testing 5d code as a beta release. it is modified from the standard reprap.org release, and is capable of working in 3d or 5d mode. I don't think i have my code uploaded I am tinkering with online yet. and it will never be more than a beta... www.profounddevices.com it is based off of code from the Mendel distribution of the reprap host software, just tweaked and wrenched on and added to.

a few things i notices that seem to improve the code. Sending back multiple acknowledges over the usb buss provides a tremendous speed improvement for rate of commands sent from host. This has to do with a software buffer of 4096 bytes from the usb driver, sending multiple commands at a time from the reprap host improves speed dramatically. like 10 times for short lines and drawings using 57600 baud (with 2x fix for baud rate), otherwise every aknowledge is sent back buffered, and the fastest the usb driver can process it at any baud rate is 2ms. so sending back one aknowledge at a time is pointless above 4800baud for short lines. Make sure if you do multiple aknowledgement that you are sure the baud rate is near error free, because you are bybassing the error checking. i think about 78000 baud will be the best, but i do not know how well it is supported in java.

i increased the serial buffer in arduino code from 128 to 800 i think, and reduced the buffer to 2 buffer lines (one being made while the other is executing) and stopped sending ok's after the buffer fills up past 720 char. Also when reducing buffer lines, change code elsewhere to not buffer extra cdd..

this allows the buffer to mainly be stored in the serial buffer and it can cache up to 128 bytes from the serial chip. i only saw speed improvements from this.


the other thing i am doing is ignoring feedrates when e is 0 or when s=0 so when no extruding is being done, use either fast_feedrate or slow_feedrate if you have issues at fast acceleration. this means jog speed even when a set z speed is determined. it is just an optimization that also speeds things up.


Also when using 5D code. your first command to move should be just a FXXX command for starting feedrate, otherwise you will start at 0 and that will take forever to move.

G1 F500;
G1 x2 y7 f1000;

Quote

the chance for great speed improvement using only 1 arduino.

From what I can see, FiveD on Arduino would improve FiveD on bigger controllers as well. Triffid Hunter apparently invested a lot of time and hirnschmalz to reduce code run at interrupt time, to make enqueuement of multiple commands possible, allow for serial line flow control (XON/XOFF) and similar things.

Quote

Sending back multiple acknowledges [...]

I see. If you talk about "multiple ACKs", you mean one ACK for each command, but in a situation where more than one command can be sent/received.

Quote

i increased the serial buffer in arduino code from 128 to 800

Beware of Arduino's 1024 bytes RAM limit. Last time I checked, there were only 157 bytes free with the default configuration. For finding out about free RAM, see [forum.pololu.com] .

Quote

G1 x2 y7 f1000;

(btw, the semicolon is obsolete)

Yes, it's an oddity of the RepRap GCode flavour F commands are meant to _end_ at the speed given while starting with the current speed. At the same time, there's apparently no attempt to do start and stop ramping needed to avoid mechanical machine distortions. I'm not sure what's the purpose of this interpretation is and will probably change it to something more in line with CNC mills. Sample code can be found here: [www.embedded.com] , FiveD on Arduino uses some of this code already.

The capability to receive multiple lines nicely allows to extend ramping over multiple commands, avoiding intermediate stops between similar movements. Implementation isn't exactly trivial, but can be done.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

In lack of a better place for colaboration, I've put the first bunch of patches into the Wiki: [reprap.org] .

Applying them should allow to build/upload firmware with the standard Arduino IDE and to issue manual commands. Running with RepRap host still fails on checksum mismatches.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Added another few patches. Unless I messed up the patches while dropping them into the Wiki, this should allow RepRap Host software 20100628 (the current one) to basically run with this firmware. GCode commands can be sent, exceptions are avoided, temperature readouts, line-resends and checksums work. [reprap.org]

Don't forget to set the host software to communicate 115200 baud in it's preferences ... FiveD on Arduino talks a bit quicker ;-)

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Start/Stop ramping is done: [reprap.org].

Should give every machine a smooth ride, independently on wether the G-code generating application tries to do acceleration or not.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

hi Traumflag,

that's a seriously impressive overhaul of my code, glad you are enjoying it!

The algorithm I hacked for the acceleration is described as a start/stop ramping algorithm on the linked site, I've refactored it considerably to make it emulate other firmwares. If you prefer the start/stop ramping, you might like to read the original article- perhaps there's an even simpler way to do it

Thanks for showing me how to make it talk to the regular reprap host software, I've been sticking to my own talker for that since I've been generating gcodes with skeinforge

As for the M/G code thing, I've read that commands can be split over multiple lines, so while it looks like it's not resetting the M/G code field, it should only do one- note the "else if (gcmd->seen_M) {" on gcode.c line 506. Perhaps we can just forbid multi-line commands?

I was intending on using the line numbers as a crude checksum which is why they're so strictly checked, as you've noticed it still has character receive errors even with all the buffering and whatnot. I think loosening the restrictions should be optional

None of my gcode files had T commands in them, so didn't pick up on it not liking them. My idea with the "OK" replies is that it sends them when it has successfully processed a command and can accept another.. didn't consider legitimate but unrecognised as a possibility, my bad

as for digit processing, could probably make it so any non-digit character ended digit processing, so if the host starts using other letters we'll still be ok

I'm currently investigating how to allow you to post all your patches to git so we can all enjoy your insights and work

---

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

Glad you took a moment to look at my work, Triffid. Refining FiveD on Arduino was a joy, as the code is well and thoughtful deigned. There was an expert at work ;-)

For any of the changes I hope it doesn't get into the way of Skeinforge people. Perhaps I should even rework the latest patch to include both, your continuous acceleration and my start/stop ramping, switchable by a #define.

Quote

As for the M/G code thing, I've read that commands can be split over multiple lines, so while it looks like it's not resetting the M/G code field, it should only do one- note the "else if (gcmd->seen_M) {" on gcode.c line 506. Perhaps we can just forbid multi-line commands?

Without having a sample or a specification of such a multiline command it'll be difficult to code a receiver for it. Likely there'll be some sort of "continue line" character, like the backslash in the Shell or C languages.

Quote

as for digit processing, could probably make it so any non-digit character ended digit processing, so if the host starts using other letters we'll still be ok

That's what I've done. Saves even a few bytes of program memory.

Quote

I'm currently investigating how to allow you to post all your patches to git so we can all enjoy your insights and work

That'd be great. My user name on github is the same as here.


Oh, and how about advertising for Sanguino and the likes? The current name somehow suggests the firmware is some sort of crutch for limited hardware, while it's most likely an enhancement to bigger sized hardware as well.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

So, I've been trying to impliment this on my single Arduino 328. I got the initial version by Triffid to compile and load on my Arduino but I have a thermocouple and not the temp sensor chip he uses. I set about trying to write in an alternate temp routine for those of us with a thermocouple but I started running into a lot of problems. Chief among these was the fact that I have never done microcontroler programming in C before.

This was about a 3 months ago that I started this. I now see that Traumflug has added a metric crap-ton of really cool features/fixes and I want to incorporate those into whatever I eventually get working.

My question is, is there a certain way I should be going about adding support for an alternate temp sensor? My initial strategy was to have the user choose which one they want through a #define and use a couple #ifdef's to select which functions to compile. Is this a good strategy?

Also, I had to enable the internal AREF to 5V which didn't seem to on in the original version...is this likely to breakanything already implemented?

Demented

---

[www.urbansurvivalists.com]

Traumflug Wrote:
-------------------------------------------------------
> Without having a sample or a specification of such
> a multiline command it'll be difficult to code a
> receiver for it. Likely there'll be some sort of
> "continue line" character, like the backslash in
> the Shell or C languages.

When I wrote my host based gcode interpreter, I found the the NIST RS274NGC standard quite useful to form a basis for an interpreter. Section 3.3 had the greatest utility for defining a grammar / parser. This specification clearly allows multiple commands on a single line, although there are clear limitations on when it is not acceptable to have specific commands on the same line, as stated as "It is an error to put a G-code from group 1 and a G-code from group 0 on the same line if both of them use axis words. If an axis word-using G-code from group 1 is implicitly in effect on a line (by having been activated on an earlier line), and a group 0 G-code that uses axis words appears on the line, the activity of the group 1 G-code is suspended for that line.".

Personally, I did not see the need to support multi-command lines, and chose not to implement support for it in my parser. Rather, I treated each line as a complete command / register set, using the newline as a command separator.

> as for digit processing, could probably make it so
> any non-digit character ended digit processing, so
> if the host starts using other letters we'll still
> be ok

I decided to keep it simple. My gcode line processing function strips out comments, spaces, and any checksum sequence it finds. It scans what's left using the Regex: "[a-zA-Z][-+]?(([0-9]+([.][0-9]*)?)|([0-9]*[.][0-9]+))" Anything remaining after this creates a warning indication.

I believe that it shouldn't be difficult to create an ultra-lean/mean parsing machine from that regex by creating a lex table, simply pumping valid characters up to a comment thru the lex table (should only be 6 states and 4 character categories), perhaps, processing each digit as it is seen in a temporary 16.16 fixed point numeric field to save it off into the proper register, assuming a valid register symbol was seen? Maybe you've already done that though. Hehe.

Edited 1 time(s). Last edit at 07/07/2010 11:50PM by BeagleFury.

The code changes were to trick the reprap host into sending multiple lines of data at a time, not to process them as one line. hopefully the /n indicates the end of a line, and the command is processed or it is stored in the buffer.

Quote
Demented Chihuahua
My question is, is there a certain way I should be going about adding support for an alternate temp sensor? My initial strategy was to have the user choose which one they want through a #define and use a couple #ifdef's to select which functions to compile. Is this a good strategy?

The usual way to implement for a new type of hardware (here: alternate temp sensor) is to look what's already there and add code until it does what's neccessary. And yes, using a #define is the right way to go, as we don't have something like a preferences panel for configuring the firmware while in use.


@BeagleFury: Thanks for the link to the NIST specification. I didn't have that yet and I don't see multi-line commands either. :-) Using a regular expression is way over what would fit into firmware program memory, though.

Quote
james d villeneuve
The code changes were to trick the reprap host into sending multiple lines of data at a time, not to process them as one line. hopefully the /n indicates the end of a line, and the command is processed or it is stored in the buffer.

I see. No, I didn't try that yet. If that trick really makes a difference, this should be fixed. Communications between RepRap Host and FiveD on Arduino is pretty quick, a line resend (in case of failure) for example, takes just 5 milliseconds.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

> @BeagleFury: Thanks for the link to the NIST
> specification. I didn't have that yet and I don't
> see multi-line commands either. :-) Using a
> regular expression is way over what would fit into
> firmware program memory, though.

I meant creating a (probably goto based state machine) equivilant to that specific regular expresison, not using a general RegEx parser; you're right, that WOULD be overkill.

Demented Chihuahua Wrote:
-------------------------------------------------------
> My question is, is there a certain way I should be
> going about adding support for an alternate temp
> sensor? My initial strategy was to have the user
> choose which one they want through a #define and
> use a couple #ifdef's to select which functions to
> compile. Is this a good strategy?

yep, I think you will just need to alter temp_read() in temp.c to read your analog sensor instead of my max6675, leaving everything else untouched so the other parts of the code that use the temp interface don't get confused or do the wrong thing. Note that the code is currently set to read the sensor every so often, and return a cached reading when asked because it takes time to read the sensor, even with analog and one of the foundational theories of my firmware is that waiting/blocking is bad!

If you can possibly leave the analog subsystem doing a read when you return from temp_read(), and save the value next temp_read(), you will avoid blocking code. To get a good first read, start a reading in temp_init() too.

> Also, I had to enable the internal AREF to 5V
> which didn't seem to on in the original
> version...is this likely to breakanything already
> implemented?

no, nothing uses analog inputs in my firmware that I know of, just be careful when initialising registers to not stomp other stuff. check the io_init() routine in mendel.c if you're concerned.

---

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

James Villeneuve Wrote:
-------------------------------------------------------
> Hello, has anyone tried to send multiple accept
> pacakets back to the reprap host? send
> println(ok\nok\ok\ok) for example. it speeds up
> the short moves dramatically and still supports
> reprap host. just curious. thanks.

my firmware processes incoming data one character at a time instead of processing a whole line. It caches moves and sends back an "OK" whenever it has read a command and is ready for another one, so it already gets the host to send about 8 commands before it's finished the first one. The only thing that sending more OKs would do is put more strain on the input buffer and increase chances of overflow.

One of the reasons that the official firmware has trouble with lots of short moves is that it does insane amounts of floating point math all over the place, and each calculation takes ages, certainly long enough to mess up sequences of short moves.

I think you may find my firmware a vast improvement in this area for this reason, and you can always increase the number of moves it caches up to the limit of available ram. Mine takes (iirc) 69 bytes of ram per cached move.

---

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

Traumflug Wrote:
-------------------------------------------------------
> Glad you took a moment to look at my work,
> Triffid. Refining FiveD on Arduino was a joy, as
> the code is well and thoughtful deigned. There was
> an expert at work ;-)

thanks! I could tell that the official FiveD wasn't written by people familiar with microcontrollers, and was determined to demonstrate that all the same functionality was possible while writing with both the platform's advantages and limitations in mind

hopefully I put in enough comments around things that were in counter-intuitive yet effective places for you. microcontrollers can be extremely harsh on style correctness and logical organisation!

> For any of the changes I hope it doesn't get into
> the way of Skeinforge people. Perhaps I should
> even rework the latest patch to include both, your
> continuous acceleration and my start/stop ramping,
> switchable by a #define.

hell, put them both in! just reset current speed to some close-to-zero speed if/when the last move finishes, so new moves will ramp from a slow speed to the saved target speed. This way we re-use the existing code and keep alterations to a minimum.

Stop ramping will be tricky, because you can never tell if a new move will come through while the last one in the queue is running. I suppose we could set a low but non-zero stop speed if it's the last move in the queue, so if the host is having trouble keeping up, the printing just slows down a bit while keeping everything synchronised thanks to the algorithm

Both of these features will be greatly enhanced by capping acceleration and allowing it to build over a number of moves.

> I'm currently investigating how to allow you to
> post all your patches to git so we can all enjoy
> your insights and work
>
> That'd be great. My user name on github is the
> same as here.

I've added you as a collaborator through git's web interface, not sure whether that's all it takes.

> Oh, and how about advertising for Sanguino and the
> likes? The current name somehow suggests the
> firmware is some sort of crutch for limited
> hardware, while it's most likely an enhancement to
> bigger sized hardware as well.

I completely agree, but don't have any bigger hardware to test on, plus I'm not great at naming. Any suggestions for more evocative yet broadly descriptive names?

---

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

Quote

hell, put them both in! just reset current speed to some close-to-zero speed if/when the last move finishes, so new moves will ramp from a slow speed to the saved target speed. This way we re-use the existing code and keep alterations to a minimum.

Actually, I tried something like that. Splitting each incoming move into three queued ones: a start ramp, a steady move and a stop ramp. That turned out to require too much code, because you have to calculate intermediate points exactly ( -> exact square root, accuracy loss due to the need of number²). So I stopped following this path.

Quote

Stop ramping will be tricky, because you can never tell if a new move will come through while the last one in the queue is running. I suppose we could set a low but non-zero stop speed if it's the last move in the queue, so if the host is having trouble keeping up, the printing just slows down a bit while keeping everything synchronised thanks to the algorithm

Yes, stop ramping is tricky. I've read a lot of papers about "look ahead" strategies and it turns out, if you want to follow a given path exactly, you have to stop after each move unless the next move follows exactly the same vector. See [books.google.com] , page 126ff. Any attempt to maintain speed while following the exact path results in speed bumps, a physical impossibility.

The trick is to move a small circle between two paths. My plan is to try this by just overlapping the stop ramp of one move with the start ramp of the next move. Regarding queueing up such movements I want to queue each move with a full stop ramp first, then relax this stop ramp as the next move arrives.

In case the host can't keep up with keeping the queue filled, there's no point in trying to maintain speed, IMHO.

Anyways, there's still some theory work required and currently, with FiveD on Arduino doing the basics right, I'm focussing on getting my Wolfstrap actually building parts. :-)


Regarding "marketing" I'll add a note to the Wiki page about it's capabilities even for larger controllers. Also, I'll try to find pages claiming FiveD is too big for the Arduino and insert a hint on FiveD for Arduino instead.

Cheers,
Markus

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

... when programming my first plotters, i managed the 'path-changing on the fly' with the start/stop-frequency, at which the motors can be started, stopped and reversed without step-losses.

The Ramping was calculated with a constant acceleration up and down, so i could pre-calculate the accelerating ramp until max. or until path/2, then the same for the decceleration ramp and the direction-changes were driven with the 'safe' start/stop-speed without any 'look-ahead'.

With a fast MC and a fifo-buffer big enough you can receive the path-data much faster than the motors can drive and have mostly some resources more, so you can implement a rudimentary 'look-ahead' too for decisions if the speed at the end of the line should be completely reduced until start/stop or if it can stay higher when the changing vector-angle of the next line is aligned or near the current moving direction ...

Maybe a simple relation between the alignment of the next vector and the changing speed is enough?

---

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]

Thanks for the responses Triffid/Traumflug! I'll get back on it here soon and see what I come up with.

Demented

---

[www.urbansurvivalists.com]

Quote
Triffid_Hunter
I've added you as a collaborator through git's web interface, not sure whether that's all it takes.

Yupp, that's all. The first two commits got in now.

For the Reprap Host compatibility changes, I'd like to drop for code readability the #ifdef LOWERCASE_OK (3 instances) I currently have. Does some other setup actually require an uppercase "OK" and "RESEND" or would "ok" and "Resend" be fine for all GCode sending softwares?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Regarding the analog temperature reading, I did that already. On an older version of triffid's code anyway. I can't remember if I correctly started and used the old number, or if I wrote blocking code. It'd still be a leg up. Can't find it right now. Hrm... because it's on my laptop. PM me with a reminder to post it if you care, I'll reply when next I use my laptop (Monday night or so)

---

--
I'm building it with Baling Wire

Triffid,

I'm a bit confused by your code and your comments. In your temp_read() function you use a delay of 1,

// enable MAX6675
	WRITE(SS, 0);

	// ensure 100ns delay - a bit extra is fine
	delay(1);

	// read MSB
	SPDR = 0;

but you say not to block. Doesn't this block? Or is it just so short it doesn't matter?

Demented

---

[www.urbansurvivalists.com]

Demented Chihuahua Wrote:
-------------------------------------------------------
> Triffid,
>
> I'm a bit confused by your code and your comments.
> In your temp_read() function you use a delay of
> 1,
>
>
> // enable MAX6675
> WRITE(SS, 0);
>
> // ensure 100ns delay - a bit extra is fine
> delay(1);
>
> // read MSB
> SPDR = 0;
>
>
> but you say not to block. Doesn't this block? Or
> is it just so short it doesn't matter?

well spotted and quite correct! My theory is that it's so short that it shouldn't matter, basically it should only be about 5-8 clocks or so. Unfortunately there does need to be a short delay so the chip has time to realise that it's being woken up. at 16MHz, each clock is 62.5nS so two clocks would be sufficient if you want to set it to the absolute minimum permissible

---

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

I'm on my laptop, so here is the code.

Note that though this code compiles, it's not been tested. It's mostly copied from more standard sources and glued into triffid's code, so it should in theory work fine.

It DOES block while waiting for the A/D conversion to complete though. look for a "TODO" in the code marking that spot.

This is temp.c from an earlier version of triffid's code, modifed for a thermistor.

Good luck.

---

--
I'm building it with Baling Wire

Thanks a lot jgilmore. I haven't had a chance to upload it and try but perhaps something like this?

if (bit_is_set(ADCSRA, ADSC)){
     raw.bytes.low = ADCL;
     raw.bytes.high = ADCH;
     old_low = ADCL;
     old_high = ADCH;
} else {
     raw.bytes.low = old_low;
     raw.bytes.high = old_high;
}

in place of this

while (bit_is_set(ADCSRA, ADSC));
raw.bytes.low = ADCL;
raw.bytes.high = ADCH;

Demented

Edited 1 time(s). Last edit at 07/12/2010 11:59AM by Demented Chihuahua.

---

[www.urbansurvivalists.com]

Hi Triffid

I am interested in trying your code.

I downloaded and successfully compiled using the Arduino IDE with board set to diecimila.

I noticed earlier you indicated it would probably also work with the Mega. If I set this as the board I get a compile error PRR undeclared. I realise this must be something different on the Mega but I have limited knowledge of Arduino coding. Can you guide me as to the changes needed. I guess a define will be needed somewhere that indicates the board type so eventually all boards can use your code.

Also I am using a Thermistor using Temperature Sensor V1.0

I will try to understand jgilmore's temp.c code.

Edited 1 time(s). Last edit at 07/12/2010 01:07PM by emt.

---

Regards

Ian