Project: Teacup Firmware

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

> 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
>
Are you sure of the format? I would interpret the protocol definition to mean "rs 1" instead of "rs N1". and which number is right in the example reply? That's what libreprap is expecting, I think.

rs N1 is what replicatorG expects, haven't tried with libreprap

---

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

What other firmwares send? What does the java host expect? If there is some consensus, then that should be clarified in the protocol standard and implemented in libreprap. Going forward, libreprap should be the reference host side protocol implementation to test with, and hopefully the implementation used by all host software. I'ts a proper standardization effort, and I'm debugging for/with RepSnapper 2.0.

created new repository at https://github.com/triffid/Teacup_Firmware for further development. Contains same history as old repository except for the integer square root function I just pushed. Please update your remotes, wiki, etc

---

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

Triffid. FiveD, which is the reference implementation, uses "rs n" instead of "rs Nn", and that's what is the most straight forward interpretation of the standard. RepG should except that too, and since it's compatibility to FiveD is newer than other host software, it definitely shouldn't dictate the defined protocol. Nontheless, libreprap should be compatible with both, since it should be easy.

elmom Wrote:
-------------------------------------------------------
> Triffid. FiveD, which is the reference
> implementation, uses "rs n" instead of "rs Nn",
> and that's what is the most straight forward
> interpretation of the standard. RepG should except
> that too, and since it's compatibility to FiveD is
> newer than other host software, it definitely
> shouldn't dictate the defined protocol.
> Nontheless, libreprap should be compatible with
> both, since it should be easy.


From what I can tell repG sets everything to lowercase before doing anything.
so "n" or "N" doesn't matter(edit: ah you meant rs # as opposed to rs nN#), but more then that repG looks for rs || resend: from there it only matches on a number ignoring any non numeric characters so it really doesn't matter (edit: need to look at repsnapper source code I have, but i think it ignores the "N" as well ). be careful with repsnapper as it sends negative numbers when sending single commands from the host interactive tab. this causes issue if Require line Numbers is set.

Edited 1 time(s). Last edit at 02/24/2011 10:09AM by Architect.

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

pcb2gcode is one of the few applications used in RepRap and supporting imperial units only (despite a --metric flag).

Quote
Triffid_Hunter
> 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?

Are there plans to use this function in elsewhere? Other than that, I can't see a regression in tailoring the integer maths to the few cases we have.

Quote
Architect
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 [...]

Both of them are checked and respected if present, regardless of how the flags are set. Settings these flags means to throw an error in case they're missing. This is how official FiveD used to work a year ago and probably still works.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote

created new repository at [github.com] for further development.

Hmm. No write access anymore

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> created new repository at
> [github.com] for
> further development.
>
> Hmm. No write access anymore

I did add you as a collaborator.. maybe it didn't take, my internet connection is a bit unreliable like that. Try now

---

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

I wonder.. since we're not checking endstops in dda anymore, can we move all the calculations to the end, in the interruptible zone and store the results in a flag to reduce how long this particular interrupt hogs the cpu? Perhaps then provide some defines for checking endstops when the flags are checked, for those few of us with reliable, noise-free endstop solutions

---

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

Would we then put a check for this flag back in the dda_step?
Mine are noise free now :-)

those of you interested in endstop polling, higher baud rates, or just general testing, please check out the 'endstop' branch. I have reordered dda_step so that 1) it disabled interrupts for a significantly shorter period of time and 2) can poll endstops with some debouncing. I haven't been able to test if it does anything really crazy yet, so please try it and tell me - pull requests are best, but any comment is welcome

---

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

Quote

I did add you as a collaborator.. maybe it didn't take, my internet connection is a bit unreliable like that. Try now

Thanks, works great now.


Regarding endstops: I obviously missed a discussion and implemented them with a minimum change of code. Before committing that, I'll add that ALWAYS_STOP_ENDSTOPS flag from the endstops branch, too.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

P.S.: I've a failing testcase here which messes up the whole DDA thing:

1. Reset the controller, move Z20.

2. Move back to Z0 slowly and trigger the min endstop manually early, so the Z axis doesn't reach the target and stops near, let's say, Z8. Now, debug output in clock.c (the regular 1 second print) reports Pos where the axis actually is and Dst where it can't go.

3. Release the endstop and try to reach Z0 again. If you just command G1 Z0, nothing will happen, because something considers the axis to be at target already. If you do a G1 Z6, the axis will start in the wrong direction and never reach the intended target. Funny timings happe, like 1 step every second, or sudden partial movements.

Probably the messup happens because after an endstop trigger, the next movement will start from a situation with Dst and Pos differing. Obviously, dda_start() or somewhat can't deal with that.

All that said, I'm not sure wether this can apply to real world situations, with firmly mounted endstops.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

hm definitely needs fixing though, I think it's caused by some things using startpoint, and others using current_position interchangeably, when they're really not interchangeable at all- especially as regards to setting dda[move].x_direction and friends.

what's the correct behaviour here? obviously moving towards the actual target, but does that mean we calculate x_direction and friends in dda_start instead of dda_create? what else will we need to move to dda_start? what effect will this have on intra-move step rates during normal operation?

my feeling, upon first cogitate, is that we should re-run dda_create if the endstops cause a substantial difference between startpoint and current_position, and let the user stab their gcode slicer or disable poll_endstops_all_the_damn_time when the whole thing keeps pausing because it's confused

---

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

Triffid, yes, making libreprap accept all the used formats should be done (will do), but following the actual standards definition is still the right thing to do. or change the standard to something that is really used (and please ask others beforehand). There is a reason the standard is there in the first place. To make everyones life easier.

Elmo

Standards are always the lowest common denominator and hold back progress. Not a good thing at all in a project that is constantly evolving.

---

[www.hydraraptor.blogspot.com]

Quote

Standards are always the lowest common denominator and hold back progress. Not a good thing at all in a project that is constantly evolving.

I'd phrase that a bit different: Standards are the common ground you can evolve from. If you deviate from standards, you should have a reason.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

nophead Wrote:
-------------------------------------------------------
> Standards are always the lowest common denominator
> and hold back progress. Not a good thing at all in
> a project that is constantly evolving.

I think this was hashed enough on reprap-dev, most of us would like for firmwares and host softwares be comptible with each other as much as is *reasonable*. Markus is right, there is no reason not to follow the protocol standard on this.

Quote

what's the correct behaviour here?

Probably something which allows homing and doesn't mess up the coordinate system, i.e. if you run from Z10 into the endstop and them back to Z10, the carriage should be at the same place. That might not always be possible, because steppers loose steps when suddenly stopped from high speeds, but it'd work at least at slow speeds.

Quote

does that mean we calculate x_direction and friends in dda_start instead of dda_create?

As dda_start() runs at interrupt time between moves, this would be pretty costly.

How about simply counting the missed steps? (ideas spring to mind as you talk about them, right?)

if ( ! z_min())
  z_step();
else
  z_missed++;

On moving back out, you'd count them back and end up where you were:

if (z_missed)
  zmissed--;
else
  z_step();

Doing this for each axis individually, you could still maintain the other axes on combined movement. The carriage would "slider" along the endstop with a hit.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

If an endstop is triggered during normal, non homing, operations I doubt there is a sane way to handle it. Every scenario I can think of would ruin the print. You are betting off stopping the gcode processing and waiting for user intervention.

Lets say you want the safest way to keep going... Record where the endstop hits, don't allow that axis to keep stepping in that direction but recording its position as if it was moving farther past that endstop. Then only start stepping again when the axis goes back past the point where the stop triggered. So you could go +10, hit stop at +7, physical stops at +7 but record position as +10. Now moving -10 from there would go -3 virtually and then -7 physically. A lot of work for a result that would not be the correct tool trajectory and would result in plastic being piled up on that +7 boundry.

2 votes for the same solution, let's go with that

---

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

What would be nice is the option to record errors in endstop movements, and be able to recall the info after a print. You'd want a way to clear the history as well, which would be sent at the start of a print.

With such a command you'd see a list of X/Y/Z that don't match what the home command said, which would be very useful when calibrating and shaking down bugs in a machine.

Note: This is just an 'optional' thing, that wouldn't be reported normally if you didn't have it enabled (or if the commands weren't sent).

I'm here to report another successfully printed object using the Teacup firmware.




The copy on the left was printed without any changes to the firmware beyond configuring the config.h file. The copy on the right was printed after the code changes outlined below along with some Skeinforge tweaks that really did not help matters much. The hardware used consists of an Atmega328p, Pololu drivers and a thermistor, all running a standard Sell's style Mendel.

In fact the firmware restarted right at the start of the first print (unbeknown to me at the time), which explains the problem with loose plastic threads in the lower half of the object (the z-axis zero position was wrong). I've tracked the problem down to an issue with z-axis resolution. With the standard Ramps configuration on a standard Mendel STEPS_PER_MM_Z comes out to 6667 (using the calculation in the config.ramps.h file). UM_PER_STEP_Z is then calculated as zero. This breaks the rate limitation code for the z-axis which ultimately causes the firmware to hang or restart if the rate specified in the gcode is too high.

I've patched the code to rescale the z-axis calculations as follows in daa.c:

#define TEN_NM_PER_STEP_Z (100000L / ((uint32_t) STEPS_PER_MM_Z))
...
distance = dda->z_delta * TEN_NM_PER_STEP_Z / 100;
...
distance = approx_distance_3(dda->x_delta * UM_PER_STEP_X, dda->y_delta * UM_PER_STEP_Y, dda->z_delta * TEN_NM_PER_STEP_Z / 100);
...
c_limit_calc = ( (((dda->z_delta * (TEN_NM_PER_STEP_Z * 24L)) / dda->total_steps) * (F_CPU / 40000)) / MAXIMUM_FEEDRATE_Z) << 8;

The changes may cause some problems at the other end of the scale - a potential issue I have not examined.

I would like to extend a thank you to Triffid_Hunter and everyone else who contributed to this firmware - it has turned out to be a very nice piece of software.

Now I need to spend some time tweaking my Skeinforge settings.

Edited 2 time(s). Last edit at 02/26/2011 01:51AM by madscifi.

Quote

With the standard Ramps configuration on a standard Mendel STEPS_PER_MM_Z comes out to 6667

Hmm. Everything above 4190.000 (22 bits) is subject to variable overflow. It'd be probably a good idea to reduce microstepping here. RepRap mechanics don't perform well in the sub-micrometer area, anyways.

Quote

[...]
The changes may cause some problems at the other end of the scale - a potential issue I have not examined.

For feedrate and direction calculations without acceleration or with ACCELERATION_RAMPING we could just shorten the movement taken into account. The actual distance moved is independent from these maths.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Cefiar Wrote:
-------------------------------------------------------
> What would be nice is the option to record errors
> in endstop movements, and be able to recall the
> info after a print. You'd want a way to clear the
> history as well, which would be sent at the start
> of a print.

we don't have the memory to store such a list on the atmega, but I think that commenting in the message space after returned OKs would be a sensible way to do this. Hosts are well equipped to store large lists of arbitrary text (such as this firmware)! Then you just need to convince your host-side talker to supply this information at the end of a print, or whenever it might be appropriate. Who wants to send patches for repg, reprap host, repsnapper etc to show returned messages during/after a print?

madscifi Wrote:
-------------------------------------------------------
> I'm here to report another successfully printed
> object using the Teacup firmware.

excellent! thanks for the photo and report perhaps we should start a new thread specifically for photos of successful prints using teacup? post hardware details too, and speeds

> With the standard Ramps configuration on a
> standard Mendel STEPS_PER_MM_Z comes out to 6667
> (using the calculation in the config.ramps.h
> file). UM_PER_STEP_Z is then calculated as zero.
> This breaks the rate limitation code for the
> z-axis which ultimately causes the firmware to
> hang or restart if the rate specified in the gcode
> is too high.

yikes, you need less microstepping on your Z axis! I think traumflug is right on this one, if you really want <1uM steps, use EMC2 or official FiveD or something that does all its math in floating point. Feel free to keep applying your changes locally but I don't think we'll put them in mainline- as you suspect we already do have trouble at the other end, and I see this extreme Z precision as the unusual case which few will benefit from us addressing. We're already doing lots of madness trying to squeeze as much as possible from 32 bits, which makes things rather slower than I'd like on our little 8-bit processor!

Do you have any good reasons for such extreme Z precision that others may be interested in, apart from noise reduction?

---

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

Triffid_Hunter Wrote:
> Who wants to send patches for repg,
> reprap host, repsnapper etc to show returned
> messages during/after a print?

I am willing to give it a shot with RepG.

---

-Steve

I agree that I should reduce the microsteps on the z-axis. To be honest I used the high microstep setting simply because that is how it is configured in the config.ramps.h file included with the source. It looks like half-stepping is the limit for standard reprap designs as any steps-per-mm value greater than 1000 will cause the associated um-per-step value to be zero, triggering the problem I encountered. Maybe a compile time check to verify that specified steps-per-mm values are not too large?

The leftmost print was printed at 16mm/s, the second at 24mm/s. While these speeds are slow compared to what some people are getting, compared to my repstrap they are blazingly fast.

Triffid_Hunter Wrote:
-------------------------------------------------------
> Cefiar Wrote:
> --------------------------------------------------
> -----
> > What would be nice is the option to record
> errors
> > in endstop movements, and be able to recall the
> > info after a print. You'd want a way to clear
> the
> > history as well, which would be sent at the
> start
> > of a print.
>
> we don't have the memory to store such a list on
> the atmega, but I think that commenting in the
> message space after returned OKs would be a
> sensible way to do this. Hosts are well equipped
> to store large lists of arbitrary text (such as
> this firmware)! Then you just need to convince
> your host-side talker to supply this information
> at the end of a print, or whenever it might be
> appropriate. Who wants to send patches for repg,
> reprap host, repsnapper etc to show returned
> messages during/after a print?

I had a feeling that this might be the case, but thought the idea still had merit (ie: should be mentioned) and that someone would suggest an alternative.

If implemented host-side, it'd be really useful (after a print of course) have the host be able to show exactly where in the print these happened (ie: in-line with the g-code). That would allow someone to see if the issue always happens after certain g-codes (ie: it's related to that g-code or what that g-code does on the machine), which would be a REAL bonus, especially if the issue was firmware-based.

Cefiar Wrote:
-------------------------------------------------------
> I had a feeling that this might be the case, but
> thought the idea still had merit (ie: should be
> mentioned) and that someone would suggest an
> alternative.

Yep, that's what we're here for

> If implemented host-side, it'd be really useful
> (after a print of course) have the host be able to
> show exactly where in the print these happened
> (ie: in-line with the g-code). That would allow
> someone to see if the issue always happens after
> certain g-codes (ie: it's related to that g-code
> or what that g-code does on the machine), which
> would be a REAL bonus, especially if the issue was
> firmware-based.

I think we can do this by adding line number to the dda so it can tell us what it's doing despite queue status

---

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