Project: Teacup Firmware

hi all, just got a report that E step and dir are reversed in config.gen3.h vs official FiveD, can someone with gen3 test and confirm?

---

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

macegr Wrote:
-------------------------------------------------------
> While this is happening, you can use the M114
> command to view Teacup's idea of the axis
> position. In the command above, Y will increment
> by 1 every second or so, far beyond the target 10
> position. It will keep going forever. If you use
> an M112 to halt the move, then tell Y to go to 5,
> the same thing happens, it undershoots 5, and over
> the course of the minutes I was patient enough to
> wait, it will go negative below the soft limit.

I encountered this today when playing with the 'endstop' branch. current_position was being updated twice, so if the move had an odd number of steps on any axis it would overshoot and continue. I pushed a fix, but one wonders why you were on the endstop branch, if that's even what was going on?

---

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

I wasn't on the endstop branch. My problem was something to do with the Arduno Uno, remember? The exact same firmware loaded on a normal Arduino works fine.

aka47 Wrote:
-------------------------------------------------------
> Interesting.
>
> Although we were getting the initialization
> strings from the Firmware there was no response
> thereafter.
>
> Having a thermistor LUT over a certain size (don't
> know what the critical size is) appears to crash
> the serial transmit and or firmware.
>
> So not really intuitive but too big a Thermistor
> LUT screws with the firmware and the symptom is no
> return serial comms after an apparently successful
> power up and init string.

I've wondered about that. The search for temperature algorythm isn't very sophisticated. I wouldn't go so far as to call it bubble sort, but it's close. It looks at every entry in the table that is hotter than the current temperature every time it calculates the temperature. With a large table (how large was yours?) that could take a significant amount of time, especially when the heater is cold.

Maybe it should remember the last reading and start a few entries above it? Or we could do a binary search... Either would be faster than what we have now and would more than likely fix this.

Thing is, 20 entries should be just fine, small tables don't have a problem, and any other algorythm will probably take more flash space. Adding a comment to the effect of "tables should have at most 40 entries, large tables will crash the firmware" would be sufficient. Probably add that to the python-generated comment at the head of the table.

Is there a benefit to larger tables? How much is the maximum error amount, naive 20 entry table (evenly distributed) vs. one entry per ADC value?

Something should be changed, thank you for pointing that out. I had no idea it could cause actual real-life problems... The design isn't mine, it was copied from the original non-5D official firmware, along with the thermistor table generator.

---

--
I'm building it with Baling Wire

... i'm testing with a PT100 sensor, where the actual temperature is simply calculatetd by: temp = (Ohms_value - 100) / 0.385.

The only critical point is the small range from 100 Ohms at 0°C to 215.5 Ohms at 300°C, so i have to use a transistor for enhancing the voltage difference from 0 to 5 Volts for this range ...

---

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]

VDX Wrote:
-------------------------------------------------------
> ... i'm testing with a PT100 sensor, where the
> actual temperature is simply calculatetd by: temp
> = (Ohms_value - 100) / 0.385.
>
> The only critical point is the small range from
> 100 Ohms at 0°C to 215.5 Ohms at 300°C, so i
> have to use a transistor for enhancing the voltage
> difference from 0 to 5 Volts for this range ...

thanks for that Viktor, sounds like an ideal candidate for a current source.. about 23mA would be perfect I think. Could use a fair bit less (5mA) if you use your atmega's internal 1.1v reference instead of vcc. we only get ~half our ADC range, but I think 512 unique values over 300 celsius with an excellent degree of linearity is sufficient precision?

amplifying that section would work fine too and almost double precision, but not sure it's necessary

---

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

... the current through the PT100 shouldn exceed 1mA, so a current source with 1mA would be perfect ...

On my daywork we're sensing and controlling temperatures with PT100, PT1000 and Nickel-resistors (around Ni200, and heating with standard MOSFET's) to an accuracy of 0.001°C

---

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]

Markus Amsler Wrote:
>
> OS: Win XP
> slicer: Skeinforge 36
> talker: send-gcode.exe
> Electronics: standard Gen 3 with Extruder
> Controller v2.2
> firmware: Teacup master, with attached patches (I
> didn't clean them up, just whats in my tree)
> config: attached

Markus,

I'm also running gen3 electronics and just getting started with Teacup. Triffid_Hunter has been helping me on the IRC channel to get things working and also make the build work better through the arduino IDE. I now have things working pretty well on the motherboard but I'm not getting anything useful to happen on the extruder. Our debugging seemed to point to a problem with intercom.

Since this chat last night, I found your post with the patches. Could any of these patches address the problem I seem to be having? Do you have any other thoughts about this?

Sliptonic Wrote:
-------------------------------------------------------
> I now have things
> working pretty well on the motherboard but I'm not
> getting anything useful to happen on the extruder.
> Our debugging seemed to point to a problem with
> intercom.
The attached patch fixes the only problem I'm aware of with intercom. The intercom would die after some seconds (1-30).
Does the extruder stepper turn?

To debug intercom I used something like attached debug_intercom.patch on the mainboard. On the extruder I blinked with the LEDs on every received packet (debug_extruder.patch). Then you see where the packet is lost.

Here are some patches, this time cleaned up

Markus,
Thanks for the fixed up patches.


> Does the extruder stepper turn?
My extruder stepper is driven from a pololu wired to the SDA/SCL header on the motherboard. It does turn (only forward at this point, but I think that's just configuration)

>
> To debug intercom I used something like attached
> debug_intercom.patch on the mainboard. On the
> extruder I blinked with the LEDs on every received
> packet (debug_extruder.patch). Then you see where
> the packet is lost.

I applied all the patches, including the debug patches. I can see the LED next to the heater connector on the extruder blinking (very faintly/briefly) but definitely blinking. The serial monitor reports the 'R's coming from intercom. It won't connect to repsnapper with the debug code in, but without it, repsnapper connects and shows the thermistor at 866.25c (default temptable). Setting the temperature above this like 900c does not cause the heater to turn on. Connecting with the extruder unplugged, M105 reports: Receivedk T0.0 with parameter T:0.0*******************

Replacing the temptable with the one I always used from reprap firmware gives the same results but 213C.

So your intercom works, the problem is the heater on the extruder. Putting

DEFINE_HEATER(extruder, PORTD, DIO11_PIN, OCR2A)

into extruder/config.h should do the trick. Make sure the debug code is removed.

> on the extruder. Putting
>
> DEFINE_HEATER(extruder, PORTD, DIO11_PIN, OCR2A)
>
> into extruder/config.h should do the trick.

Forgive me, I'm not understanding you. That line is already in the config.h for the extruder but it is wrapped in and ifdef block. Here's my config.h. [pastebin.com]

After a Quick read of the last 2 new pages I feel relived that the problems, I have encounterd with all the various Flavors of Firmware & hostware and inter mixing are not peculiar to me..

I have one configuration that still works and I seem to always revert back to after every atempt at other combinations.

The only working every time combination I have found is the original Windows Repsnapper with original Tonokip Firmware.

The hardware I am using is 2 original gen3 V1.1 motherboards and 8 Gen3 2.3 stepper controllers. ( I do NOT use extruder controllers even though I have 4 of 7 extruder controller boards built.)!

I just change the pins to suit my build and the XYZ & E resolutions (all driven from the motherboard) it just works so this is what I am still using.

It seems on the last read of the last few pages of this Thread that there is a great need for a deffinition or a specific change log for all HOST - Firmware Communincations protocols / Combinations.

OR

A compatability table listing the specific combinations of compatible builds that work.. Maybe just having a Repository that has both the firmware and hostware zipped up in working combinations frozen in time as starter or refrence packages to download. ??

The table may need to be even more complex and take into account all the variations of hardware builds as well..
(I really hope this is not needed thou)

From my experiments I have a prefrence for the Teacup version fo Firmware.. However I have not yet managed to get it Fully working with any of the host combinations I have tried so far. It works great just sending manual commands without a host package.

I now have all the bits for a Ramps Board so that will be my next build to try out maybe this weekend...

Edited 1 time(s). Last edit at 03/26/2011 02:30AM by BodgeIt.

---

Bodge It [reprap.org]
=======================================

---

BIQ Sanguinololu SD LCD board	BIQ Stepcon	BIQ Opto Endstop
BIQ Heater Block PCB	BIQ Extruder Peek clamp replacement	BIQ Huxley Seedling
BIQ Sanguinololu mounting	BIQ standalone Sanguinololu or Ramps mounting	Print It Stick It Cut it

My rep strap: [repstrapbertha.blogspot.com]

Buy the bits from B&Q pipestrap [diyrepstrap.blogspot.com]
How to Build a Darwin without any Rep Rap Parts [repstrapdarwin.blogspot.com]
Web Site [www.takeaway3dtech.com]

sliptonic Wrote:
-------------------------------------------------------
> > on the extruder. Putting
> >
> > DEFINE_HEATER(extruder, PORTD, DIO11_PIN,
> OCR2A)
> >
> > into extruder/config.h should do the trick.
>
> Forgive me, I'm not understanding you. That line
> is already in the config.h for the extruder but it
> is wrapped in and ifdef block. Here's my
> config.h. [pastebin.com]

In your config is OCR0A, which is wrong OCR2A is the correct timer for heater PWM. I should have made myself clearer.

Also the heated bed does not work like this, because its on a non PWM able pin. Do you have a heated bed?

>
> In your config is OCR0A, which is wrong OCR2A is
> the correct timer for heater PWM. I should have
> made myself clearer.

Oops. Can't believe I missed that. I've changed it now but I don't see any change in symptoms or behavior. Still no change in thermistor readings and no LEDs turning on near the mosfets.

> Do you have a
> heated bed?

I will but it isn't installed yet.

sliptonic Wrote:
-------------------------------------------------------
> Oops. Can't believe I missed that. I've changed
> it now but I don't see any change in symptoms or
> behavior. Still no change in thermistor readings
> and no LEDs turning on near the mosfets.
In our pasted config you have

#define HEATER_PIN AIO1 //DIO11

which doesn't work, as DIO11 is the only PWM able mosfet on the extruder controller.
Try

#define HEATER_PIN DIO11

instead and wire your extruder heater to the middle mosfet.

One more bug to track down: I've noticed that when I turn Jitter on in Skeinforge 40, it produces Gcode that somehow manages to crash Teacup. I should make some Gcode to demonstrate the problem, haven't gotten that far yet. The crash happens some random point within the build. I don't think I've ever managed to complete a build that had Jitter enabled. Disabling Jitter resolves the problem in every case.

For fun, here's another couple of recent builds using Teacup:

SOmething I forgot to mention re the thermistor python script.

It refuses to run on my Ubuntu workstations (pretty much up to date Lucid, 64 bit and 32 bit)

Unless the character encoding is stated at the top of the script. Python was a bit picky.

So the first lines from the script were changed from:-

Quote

#!/usr/bin/python
#
# Creates a C code lookup table for doing ADC to temperature conversion
# on a microcontroller
# based on: [url]http://hydraraptor.blogspot.com/2007/10/measuring-temperature-easy-way.html[/url]
# Modified Thu 10 Feb 2011 02:02:28 PM MST jgilmore for 5D_on_arduino firmware

to:-

Quote

#!/usr/bin/python
# -*- coding: utf-8 -*-
#
# Creates a C code lookup table for doing ADC to temperature conversion
# on a microcontroller
# based on: [url]http://hydraraptor.blogspot.com/2007/10/measuring-temperature-easy-way.html[/url]
# Modified Thu 10 Feb 2011 02:02:28 PM MST jgilmore for 5D_on_arduino firmware

I don't this should break the script for other OS's so probably worth updating in repository.

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

OK

Further testing.

RepG24 and Repsnapper both do the same thing.

I have run up the machine and used both of the above host-wares.

You can flick to the manual controls in the host-ware and move the axes in a + direction. But not in a - direction.

So for example doing the following :-

Y0
Y10
Y20
Y10
Y0
Y-10

The 10, 20, 10 moves the y axis to +10, to +20 and back in a - direction to +10.

So far so good.

Y-10 should continue to move the axis in a - direction to -10 but the firmware does nothing. The instruction is issued I can see it in the sent commands window. RepG updates the count in the display. But the head does'nt move at all.

If we change about and keep on clicking for a move in the + direction movement resumes when the count again becomes positive.

If my understanding then is correct (happy to be wrong as ever) as there are no end stops, the bed cannot be homed, and if the machine is powered on with the head anywhere but home you cannot move it backwards to home using the manual controls in RepG24 or Repsnapper.

Am I correct in this or have I missed something blindingly obvious somewhere. ????

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

weird, don't have this problem myself. are you using relative or absolute positioning?
i can't remember sending neg. numbers currently.

I am currently using whatever repsnapper and Repg24 comes out of the box with.

I guess I could drag the axes to home by hand before powering up the machine bit it is'nt very good for the electronics.

Will have to have a rummage around in the apps and see if there is something I can set to make it all match up.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

aka47: I'm pretty sure that you have soft endstops enabled in config.h for Teacup. I absolutely hate them for X and Y, but on the Z axis it's extremely valuable. I'm not the first person who's ever sent a file to a printer that starts a few mm below zero. With the Z soft endstop enabled, by zeroing the machine at the bed surface every time before a print, you can practically eliminate Z crashes assuming you don't lose steps.

yep that's soft endstops at work. Set your position using G92 to some non-zero value and see if you can move the head back to where you want it. Comment X_MIN,Y_MIN,X_MAX etc if you want to disable them.

---

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

Cool that explains that one then, thanks guys.

TBH I can see the sense in not going backwards further than Zero. So if they are set up correctly they would definitely be a very good asset.

Just wish I had a homing that would set it op each time the machine was powered on. XY & Z all to the Hard Min stops.

(without getting into the debate of endstops validity whilst printing) Having them auto initialize from a seek home operation after power up has gotta be good. I guess I ca understand why someone who hasn't yet fitted them though might want that behavior to be optional though.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

add a call to home() in mendel.c main() after init and before the main loop if you want that

---

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

hey, some success. got my test cube to print with teacup. now to work on tweaking the settings. anyone have suggestions as to the bulging in the corners? i'm thinking that i'm squishing the layers a bit. anyways, asked infrastructure if they had any scanners or old hardware laying around today. scored a 5k scanner from scitex. the idiots were throwing it in the dumpster cuz it was over 3 years old...

The cube looks cool.

Having had a look at the picture, I am not sure what the problem is.

Given the fact that you have said you are extruding over temperature there is perhaps a possibility that there is too much heat left in the plastic and it is rubbery enough for the infill (which is sparse) to pull them in as it cools quicker.

Maybe worth a shot dropping your extrude temperature to something that other folks get success with.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Something that is becoming apparent.

There are a lot of settings that need tweaking in the source, recompiling and reprogramming each time I need to adjust operating parameters (rather tedious and needs a working tool chain).

Given that these devices have a bunch of eeprom that we are not realy using that much.

It kind of makes sense to transfer any of these parameters (steps per mm for example, thermistor tables and so on) into eeprom.

This has two advantages.

1. It frees up program memory on those devices that are tight.
2. It gives us the option of changing these values on the fly perhaps by adding commands that let us change these parameters via G-code (actually some other letter code but following similar standards).

Sure these parameters need some sort of default value which will always be set in the source code. When it comes to commissioning and testing a particular build though there would be less dependence on the toolchain. Not to mention much quicker turn around.

I guess it also takes the firmware closer towards being able to offer pre compiled images for classes of machine/processor that can still be adjusted to work with the fact that no two machines are alike.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

.. should be even easier with a configuration file on a SD-card, that will be read after power on or reset ...

---

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]