Project: Teacup Firmware

alianmac Wrote:
-------------------------------------------------------
> Using
> reprap host 20100806 I get this message. I have
> made no changes to the config.h file.

show us the actual serial data going back and forth. I have no idea how to do this on windows or with reprap host

---

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

Is what you were after?

I have putty installed, or a Linux machine I could use if you could take me through what I would need to do.

Traumflug, consider what happens when one issues a long series of x-axis only moves, each move only one quarter of a step in length. The internal position tracks to the precision of the math as the series of moves is executed, but since the delta in micrometers from one move to the next is always below that required to issue a step the x-axis never physically moves.

alianmac Wrote:
-------------------------------------------------------
> Is what you were after?
>
> I have putty installed, or a Linux machine I could
> use if you could take me through what I would need
> to do.

yep that's lovely. Looks to me like you have no temp sensors, so M105 is returning simply 'ok' and your reprap host is choking. nothing wrong with the firmware- it's returning zero results for your zero temp sensors in response to a 'return temperatures' command!

try a different host talker, there are plenty.. even something like the infamous send.py should work better than reprap host

---

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

Thanks! Do you have any recommendations? I've tried ReplicatorG too but that hangs whenever I try to use the control panel on my Gen 3 electronics as well as Gen 7.

Hi

I have a problem and I think its a miscalculating of the temperature from the thermistor readings and the thermistor table. I have done some testing of my thermistor and different thermistor tables. With this board and the test program on the bottom of the site I have good readings at room temperature but with teacup I have readings of T:4.0 and when I heat the extruder to 60 degree my thermometer is smelting and shows a temperature of more than 100 degree. I have changed than the thermistor table script by variing the resitor 2 and after some tries I had good readings with a R2 of 400 ohms but I have a 4.7 Kohm installed. So I think Teacup does somthing wrong with the thermistor readings. Can you shine some light on this mater?

Thanks Jörg

I am still struggling to get the motor to work.

I have been using PuTTY to talk to the firmware. It responds to the X command as I would expect e.g. typing in G1 X50 followed by M114 (repeatedly) produces lines that show the controller thinks that the motor has moved towards (and reached) X50.

However, if I connect a motor to the X-axis Pololu, the motor does nothing.

So I have repeated the process looking at the voltage on Pin 25. I believe that this is the pin that controls the X step. The voltage on pin 25 s 0.15V whilst the motor is inactive but only rises to 0.35V when I issue the G1 X50 command. Is this correct?

alianmac Wrote:
-------------------------------------------------------
> So I have repeated the process looking at the
> voltage on Pin 25. I believe that this is the pin
> that controls the X step. The voltage on pin 25 s
> 0.15V whilst the motor is inactive but only rises
> to 0.35V when I issue the G1 X50 command. Is this
> correct?

That's exactly what I would expect if you try to "see" a low duty cycle digital signal with your DMM. You really need something that can pick up short pulses, like an oscilloscope or logic analyser. Even a very bright LED would be better than your DMM! If you're convinced that the output voltage is too low, use a diode and capacitor as a peak detector, and measure that.

A4983s (the chip on the pololu carrier) is very easy to destroy. Any noisy connections between the chip and the motor will kill them very quickly. Have you checked all your axes? Do Y, Z or E work? Is your board getting 5v and 12v in all the appropriate places?

---

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

> Can we start with finding out what's different in
> your setup from mine? I have a STEPS_PER_M_X of
> 320000 and use absolute coordinates. What is
> yours? Can you find out how many steps are moved
> on 45 deg commands? They should be the same for X
> and Y, obviously.
I have a STEPS_PER_M_X of 10000. That explains a lot, as my steps are way bigger. I think you also had wandering, but with 3 microns/step you didn't notice it.

More generally for an open loop system with steppers the firmware has to count each step the machine makes, there's no way around it. There has to be another way to solve the UM_PER_STEP issue.

IMO a better way around UM_PER_STEP would be to store the speed as something more machine friendly like (cpu cycles)/step and do everything in steps, cpu cycles beyond gcode_parse.

Triffid_Hunter Wrote:
-------------------------------------------------------
> That's exactly what I would expect if you try to
> "see" a low duty cycle digital signal with your
> DMM. You really need something that can pick up
> short pulses, like an oscilloscope or logic
> analyser. Even a very bright LED would be better
> than your DMM! If you're convinced that the output
> voltage is too low, use a diode and capacitor as a
> peak detector, and measure that.
>
> A4983s (the chip on the pololu carrier) is very
> easy to destroy. Any noisy connections between the
> chip and the motor will kill them very quickly.
> Have you checked all your axes? Do Y, Z or E work?
> Is your board getting 5v and 12v in all the
> appropriate places?

Aha success! For interest to anyone else who has the same problem:

An LED on pin 25 lights up when sending an G1 X... command. The higher the feedrate the brighter the LED, although it never seems to reach the same intensity as the LEDs on the board.

Trying lots of different combinations of pololus in different positions produced the curious result of different axes working depending on which position a certain pololu was in. This specific pololu had previously produced some smoke so I suspected it had blown; luckily I had a spare. Not being able to figure out what the heck was going on, I removed all the jumpers controlling the microstepping (MS2 and MS3) and worked through each axis in turn, increasing the microstepping on success. All looked fine until the E axis - on half stepping it worked fine, but on 1/8th none of the axes worked! Turns out there was a connection between the MS2 and EN tracks invisible to the naked eye. Now that has been removed it all works.

Thanks a million for all your help

Markus Amsler Wrote:
-------------------------------------------------------
> IMO a better way around UM_PER_STEP would be to
> store the speed as something more machine friendly
> like (cpu cycles)/step and do everything in steps,
> cpu cycles beyond gcode_parse.

I didn't take into account that each axis may/will have different steps per mm, so for distance and speed calculations you can't simply use steps like I naivly thought.

The Uno32 chipKIT board looks like a really good candidate as a target for porting Teacup. The cost is currently slightly less than that of a Arduino UNO and it has more io pins available. The only real downside looks to be that is runs on 3.3 volts - the base Pololu boards support 3.3 volts so the only question is whether or not the heater mosfets can be adiquately turned on by 3.3 volts.

What I'm particularly interested in is the fact that is has five output compare circuits that can be used to trigger a voltage change on a pin and generate an interrupt at the same time. It might be possible to reduce jitter in the stepper pulses down to the resolution of the clock driving the compare circuits by using the output compare circuit to generate the pulse and the interrupt routine to set up the compare for the next pulse. It might be necessary to add an AND gate between the cpu pin and the stepper controllers so that an interrupt can be generated without generating a step for very slow operations.

Edited 1 time(s). Last edit at 05/22/2011 04:10PM by madscifi.

Quote

IMO a better way around UM_PER_STEP would be to store the speed as something more machine friendly like (cpu cycles)/step and do everything in steps, cpu cycles beyond gcode_parse.

Please try the fix to the fix attached.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug, I've taken a look at the patch and I believe it solves the drift problem (although I've yet to actually run the code). However, I think that all uses of x_delta_um in the dda_create function should be replaced by dda->x_delta * UM_PER_STEP_X. My argument is that the distance and limits should be calculated based on the actual motion of the machine, not the requested distance in um.

madscifi Wrote:
-------------------------------------------------------
> Traumflug, I've taken a look at the patch and I
> believe it solves the drift problem (although I've
> yet to actually run the code). However, I think
> that all uses of x_delta_um in the dda_create
> function should be replaced by dda->x_delta *
> UM_PER_STEP_X. My argument is that the distance
> and limits should be calculated based on the
> actual motion of the machine, not the requested
> distance in um.

problem then is that if STEPS_PER_MM >= 1000, UM_PER_STEP is zero, which is what traumflug is trying to solve in the first place!

---

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

Some of us peanuts should pay more attention... Thanks for pointing that out.

I'll just state the obvious and point out that best way from an accuracy point of view would be to write an appropriately scaled steps_x_to_um function and use that to convert dda->x_delta to um for use within the function. However, that is relatively expensive and I don't know if it would really be worth the execution time or not.

personally I like storing position internally as steps. We only need micrometers or whatever when calculating distance, and M114, neither of which needs full precision.

If we run in relative mode with the current code, we'll have wandering as well if steps/mm doesn't lend itself to conversion with no precision loss.

Unfortunately we can't store speed as ticks per step, as each axis has different steps/mm and so would have a different ticks per step for the same speed.


How about we store position internally as nanometers? That way, we have a range of +/-2.147m and tons of precision. We then work out NM_PER_STEP and add or subtract this when changing position. With extremes like 6400 steps/mm, we have 156.25nm per step and passing X200 will give us a resulting position at X=199.68 due to rounding 156.25 down to 156. At less insane precisions, we'll have even less rounding error.

The big question is, is it worth the change? Will the dda still count steps, or should it count nanometers? What other mathematics could be adversely affected by this change? Which formulae become more susceptible to overflow? I know we have to square some things in dda_create, so either we're limited to 16um moves or we have to convert to another unit for those calculations.

---

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

Perhaps the new approach doesn't change as much as it looks? After all, it just moves the conversion of the value given in G-Code from gcode_parse.c to dda.c. um_to_steps() does the same decfloat_to_int() did before.

That way you can store the commanded distance aside instead of doing a back-conversion.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

A couple of 64 bit operations (48 bits even) and this would be easy to resolve. Sadly, 64 bit operations on an atmega are extremely expensive. Just out of curiosity I coded a 64 bit conversion using long long to steps and another back to um. It added almost 5000 bytes to flash and over 200 bytes to ram. I did not bother looking at the execution time.

I was wrong about the use of the requested um as the distance being inaccurate - at least for certain cases. For very high resolution axis, such as the Mendel Z axis, the use of the requested um as Traumflug has done in calculating the motion distance turns out to be more accurate than back converting from steps due to limited precision required to avoid overflow.

I don't have an opinion as to which approach (steps or um or nm) is best in this situation. All of the approaches have issues given the limitations of the microcontroller, so something has to be traded off. The question is what?

I've successfully made the switch to Teacup firmware and I'm really liking it a lot. Thanks go to everyone who's answered my many questions.

I'm still working a few bugs out of my configuration and there's one thing about Teacup I don't understand. My start.gcode immediately turns on the heater and the heatbed and then homes. Then it hits a M109 and waits until the temperatures reach target. With Klimentkip/Sprinter and others I've used, the M109 wait was typical and predictable but with Teacup, it is much MUCH longer. Even if I preheat things before starting the print, the wait will still be 5 or 6 minutes. I have LEDs wired in so I can see when the heaters are on and they start flickering when the temp is at target but still Teacup waits.

I have TEMP_HYSTERESIS at 10
and TEMP_RESIDENCY at .25

but I've tried other values for both.

Anyone have any ideas or similar experience?

I don't think you need M109's when using PID heat control. I preheat and and just use M104's, If I blow directly on the heater block and the temperature drops it will stop the build until it reaching temp again.

I have TEMP_HYSTERESIS 5
and TEMP_RESIDENCY 1

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

sliptonic Wrote:
-------------------------------------------------------
> I've successfully made the switch to Teacup
> firmware and I'm really liking it a lot. Thanks
> go to everyone who's answered my many questions.

Excellent!

> With
> Klimentkip/Sprinter and others I've used, the M109
> wait was typical and predictable but with Teacup,
> it is much MUCH longer. Even if I preheat things
> before starting the print, the wait will still be
> 5 or 6 minutes. I have LEDs wired in so I can see
> when the heaters are on and they start flickering
> when the temp is at target but still Teacup
> waits.
>
> I have TEMP_HYSTERESIS at 10
> and TEMP_RESIDENCY at .25

I think residency should be an integer value

> but I've tried other values for both.
>
> Anyone have any ideas or similar experience?

I've had this happen to me when my PID parameters didn't match my heater block. The temperature would overshoot and undershoot for quite a while before settling down.

Having said that, with a residency of 1 it should fall through just after reaching target.

I'll look into it for you

---

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

Has anybody had problems with teacup randomly deciding to send some combination of the x/y axes to infinity during a print?

It seems to be a persistent random occurrence, happening with a frequency of once every 10 print hours or so. The soft limits do not seem to apply to this, as I've let it crash for 30min continuously (hundreds of meters of theoretical travel)

The host software (send-Gcode in my case) ceases to reply "ok" after the move to infinity, but it appears reasonable g-code was sent.

The Z axis nor the extruder ever seem to be involved.

Ideas?

Thanks! Other than this teacup has worked flawlessly so far.

What version are you running? I have seen Teacup send a stepper off into the wild blue yonder, but not for a long time (I don't remember what version it was). Also, can you post up your config file, that might, or might not, contain some clues? If you have not tried the latest in the master branch on github please do try it out.

Edited 1 time(s). Last edit at 05/26/2011 12:40AM by madscifi.

Andrew Diehl Wrote:
-------------------------------------------------------
> Has anybody had problems with teacup randomly
> deciding to send some combination of the x/y axes
> to infinity during a print?
try

#define STEP_INTERRUPT_INTERRUPTIBLE 0

in config.h

It is (was?) possible that the step interrupt interrupts itself, and the step counter goes below zero, and then count from 2^32 to 0 again.

Are you running current git/master?
I thought [github.com] should have fixed this issue.

I have not been running the current. I probably have a version over a month old. I hadn't switched because it was a multi hour project to change over, and the version I had was running perfectly 99.9% of the time.

Since It sounds like my issue has been resolved, I've begun the jump to the current master.

Markus,

The current master has

#define STEP_INTERRUPT_INTERRUPTIBLE 1

Should I be changing that to a "0" or only if I have problems from now on?

Thanks.

~Andrew

Another Question,

The method for calling out temp sensors has changed since my last version.

I'm trying to set up my ad595 thermocouple but I'm not really sure what to put in the "additional" column. Everything I've tried so far has resulted in a temperature reading of 0 through hyper terminal.


// name type pin additional
DEFINE_TEMP_SENSOR(extruder, TT_AD595, AIO3_PIN, _____)

Thanks again!

The additional field is currently only used for thermistors. There you can specify which thermistor table to use. It shouldn't influence thermocouples. Just put in 0.

Hi everyone,

I saw some troubles about the gen7 board with teacup firmware,
I'm experiencing strange 0.0 temperatures, and bad getTemps:


For instance:
ERROR: GCodeReaderAndWriter.getBTemp() - no value stored! [46,893s/1ms]
comms: G-code: N75 M105 *53 dequeued and sent [48,395s/1502ms]
ERROR: GCodeWriter.waitForResponse() - dud response from RepRap:T:0.0 B:0.0 [48,396s/1ms]
comms: Response: T:0.0 B:0.0 [48,396s/0ms]
comms: G-code: N75 M105 *53 dequeued and sent [48,396s/0ms]
comms: Response: ok [48,396s/0ms]
ERROR: GCodeReaderAndWriter.getETemp() - no value stored! [48,397s/1ms]

I guess it's a common mistake with the pin address. So it's getting some 1/0 division or something (perhaps not

>>Is a nice person using gen7 board have a nice config.h working to send me please? I tried several from this post and other ways but, I didn't get anything good until now...

Thx a lot,

PS: Everything else seems to work well, great job guys by the way !

> response from RepRap:T:0.0 B:0.0 [48,396s/1ms]

I had the same problem. I assume you generated new thermistor tables? There has been a change in table format, instead of a two-dimensional table it is now a three-dimensional table, and the python script still generates the old format. You need to add curly braces around the table.
Otherwise you need to double-check pin assignments, I was a bit confused by the different example configurations and pinout tables in the Wiki. The current version of Teacup seems to need an integer pin index, "1" for extruder and "2" for bed.
It looks like there are quite a few people having that problem and the designer of the hardware gets flooded in questions.

I'm considering writing a setup program similar to the Stepconf Wizard in EMC2, and somebody else is already working on a visual editor. Considering that many people will need very similar setups (with minor difference in stepper resolution and microstepping settings) because they base their printer on a common design it should really be easier to get a useable configuration out of the box.
Hopefully I get my printer finished soon so I can try this. (Or hopefully someone else beats me to writing an editor.)