giving this a little thought. it would be nice to have for testing. I could interface directly with the values using my LCD/joystick input. interesting....
I first thought hey, I haven't actually messed with my config in awhile so once its set, its set. trying to think of a time when i would need to modify the config and can't other then adding new hardware like a heated platform or something.
but even so are you thinking something like ecodes or another [alpha]code commands to change them?

I think you might be right about the to hot thing. I'm running abs at 245 for that first test. think I'm also squishing .45mm to .25 layer height. thought i had read somewhere that's a good starting value for the height. but looking at the output it is much more condensed then some of the parts I have from others.

Yup sd card would be good.

I think there is a question to be asked of SD card.

Do we actually want it on the machines main control board or on a HID board like architects.

To put it on the machines main board with the teacup firmware means shoe horning it into the firmware. Not only in terms of space but also processing cycles. Given the real time control nature of the firmware there is perhaps an argument for not doing it.

An SD card realy needs in addition some way to call up the stored stuff and to print some or all of it. This feels to sit better logically with a control panel rather than the machines main board.

I guess if going the direction of sd card, & control panel the control panel processor is likely to spend a lot of time doing very little. Perhaps a good candidate then to add An Ethernet interface to. something like the microchip one chip wonder ether net controller with SPI interface.

Going this route arguably makes it a separate project though....

Just musings.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

More testing done.

The juddering and not extruding extruder problem.

I have gone over the pinouts and processor settings these are all good.

My board is a RAMPS 1.1c and the pinout on the diagram matches the choices in the config.ramps.h

Having dismantled the machine and checked joints and reflowed them all it is still the same.

I hooked up a logic probe and monitored the direction pin. Immediately after reset this is pulled low.

Selecting stepper forwards from RepG the Direction pin goes high, if I reverse the direction from RepG after a while the dir pin does not change (it should if the stepper is to go the other way)

If I reset everything and set off in the reverse direction the same signals are observed.....

The logic probe shows high low and floating. this pin has never shown floating. so it is being driven just incorrectly.

E0_Dir is diagrammed and configured as D34.

Anyone any ideas ??

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Heres a g-code excerpt

Quote


Extruder stepper direction forwards speed 1rpm

[14:38:18
sending: N149 T0 G1 F1 *23
[14:38:18] sending: N150 T0 G1 E0.078349 F1 *101

[14:38:20] sending: N152 T0 G1 F1 *29
[14:38:20] sending: N153 T0 G1 E0.080016 F1 *104

[14:38:22] sending: N155 T0 G1 F1 *26
[14:38:22] sending: N156 T0 G1 E0.081683 F1 *102


Stepper direction reversed.


[14:38:31] sending: N165 T0 G1 F1 *25
[14:38:31] sending: N166 T0 G1 E0.080016 F1 *110

[14:38:32] sending: N168 T0 G1 F1 *20
[14:38:32] sending: N169 T0 G1 E0.078349 F1 *111

[14:38:32] sending: N171 T0 G1 F1 *28
[14:38:32] sending: N172 T0 G1 E0.076682 F1 *105

]

---

Necessity hopefully becomes the absentee parent of successfully invented children.

F1?? that would most certainly not work on my setup. anything less the F40 seems to kill the steppers. that looks really odd to me.
I'll have to check that on my setup tonight. I also don't send the T0 commands so not sure about that.

Edited 2 time(s). Last edit at 03/31/2011 10:55AM by Architect.

I get similar with the speed set to 10 rpm which gives F10

Although I need to correct something I said before.

If I reset the machine and start in reverse direction the dir line is pulled low but doesn't go high when the direction is reversed.

It looks a bit like the firmware hasn't detected that the direction of motion is reversing for the Extruder.

I am not sure what the T0 is. Or if it is needed.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

T0 I believe is tool/extruder selection. some people out there have multiple extruders on there print head.
interesting concept..

Yup it is useful for breakaway support in a separate material.

Or different colours.

I realised I hadn't tried repsnapper with the extruder problem. Just the soft zero axes problem.

repsnapper drives it ok.

So the problem looks to be a mismatch in the code that RepG24 is sending and what the teacup firmware will cope with.

I think Repsnappers generated gcode is 3D, but as teacup was originaly 5D on Arduino I might expect it to support 5D code.

I wonder which part it is falling over.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

@AK47 have a look GRBL it allows you to change your steps per mm/inch, max speed, acceleration, arc segment size and more from the serial terminal and it is based on the original reprap G code interpreter. So it should not be to hard to take their example and implement it in Teacup. It currently supports all standard Gcodes for milling, It supports arcs and has acceleration while still fitting on a 328 and will fit on a 168 without arcs or with arcs but no acceleration. Have a look here [dank.bengler.no]

i don't know, I think you might be over looking something here. what is creating your gCode? from skienforge ala ReplicatorG my gCode looks something like repsnapper looks very similar as well.

G1 F400
g1 Z.04
G1 F2000
G1 x10.0 y10.0 E.05
G1 x10.0 Y20.0 E.05
G1 X0.0 Y20.0 E.05
G1 X10.0 Y10.0 E.05
G1 F400
G1 Z.08

This is off the top of my head here at work. I believe teacup uses the speed i.e F values and figures out how many steps for everything from there. if F doesn't change it uses the last know values. it also throws in ramping up to speed and down depending on what your config wants it to do. I don't think F is RPM. I could be wrong...

I haven't got to slicing etc yet.

That is another can o worms.

Been working through a step at a time at the moment. Logical problem solving. Start form a known position and add things till something breaks. work out what it is, fix or work around, move forwards. Repeat until machine works and prints.

Just been doing manual control. I would guess the G-codes for manual control are hard coded in the driver for RepG24.

The solution for Teacup and RepG could perhaps be a dedicated Teacup driver.

Thanks for the pointer Sublime. I am sticking with Teacup for now. If no one tests a feeds back it never gets to the next level. I will have a look though when I get my machine printing acceptably.

I think all the Host and Firmwares would benefit from having a G-Code test suite that they all work with/produce. It would create a consistent standard method and improve interoperability.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

@AK47 It should be possible to craft a special config.h where the defines are actual variables/functions to get the config from sd/eeptom/startup/whatever. I haven't thought it to the end but I don't see a major problem. Performance would get worse, as some math currently done at compile time, would have to be done at runtime. But I think it won't be noticeable.

@Sublime GRBL looks good. I like the motion planner it has.

I am not suggesting to use GRBL for reprap as it has been redesigned for milling in mind and has dropped all the extruder/heater code while adding lots of milling options, but rather that it could be used an example of how to implement the adjustable settings via serial command line. And as Markus pointed out it does implement a 20code read ahead which could be useful as well. I am playing with it for a Milling machine and Teacup on my Printer.

Edited 1 time(s). Last edit at 04/01/2011 01:35AM by Sublime.

Ahhhhhh I see.

Sorry, (Looks a bit dim).

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Getting the steps/mm values from eeprom wouldn't be a huge performance hit. The DDA queue stuff is all in steps at this point anyway, so the conversion wouldn't be done at interrupt time.

It would take a bit more code space, and some RAM to hold the variables. From what I understand, reading from EEPROM takes quite awhile. Maybe that was just flash though. Hrm.. Datasheet says 3.3ms typical write time, per byte. Read time I can't find, though it does note that the CPU is halted for 4 clock cycles after a read instruction before the next instruction is executed. (ATMEGA168 data sheet, section 7.4.1, "EEPROM read/write Access", pg 19)Maybe that's all the time it takes to read from eeprom? If so, read times aren't significant and we could maybe just read directly from eeprom when multiplying to get steps?

---

--
I'm building it with Baling Wire

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

One step ahead, check out eeconfig branch, help me get it ready for master

---

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

aka47 Wrote:
-------------------------------------------------------
> Heres a g-code excerpt
>
> sending: N149 T0 G1 F1 *23
> [14:38:18] sending: N150 T0 G1 E0.078349 F1 *101
>
> [14:38:20] sending: N152 T0 G1 F1 *29
> [14:38:20] sending: N153 T0 G1 E0.080016 F1 *104
>
> [14:38:22] sending: N155 T0 G1 F1 *26
> [14:38:22] sending: N156 T0 G1 E0.081683 F1 *102
>
>
> Stepper direction reversed.
>
>
> [14:38:31] sending: N165 T0 G1 F1 *25
> [14:38:31] sending: N166 T0 G1 E0.080016 F1 *110
>
> [14:38:32] sending: N168 T0 G1 F1 *20
> [14:38:32] sending: N169 T0 G1 E0.078349 F1 *111
>
> [14:38:32] sending: N171 T0 G1 F1 *28
> [14:38:32] sending: N172 T0 G1 E0.076682 F1 *105
>
> ]


I see the problem, teacup currently expects /every/ E-word to be relative, whereas recent changes in slicers have switched to absolute E with a reset to zero after every layer. A trivial change to make, but one I haven't done yet. Please wrap it in an ifdef if you send me a patch, so those used to the old behavior can keep it

---

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

Absolute E paths have the benefit of being more accurate. If you have many short moves, with E advancing only a few steps per move, the error becomes noticeable.

Did you miss the recent patches or are they so awfull its not worth commenting

Markus Amsler Wrote:
-------------------------------------------------------
> Did you miss the recent patches or are they so
> awfull its not worth commenting

Sorry, checking them out is on the top of my todo list, currently trying to sort out accommodation so time available for teacup is sporadic at best. The bit of stuff I've committed since you posted them is stuff I've been waiting for the time to get out of my head for a while.

---

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

After 48 days, I finally got my reprap printing with teacup (from the Arduino IDE and Windows, no less) Thanks for all the help!

~Andrew

Andrew Diehl Wrote:
-------------------------------------------------------
> After 48 days, I finally got my reprap printing
> with teacup (from the Arduino IDE and Windows, no
> less) Thanks for all the help!

Excellent!

perhaps we should start a page on the wiki discussing how to get printing with teacup? It seems to me that most of the issues come from confusion over configuration settings and host <-> firmware communication - we should start documenting how we solve these in a more accessable format than a colossal forum thread

---

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

Triffid_Hunter Wrote:

> perhaps we should start a page on the wiki
> discussing how to get printing with teacup? It
> seems to me that most of the issues come from
> confusion over configuration settings and host <->
> firmware communication - we should start
> documenting how we solve these in a more
> accessible format than a colossal forum thread

Does this mean its ready for release status?

Quote

Did you miss the recent patches or are they so awfull its not worth commenting

In my queue, too

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Sublime Wrote:
-------------------------------------------------------
> Does this mean its ready for release status?

I think I'll start talking about a release when teacup works out of the box for most people, despite electronics, machines, host software etc, and we have all the features we want and have polished up most of them so they're good code rather than something someone cooked up at 3am (or at least behave as such!)

When we do get to release, I'll be leaving master branch as the release branch and moving development to another branch, backporting bugfixes as necessary until we make a new release from the devel branch

Traumflug Wrote:
-------------------------------------------------------
> In my queue, too

care to push if your eyeballs and machine like them? I'm not gonna have time to check them out in the next couple of days, just time to post occasionally from my phone

---

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

I have a problem configuring my heaters in the latest src from git.
I know it is simplified. I have this in config.h

#ifndef DEFINE_HEATER
	#define DEFINE_HEATER(...)
#endif

//               name      port   pin    pwm
DEFINE_HEATER(extruder, DIO0)
DEFINE_HEATER(bed, DIO1)
// DEFINE_HEATER(fan,			PORTB, PINB4, OCR0
// DEFINE_HEATER(chamber,	PORTD, PIND7, OCR2A)
// DEFINE_HEATER(motor,		PORTD, PIND6, OCR2

/// and now because the c preprocessor isn't as smart as it could be,
/// uncomment the ones you've listed above and comment the rest.
/// NOTE: these are used to enable various capability-specific chunks of code, you do NOT need to create new entries unless you are adding new capabilities elsewhere in the code!
/// so if you list a bed above, uncomment HEATER_BED, but if you list a chamber you do NOT need to create HEATED_CHAMBER
/// I have searched high and low for a way to make the preprocessor do this for us, but so far I have not found a way.

#define	HEATER_EXTRUDER HEATER_extruder
#define HEATER_BED HEATER_bed
// #define HEATER_FAN HEATER_fan

When i try to compile this i get the following error:

In file included from heater.c:34:
config.h:297: error: lvalue required as unary '&' operand
config.h:298: error: lvalue required as unary '&' operand

If i change the pins to DIO3 & DIO4 then it compiles fine, so it seems that the new way of defining a heater only works for pins that support PWM.

kuhlivisj Wrote:
-------------------------------------------------------
> config.h:297: error: lvalue required as unary '&'
> operand

thanks, should be fixed now. That's my bad for not testing enough.


Markus Amsler Wrote:
-------------------------------------------------------
> Here are some patches, this time cleaned up

I finally got around to checking these out, they look great! Thanks! I can give you direct commit access if you promise to be at least as careful as I am with the tree (which isn't exactly a high bar I know) - just need a git account and pm me your username

---

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

I was playing around with gcode extruder retraction and got some firmware lookups as results. The Problem was/is that for step pulse rates above around 30kHz the step interrupt interrupts itself if STEP_INTERRUPT_INTERRUPTIBLE is set. if STEP_INTERRUPT_INTERRUPTIBLE is not set I get lost serial chars.

Now what should the firmware do if we get close to the step rate maximum, and how do we detect it? A fixed value is difficult as it depends on the acceleration config, and on the other interrupts interrupting the step interrupt.

30 k steps per second. What's that in real terms....

Lets see

If we have an 80 step motor that we are micro-stepping at 16 micro-steps per step then we get:-

1280 steps per revolution.

at 30,000 steps per second this is 23.4375 revolutions per second. (1406 RPM)

If we multiply the circumference of the driven sprocket (on a belt machine) by this figure we can see what speed the axis should be flying along at.

(conversely if we divide the circumference of the driven sprocket by this figure we can see what resolution we are getting per micro step on that axis)

I am not sure if my machines belt driven axes will take that sort of speed/acceleration.

Thinking though of my Z axis which uses M6 lead screws (1 revolution gives a displacement of 1mm) then my axis would be running at 23.4375mm/second.

So arguably doable on my Z axis which is an M6 lead screw although could be a little faster than needed when printing on an axis that actually only takes moves once a layer.

However I actually only micro-step at 8 (Half the steps double the speed). Because I know that 16 is arguably overkill and a little pointless.

There is also an argument that on my Z axis I perhaps don't need much in the way of micro-stepping at all as one 80th of a millimeter is plenty of resolution. We only actually need one 10th of a millimeter. So without micro-stepping at all my Z axis has about 8 times more resolution than I actually really need.

Overall then I am pretty much of the opinion that if the mechanics are right and sensible then 30k steps at the micro-controller step pin should be plenty enough.

There is going to be a limit on the speed that the micro-controller can run at which will be a function of loop/routine times and xtal frequency. There are finite limits. A faster xtal would give you more speed, but throw out any timings based on a fixed (not scaled to F_CPU) number of instruction times and or clock cycles.

If you are struggling for machine speed at 30k steps at the micro-controller step pin it is perhaps time to revisit your design decisions around the mechanical bits and think about reducing your degree of micro-stepping.

When you suggest around are we talking at less than 30k or greater than 30k ??

Having said all of the above it is good to know where the limit is. There is always going to be one.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

@aka47
Where did you get an 80 step motor?
A 7.5degree stepper has 48 steps per rev. and a 1.8degree stepper has 200 steps per rev..