Project: Teacup Firmware

Here are a few patches.

Quote

Here are a few patches.

0001: applied as is.

0002: added an empty line for cosmetics.

0003: Not sure wether it's a good idea to switch off the Z stepper while only X and Y are moving. Stepper motors without current snap back to their natural positions and in conjunction with half- or microstepping this means step losses. The patch fits to what's done in dda_start() though, so I applied it.

0004 was sent by sw yesterday already: [github.com]

0005: applied.

0006: good catch ... and delayMicrosecondsInterruptible really should take F_CPU into account.

0007, 0008: Not (yet) applied. For homing, we have G28 already? Perhaps I'm missing some recent development, but what's the intended purpose of the already existing G161, G162 and the now proposed G163? Neither of them is mentioned on the RepRap G-Code Wiki page.

0009, 0010: Not applied. Similar patches were done by sw and Triffid on 20/02/2011 already. In general, it's a good idea to do a "git pull" along with eventually neccessary fixes before publishing patches

0011: Not applied. This is identical to what's in the repo already?

0012: applied as is.


Thanks a lot for the patches, Markus. Having the work split up into a bunch of topic-related pieces is most welcome.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

thanks markus, luckily they didn't conflict with traumflug's patches.

I noticed that temp.h wasn't the only desynced file in extruder/, I think I got the rest. Curious: do they hardlink when you pull the repository? I have them hardlinked here because windows doesn't do softlinks.

---

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

Traumflug Wrote:
-------------------------------------------------------
> 0007, 0008: Not (yet) applied. For homing, we have
> G28 already? Perhaps I'm missing some recent
> development, but what's the intended purpose of
> the already existing G161, G162 and the now
> proposed G163? Neither of them is mentioned on the
> RepRap G-Code Wiki page.

technically, G28 is for going to zero, and G92 is for adding an offset to absolute position. Neither should be used for homing using endstops, so I did some googling and makerbot uses G16x for homing using endstops.

Also, have been lots of requests (here and in other threads and on blogs and in irc, not necessarily related to teacup) for ignoring endstops during printing, and only using them during homing, with only a couple of requests to the contrary, hence the separate file and extra routines.

It has been discussed in this forum afaik, albeit across several pages, several pages back. I'm not surprised you missed it while concentrating on your other projects


Just had an idea, perhaps we could add a flag to the dda for endstop behaviour, die_when_all_axes_hit_endstop or something so we don't need the majority of home.[ch]? Could potentially change ALWAYS_POLL_ENDSTOPS to a soft-flag rather than preprocessor directive if we're going to include the endstop code for homing anyway.


btw, what does everyone think of my shrinking the exclusive section of dda_step at the expense of not doing math /before/ the steps?

---

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

Traumflug Wrote:
-------------------------------------------------------
> 0003: Not sure wether it's a good idea to switch
> off the Z stepper while only X and Y are moving.
> Stepper motors without current snap back to their
> natural positions and in conjunction with half- or
> microstepping this means step losses. The patch
> fits to what's done in dda_start() though, so I
> applied it.
I haven't found a better place to disable the z-stepper after a z move.

> 0007, 0008: Not (yet) applied. For homing, we have
> G28 already? Perhaps I'm missing some recent
> development, but what's the intended purpose of
> the already existing G161, G162 and the now
> proposed G163? Neither of them is mentioned on the
> RepRap G-Code Wiki page.
I just saw G161, G162 and thought G163 for home all would make sense. It seems triffid added G161/2 not sure about his motivation.

> 0009, 0010: Not applied. Similar patches were done
> by sw and Triffid on 20/02/2011 already. In
> general, it's a good idea to do a "git pull" along
> with eventually neccessary fixes before publishing
> patches
>
> 0011: Not applied. This is identical to what's in
> the repo already?
I was just trying to resync a/* and a/extruder/*.


Triffid Hunter Wrote:
-------------------------------------------------------
> Curious: do they hardlink when you pull the repository?
Apparently not. Does git really support hardlinks?
The main problem seems to be the arduino ide, which only compiles stuff in one folder.

crc.c crc.h is also needed in /extruder, because heater.c needs it. Now how to get non default PID values to the extruder board is an intresting question. Which in anyway results in an intercom change.

Possibilities:
1. put everything into an intercom packet incl pid values
2. change the protocoll to send commands to the extruder, like official firmware
3. dumb down the extruder board so it receives pwm / digital io values, and sends back raw analog readings. All calculations is then done on the "mainboard"

I lean towards possibility 3. Half of the files in extruder/ could be deleted.

Personally, I lean towards alter or abuse the existing protocol. I really like how we hand over lots of processing to the extruder board when it's present, in the same way that we hand over all sorts of stuff to the hardware in the atmega chips. Also, we have tons of spare space on the extruder's 168, no reason to not use it

If we expand the protocol, I propose we replace temp[3] with a miscellaneous long and a pair of descriptor bytes which describe what's in the long- PID values (use 2nd descriptor to say /which/ PID factor for /which/ heater) or dio from mother->extruder, temps (can fit 2 temps in 32 bits) from extruder->mother. We could make the descriptors directly mirror M-words, with some extensions for internal stuff. This keeps the packet relatively short (same size as current protocol!), but will require multiple packet exchanges to read more than two temperatures. Since we get PID values one at a time from the host already, we can simply pass them through directly with an early packet exchange or something.

---

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

by the way, has anyone tried having heaters defined both on the extruder and the motherboard at the same time? I vaguely remember some code going in around that, but I don't think it got fleshed out and tested. I'd really like that capability just to keep the whole temp/heater thing generalised. I don't mind requiring that the temp sensor and heater are connected to the same chip however, that just makes sense to me in case of comms disruption or other fault possibilities.

---

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

There's some ugly bug in the intercom I'm not able to catch: The extruder stops listening after some time because the disable_transmit() in USART_TX_vect is never called. If I put the disable_transmit() in USART_UDRE_vect it works like a charm, but like that it doesn't send out all bytes.
It seems that under some circumstances USART_TX_vect gets not called, altough the interrupt is enabled and data is still in the shift register. Strange

Do we correctly disable reception while transmitting? That delay in start_send could allow the tx buffer to empty before we set tx interrupt flag.

In fact delays that long in interrupt context set off all my bells, can we move it to main loop via a flag?

---

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

Quote
Triffid_Hunter
technically, G28 is for going to zero, and G92 is for adding an offset to absolute position. Neither should be used for homing using endstops, so I did some googling and makerbot uses G16x for homing using endstops.

Hmm. That differs from the RepRap Wiki. They explicitely mention G28 to search the endstops, there. So, G28 and G163 are equivalent? For going to zero, there's G0XYZ ;-)

Quote

Also, have been lots of requests (here and in other threads and on blogs and in irc, not necessarily related to teacup) for ignoring endstops during printing

I see. We're expected to compensate for unreliable endstops in software.

Quote

Just had an idea, perhaps we could add a flag to the dda for endstop behaviour, die_when_all_axes_hit_endstop or something so we don't need the majority of home.[ch]?

Sounds good. 280 lines of code (home.c) just for moving axes into the endstops is a bit much for my taste.

Quote

btw, what does everyone think of my shrinking the exclusive section of dda_step at the expense of not doing math /before/ the steps?

Sorry, didn't have the time to look at this, yet. Is it expected to solve the problem mentioned in the second half of this post?

Quote

do they hardlink when you pull the repository?

No, no hardlinks received on this end (Ubuntu). Linking two files in an Arduino-and-Git-compatible way would be to create files with just an #include "../.c" in it.

Quote
Markus Amsler
I haven't found a better place to disable the z-stepper after a z move.

The place is fine, I just wouldn't disable Z steppers during a build at all. Not my problem, though, as my electronics can't disable steppers individually at all

Quote

I was just trying to resync a/* and a/extruder/*.

Sorry, missed the bit the new files are in extruder/ . As Triffid is apparently working on this, I'll keep my fingers off this for now.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Triffid_Hunter Wrote:
-------------------------------------------------------
> Do we correctly disable reception while
> transmitting?
I think so

> In fact delays that long in interrupt context set
> off all my bells, can we move it to main loop via
> a flag?
Looks like its no needed anymore.

I found the problem. disable_transmit() gets called, but theTX_ENABLE_PIN stays sometimes(1% or so) high. Altough there's a WRITE(TX_ENABLE_PIN,0); in disable_transmit. A big delay before disable_transmit doesn't help. If I set a flag in disable_transmit and do the WRITE(TX_ENABLE_PIN,0) in the main loop it works.

Seems like I can't pull down TX_ENABLE_PIN in interrupt context???

Traumflug Wrote:
-------------------------------------------------------
> I see. We're expected to compensate for unreliable
> endstops in software.

Yes. Hardware is expensive to fix, and has to be fixed on every machine. Software is fixed once and fixed on every other machine for free. It's far cheaper and more reasonable to compensate for unreliable hardware as much as possible in software.

---

--
I'm building it with Baling Wire

Sane Handling of Endstop values:

There are three very different scenarios where an endstop is triggered during a regular DDA movement.

First, your g-code generation may be screwed up royally, or just not set correctly for your machine. Basically, your machine is being told to move outside of its physical envelope.

If that's the case, then the proposed solution (tracking "supposed" position virtually) is as correct as you can hope to get. Though halting the print is also a reasonable option, and if there is an e-value, halting the print is probably far better. In any case, g-code specifying locations outside the physical envelope should be treated as equivelent to at least a "compiler warning" - an intelligible warning message should be sent back to the host so the user can correct the g-code generation. This is "software endstops" implemented in the firmware, essentially.

Second, you may have missed steps, and the position you're at isn't where you should be. In that case, we could re-caluculate the DDA's and adjust current_position to be correct, but the error is probably small enough that isn't needed. Also that would be the appropriate place to send a message to the host with the offset amount (in steps would be fine) so people can tell when their machine is skipping steps for some reason. If we're way off, halting the print is probably the reasonable action, but re-zeroing the physical location is also a reasonable action.

It's fairly simple to tell the difference between these two if we know what our current physical position should be. Just compare the target position with the known physical envelope. Adjust the dda in dda_create if it's out of bounds. However, Teacup doesn't currently track real physical position. "current position" is reset by the set home command.

We could have G92 set a "home position" variable instead, and translate everything into physical coordinates in dda_create. Or maybe in g-code process, in the same place as we adjust relative/absolute positioning? That might be better, as then special commands (home, etc) can have targets outside physical boundaries. Either way, dda_create or process_gcode can then check incoming targets against the physical envelope. And give a useful error message there.

Third, it may just be noise. If physical position is way away from the real endstops, maybe we should just assume it's an error and ignore it unless it's on for 100ms or so, and then pitch a fit and halt the print with an error message?

I'm of the opinion that endstops should be for the most part ignored during an actual print, and if the host g-code generation is correctly done and the machine doesn't skip steps this isn't a problem. But if either of those isn't true, then the presence of all six hardware endstops can be an important safety measure. That is why I specified such a long time for endstops debounce for noise time. If you're traveling at 3000mm/min, (very fast) 100ms is still only 5mm, which should still be plenty short enough to keep even a very strong-steppered and weak framed machine from damaging itself.

Huh. Real physical boundaries could be set in the config file, but it might be nice to save them in eeprom and set them either via directly gcode (use the debug interface, it's easy), or with a "home to all six endstops, determine empirically the build volume, and store that information in eeprom" which could actually be done with a special sequence of g-code if all of the above was implemented. It would go like this - re-zero based on the min endstop, reset the physical build area in ram to a huge value, seek that direction till the firmware pitches a wobbly about hitting the max endstop, save that value in eeprom. Repeat for the other three axises.

---

--
I'm building it with Baling Wire

Quote

Traumflug Wrote:
-------------------------------------------------------
> I see. We're expected to compensate for unreliable
> endstops in software.

Yes. Hardware is expensive to fix, and has to be fixed on every machine. Software is fixed once and fixed on every other machine for free.

Trying to compensate hardware failure in software is hardly a "fix". You can do some wild guesses, but as long as hardware behaviour is unpredictable, software behaviour will be unpredictable as well. Perhaps unpredictable in a more convenient range, but that's all one can do. Just like it's nicely explained in your next post.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Would it be difficult to implement something in the firmware to activate a multiplexer for multiple thermocouples off a single AD595 (or similar)?

That way you could limit the hardware cost for a heated bed and extruder, since 595s are so darn expensive.

Just use a thermistor. Thermocouples aren't needed because the bed temperature is low, and so is the accuracy.

Vik :v)

Quote

btw, what does everyone think of my shrinking the exclusive section of dda_step at the expense of not doing math /before/ the steps?

Now I had a look and yes, that's an excellent idea. To avoid the delay of one step, we could jump from dda_start() right into dda_step(), instead of waiting for the timer to do this.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

In mendel.c, I see a bunch of these:

WRITE(X_STEP_PIN, 0);	SET_OUTPUT(X_STEP_PIN);

Is there a reason why there's a bit written _before_ the pin is configured as output? Wading through ATmega's reference, I can't find one.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I prefer setting whether the output will be low or high /before/ we kick in the high current drivers that will force it to that state, so there's less of a glitch when they do.

Never trust reset states- we simply don't know if the bootloader has done something funky (eg debug led pin is usually set as output coming out of bootloader), or we've reset in an unusual way or something like that.

---

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

That goal makes sense. However, either the pin is an output already and the write does what you want to avoid, or it's coming as an input from the bootloader and you just disable the pullup resistor. Anyways, as that's only a few bytes of code and doesn't eat up precious RAM, it can probably be left in place.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I am loving the teacup firmware so far - and almost to the point where I can print

I have a minor issue in the firmware - I am running my own custom electronics and in mendel.c the SPI init comes after setting up stepper pins. I wired a stepper to the MISO pin and I have to comment out the spi init so that MISO does not turn into an input. Perhaps moving the SPI gpio init stuff before the stepper IO init - or making a mention in the config.h not to use that pin might help some confusion in the future.
I think moving the spi init before the stepper init routines would be the best option.

Hello again!

I have (Formerly 5D for arduino release branch) on an atmega 328.

When I try and run the host software I get to the initializing arduino/sanguino, the sending N0 M110 *3 (dequed and sent) and then nothing... I get the impression the host is waiting for something to be sent back that isn't.

The entire screen is here [i211.photobucket.com]

I've also tried using hyper terminal to contact the Arduino, using the Xon/XOff flow control and the proper 57600 baud rate. The only response or action I could get was some gibberish right after I reset the board.

Any ideas?

Quote

using the Xon/XOff flow control and the proper 57600 baud rate

57600 might be the right baud rate for the bootloader, but if you run Teacup, you want to set your sending application to 115200. The bootloader and the actual firmware differ in the baud rate.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

People get worked up about high baud rates, but even with 19200 baud I seem to have no problem filling teacup's buffer.

Vik :v)

Changing the settings to 115200 worked!

It's really confusing that there are different speeds for different things. I assumed incorrectly setting the 57600 in the firmware was for the communication for the host.

Finally have a stepper moving a little bit with the "nudge axis position" Seems to be trying to step at an awkward rate still and won't work for more than a .1mm nudge. Computer controlled movement is progress! I'm assuming playing with the acceleration and max mm/min settings will fix that.

kiram9 Wrote:
-------------------------------------------------------
> I have a minor issue in the firmware - I am
> running my own custom electronics and in mendel.c
> the SPI init comes after setting up stepper pins.
> I wired a stepper to the MISO pin and I have to
> comment out the spi init so that MISO does not
> turn into an input. Perhaps moving the SPI gpio
> init stuff before the stepper IO init - or making
> a mention in the config.h not to use that pin
> might help some confusion in the future.
> I think moving the spi init before the stepper
> init routines would be the best option.

this is a bug. I pushed a commit for you, wrapping an ifdef TEMP_MAX6675 around the spi init section as this is the most correct way to fix this issue.

Vik Olliver Wrote:
-------------------------------------------------------
> People get worked up about high baud rates, but
> even with 19200 baud I seem to have no problem
> filling teacup's buffer.

It may be fine for printing, but debug is terrible at 19200. Plus, running at 115200 forces us to keep our interrupts short- if an interrupt hogs the processor for longer than it takes to receive one byte, we lose data. This makes long-running interrupts a very visible issue rather than allowing them to hide

---

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

Thanks! Pulled the updated version and it looks great!

Guys

A trivial thing.

Is it worth renaming the output files from mendel to perhaps teacup. A further disambiguation thing.

I built the final firmware of 5d for my Huxley-Stretch and it compiled first time with minimal tweaks.

I have just done the same with Teacup too, great work.

Cheers

Aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

hi all, please test endstop and intercom-protocol branches, tell me whether they're ready for merging, or post patches if not

---

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