Project: Teacup Firmware

Ok thanks here is the GCode & config.h.

This gcode has been generated with Skeinforge40, config.h and steps_per_mm_E adapted for SF40. Problem occured also with SF39.

Edit: Added SF40 info

Edited 1 time(s). Last edit at 06/11/2011 09:31AM by cloudmaker.

That sounds like a good compromise.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

what happens if you strip the comments out before printing?

---

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

I'll try that immediatly.

Took some time to manually remove all the comments...

With No Accelertation at all defined, this didn't fix it, error occurs first at around level z=16.73, and then +-every second level, but allways at different places, extruder stops for +- 12mm and then starts again.

I'll now try with acceleraiton set to reprap style again and report back.

Ok, I think I found the problem...

I restarted printing with acceleration_reprap, the problem occurs around z=5mm.

I have the intuition that it might be a temperature problem, burn my finger while testing this on the polulu driver, I start blowing on to the pololu, the intermittent extruder problem stops...

So, looks like a hardware temperature problem, will do some further testing and report back if I can confirm that.

But big thanks for your quick help anyway!!!

Something I just noticed rummaging through G-code defs etc.

Makerbot and Repg is using M109 for the bed temp not the extruder temp.

M109 P1 Snnn.n should be equivalent.

Something to watch out for I guess. As anything generating G-code may well be using the Makerbot numbering, particularly Repg.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

cloudmaker Wrote:
-------------------------------------------------------
> Ok, I think I found the problem...
>
> I restarted printing with acceleration_reprap, the
> problem occurs around z=5mm.
>
> I have the intuition that it might be a
> temperature problem, burn my finger while testing
> this on the polulu driver, I start blowing on to
> the pololu, the intermittent extruder problem
> stops...
>
> So, looks like a hardware temperature problem,
> will do some further testing and report back if I

Ooof! Do you have heat sinks on your pololu's ?
> can confirm that.
>
> But big thanks for your quick help anyway!!!

@ cloudmaker

Is it possible that your Pololu driver is going into thermal shut down?

EDIT you came to the same conclusion while I was typing.

Edited 1 time(s). Last edit at 06/11/2011 01:36PM by Sublime.

---

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

Guys

Just spotted something odd with the Master branch.

The delay doesn't look to be working very well (G4) and my Z axis isn't updating it's position.

I have been messing with building a simple initialization block of G-code. Something I could cat onto the front of G-code objects to be printed.

As it wasn't operating how I felt the G-code should operate I sprinkled in some G-code statements that returned temperatures and positions that the firmware though it was at.

The odd thing is that after instructing a move to X10.0 Y10.0 Z60.0, the move happened in an ever decelerating sort of way. And no way was the Z axis displaced to 60mm

So I changed it to X10.0 Y10.0 and Z 20.0 and put a G-code position query before and after the command.

X and Y had gone from 0 to 10.0 (excellent) Z had gone from 0.0 to 0.0 whilst the axis had actually moved the required 20 ish mm.

Given this and that timed pauses are not looking to take the correct times. I am beginning to wonder if something isn't screwing up the timing interrupts.

All in all, the Z axis isn't incrementing in line with the last move, the G4 delay period either flies by too short or never returns, the extruder heat-up then return, doesn't, I got fed up of the smell of burning ABS and quit the job multiple times.

The only thing I could guess at is that the interrupt nesting is screwing with the timing interrupt. The default in config.h though is to nest interrupts. (I pulled down a clean clone to be sure)

I am using a newly git cloned copy of master, Ramps config, with GTKTerm as the host software. The commands I used to test the operation I typed in one at a time by hand leaving enough pause between to be sure that whether it buffered or not it had completed. The baud rate is set to 57600 (SHould be slow enough to be sure) and xon/xoff is enabled in both GTKTerm and Teacup.

Freaky huh.

I can't look towards RepG for this. I wanted to do some experimenting with the firmware with a view to :-

A. getting an arrangement together I could print with.

B. getting together a known good test bed for the development work on Textual-Teacup, to integrate libreprap.

And look to have come up a little short.

Is this the nested interrupt thing ( I hate nested interrupts) or something else ??

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

@Triffid-Hunter , Architekt, Sublime

Reporting back... It seems that it was the Polulus indeed, I didn't have heatsinks on em... (for the simple reason that I couldn't find heatsinks).

So now I glued copper mig welding tips to the chips (I had them them laying around for nozzle design testing) and as copper is an excellent heat transporter, I figured that would be perfect. And it seems to be, until now.

And it looks cool, they stick out like 4 air inputs of a powerfull engine.

Thanks again for your feedback and help.

Quote

X and Y had gone from 0 to 10.0 (excellent) Z had gone from 0.0 to 0.0 whilst the axis had actually moved the required 20 ish mm.

How many STEPS_PER_MM have you on the Z axis? For more than 100 STEPS_PER_MM, Teacup's position report is pretty inaccurate.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Nearly 400 times the microsteps.

This is largely due to the mech being a huxley using m6 lead screws (1mm per turn) and the drive belt sprocket ratio of 8:15 ish.

I think I might reduce the microstepping for the Z axis as the number of stepps is clearly overkill. It will certainly make the numbers a bit more manageable and reduce the work the fimrware has to do.

In fact as I write about it I seem to recall we have had a conversation about this a long time back. Yup step reduction and more testing it is.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Try to get below 500 STEPS_PER_MM. The UM_PER_STEPS issue still isn't solved.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hi all, just found a bug that would cause waitfor_temp to only check every 256 seconds, just pushed a patch. Please test and let me know if it's sorted

---

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

Triffid_Hunter Wrote:
-------------------------------------------------------
> Hi all, just found a bug that would cause
> waitfor_temp to only check every 256 seconds, just
> pushed a patch. Please test and let me know if
> it's sorted

Temp achieved is reporting correctly and in a timely manner for me

Thank you!

Triffid_Hunter Wrote:
-------------------------------------------------------
> Hi all, just found a bug that would cause
> waitfor_temp to only check every 256 seconds, just
> pushed a patch. Please test and let me know if
> it's sorted

I had noticed the long heat up time but attributed it to my just recently connected heated platform.

I confirm: The patch fixed that, the printer starts printing now much earlier.

Thx & regards

OK I have reduced the uStepping and the positioning looks better.

I am still not getting the correct values back from the query commands, I think though it is related to the fact that the commands are not executing in sequence.

Even though the G-code is in the correct sequence in the file and the machine is waiting for the head to heat up. The funny thing is that both of the what temperature ? commands (one before the M109 and one after) have already executed.

If they are executing in the correct sequence it is impossible for the second get temperature command to have executed and returned a cool extruder temp as the extruder wold have heated up.

But this is what i am seeing, two sets of get temperature responses returned before the code for the M109 which is sandwiched in between them.

It looks rather like the non-buffered commands are execute immediately that they are received, even though the buffer has a stack of commands in it to work through.

The net result being that the G-code is not executing in sequence.

I guess this may contribute in some way to Host-wares struggling to understand what is happening and locking up. ie it will be waiting for responses that are not coming because they have already been done but out of sequence.

Whether buffered or not the commands should still execute in sequence or the intent of the code is lost.

What do you guys think ??

---

Necessity hopefully becomes the absentee parent of successfully invented children.

If I had to guess what was happening I would guess that :-

1. Non buffered commands are being executed immediately they are received and are never put in the buffer.

2. The buffered commands are being put int he buffer to be execute later.

3. Because of this non buffered commands are prioritized over buffered commands and execute even though there are commands already in the buffer.

This fits the behavior I am seeing from doing testing.

I guess a logic fix is :-

1. Non buffered commands are buffered, but no more commands are accepted from the host until the non buffered command has bee executed. (xon/xoff and no OK until executed.)

2. All commands are processed out of the buffer.

3. Because of this commands will always be executed in sequence, buffered commands will be stacked up to ensure speedy printing (Think G1's here) of a bunch of segments ie those that make up a circle. But non buffered comands will always block until processed and will always be processed in sequence.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I thought I had better move this part of a discussion from another thread where it was getting off topic to here where it is on topic.

--- snip ---

consider:-

M105
M109 P0 S225
M105

This should in sequence do :-

M105 get the current temperature of the extruder (ambient if from cold)
M109 P0 S225 Heat the extruder up to 225 Deg C and return when at temp.
M105 get the current temperature of the extruder (now reading 225 Degrees C)

What we do get instead is:-

M105 get the current temperature of the extruder (ambient if from cold)
M105 get the current temperature of the extruder (Still same as above)
M109 P0 S225 Heat the extruder up to 225 Deg C and return when at temp.

If we have a bunch of buffered moves going off as well the returns are peppered with random OK's sometimes in the middle of a return string that I am waiting for.

Things like the temperature report, like the position report etc.

If I am a piece of host-ware and I issue a command to tell me where the tool is at ie position request, I should be able to listen for the reply. If that reply is returned to me embedded in and occasionally shot through with OK's I will have difficulty recognizing it.

As a piece of host-ware I now don't know what to do and lock up awaiting a response that will not come because it already came in an unrecognizable format.

This is exactly what is happening.

When I write C code I know what order or Sequence the instructions will execute in. A run through with a debugger confirms this.

In this case the G-code (whilst being predictable if you know what is going off) appears to have an arbitrary execution and response order.

C code that picks which instructions to execute and self rearranges the order is completely useless.

In this case though the G- code appears to work as the sending tools don't care what order responses come back and are completely blind as to whether the responses make sense.

Host-wares though are trying to be a lot more clever and the randomly unintelligible responses gum them up. When it happens depends on the G-code sequence and speed of response etc. so looks random.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

didn't see this until too late, my reply is in the other thread here :/

---

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

As per your other reply.

My code is your code. This is a clean clone of the current master with only makefile, config.h and the thermistor tables edited.

The host is GTKterm with xon/xoff enabled.

I could accept perhaps that some of the apparent random ok thing is the streams being mixed together poorly by gtkterm. I will have another testing session in a day or two, when I get time, with the local echo turned off.

It still doesn't explain the :-

M105 get the current temperature of the extruder (ambient if from cold)
M109 P0 S225 Heat the extruder up to 225 Deg C and return when at temp.
M105 get the current temperature of the extruder (now reading 225 Degrees C)

Returning two consecutive low temperatures before the M109 has completed.

It should be

Low temp
M109 completes
Temp set by M109

But it is'nt.

Sorry if this doesn't meet expectations, I test and report what I see, There is nothing in it for me either way other than hoping to eventually have a version of teacup that will print from my machine.

I will double check the position reporting later on as well, I am still not convinced that the Z is reporting correctly although after reducing the step/mm below 500 it does now move what looks to be the correct distance.

There are definitely some inconsistencies in the current master branch. As to whether they have been there all along I can't comment as I have yet to achieve a successful print with Teacup.

Even using GTKTerm.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I just downloaded the latest commit from master to test my recently completed heated bed.
After a reboot the extruder heater works fine. After I send m104 p1 s100 both thermistors begin to read the extruder thermistor and both m104 and m104 p1 begin to turn on and off the bed heater only. A lot changed in config.h since the commit I was using. Could I have mis configured something?

Also, an observation. In the Makefile I needed to set PROGID = stk500v1 to program. Avrdude complained about not being able to find the programmer with both PROGID = arduino and PROGID commented out.

Finally, is it possible to set BANG_BANG_ON and BANG_BANG_OFF independently for different heaters.

spaztik Wrote:
-------------------------------------------------------
> I just downloaded the latest commit from master to
> test my recently completed heated bed.
> After a reboot the extruder heater works fine.
> After I send m104 p1 s100 both thermistors begin
> to read the extruder thermistor and both m104 and
> m104 p1 begin to turn on and off the bed heater
> only. A lot changed in config.h since the commit I
> was using. Could I have mis configured something?

I notice that you have THERMISTOR_EXTRUDER and THERMISTOR_BED in DEFINE_TEMP_SENSOR's additional field. Does your ThermistorTable.h have two tables in it?

Apart from that your thermistor and heater definitions look fine, and I don't think the above would cause them to parallel.

Does specifying M104 P0 sort things out for you?

> Also, an observation. In the Makefile I needed to
> set PROGID = stk500v1 to program. Avrdude
> complained about not being able to find the
> programmer with both PROGID = arduino and PROGID
> commented out.

Interestingly, avrdude won't talk to my boards unless PROGID=arduino. the stk500 protocols get the device ID in a way that optiboot doesn't support.

> Finally, is it possible to set BANG_BANG_ON and
> BANG_BANG_OFF independently for different heaters.

Not yet, but that's a good idea. When I have my machine working I promise I'll be doing more work on this firmware, and it's not far now

---

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

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

> I notice that you have THERMISTOR_EXTRUDER and
> THERMISTOR_BED in DEFINE_TEMP_SENSOR's additional
> field. Does your ThermistorTable.h have two tables
> in it?
No, this was my final attempt at trouble shooting (read shot in the dark). I forgot to change it back. It fails to compile like this. The trouble I described is from before I changed it.

> Does specifying M104 P0 sort things out for you?
Not sure, I'll try.

> > Finally, is it possible to set BANG_BANG_ON and
> > BANG_BANG_OFF independently for different
> heaters.
>
> Not yet, but that's a good idea.
I'm not even certain that bang_bang will work with my heaters yet. I do know they have opposite characteristics though. I probably should use PID but I don't have the best luck tuning it. Just a thought I had about auto tuning the PID. Could a script running on the host do the work of auto tuning the PID using m104 and m105? I don't know if resources are an issue or not (I suspect it would be nontrivial to code as well) I am just thinking out loud.


> When I have my machine working ... it's not far now
That's great to hear. I've had it in my head for a while now that when/if I manage to print 2 copies of a prusa mendel I'd like to offer to print and send you any (up to and including all RP prusa) parts you might need. If progress on your wooden mendel is coming along nicely, that's even cooler. Regardless, the offer stands if required.

As always, thanks for all your effort. I hope you'll be printing soon.

Ok

Further testing of the current master branch. Something is definitely fubar. I updated my local copy of master and recompiled just before taking the screen shots (GTKTerm does'nt script or cut/paste)

See the attached files.

cal.gcode has a bunch of reporting added to it so as to show up the issues.

Basically it homes the machine, moves the head in and up a bit, heats the extruder, then is supposed to extrude a little.

All in all very simple.

From the screen shot it is clear that the code appears to be executing out of sequence, the position reports either side of the move show the same 0.0 values (One should show the position post move).

From the Extruder heat-up, the temperature reports are both showing the temp pre heat-up when one instruction is clearly post heat-up (and wait) instruction.

The heat-up and wait command isn't returning, I gave up waiting.

But has reported a post heat temp that is the same as the pre heat-up temp.

The extruder hasn't run and it hasn't reported a final position, the machine gives every appearance of either being hung or waiting to come up to temp , although measuring the print head externally shows it is steadily at temp.

Is there a branch of Teacup that we are sure actually works ?? I would like to compare it with the results attached.


Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

This is the last commit that worked for me flawlessly. [github.com] I haven't tried the latest because I was busy printing and now I am out of filament.

---

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

the log shows the temperature at just 87.5 degrees. if that's what teacup thinks the temperature is, it will certainly be waiting for things to heat up. The provided thermistor table works with reprap's most common type of 100k thermistors, is yours a different type? If you keep sending M105, does teacup report a temperature that's +/-10 of your target 235?

Have you pasted a thermistor table from another firmware? Teacup uses 14.2 fixed point for temperatures internally, so all the temperatures in the table must be multiplied by 4 compared to other firmwares.

The queueing is behaving exactly as intended- M114, M105 etc ask what's happening now, but M109, M101, G1 etc get queued. You may be able to achieve the queueing behaviour you want by setting MOVEBUFFER_SIZE to 2 (or maybe 1), which will effectively disable the queue as ringbuffers can't sensibly manage a queue with only 2 slots and think it's full when only one of the slots is used.

---

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

> the log shows the temperature at just 87.5
> degrees. if that's what teacup thinks the
> temperature is, it will certainly be waiting for
> things to heat up. The provided thermistor table
> works with reprap's most common type of 100k
> thermistors, is yours a different type? If you
> keep sending M105, does teacup report a
> temperature that's +/-10 of your target 235?
>
> Have you pasted a thermistor table from another
> firmware? Teacup uses 14.2 fixed point for
> temperatures internally, so all the temperatures
> in the table must be multiplied by 4 compared to
> other firmwares.

The temp was at 87.5 purely because the hot end had not completely cooled from the last test run. The pertinent feature is that the temperature is the same for both attempts to get the temperature. Given that they are either side of a heat-up and return when done command that has'nt completed. This is a very clear indication that the G-Codes are not executing in sequence.

The temps and heater operation etc are fine, I have hand calibrated these and they are verified against the temperature measuring equip I used to do it.

The issue with the heating etc is that if anything it is not returning from the M109.


> The queueing is behaving exactly as intended-
> M114, M105 etc ask what's happening now, but M109,
> M101, G1 etc get queued. You may be able to
> achieve the queueing behaviour you want by setting
> MOVEBUFFER_SIZE to 2 (or maybe 1), which will
> effectively disable the queue as ringbuffers can't
> sensibly manage a queue with only 2 slots and
> think it's full when only one of the slots is
> used.

So we are agreed that the G-codes are executing out of sequence.

There is then the question of how it is intended to work.

I guess if you want Teacup to work in this way then fine.

In reality though it is certainly not how G-Code is intended to function.

Arbitarily changing the sequence of execution changes the behavior of the machinery in a non deterministic way. If we were just doing something that was'nt physicaly dependant on that sequence it might not matter. In reality we are and it does.

G-Code has a lot more to it than we have implemented so far. There is a very strong argument to develop our G-Code implementation further adding in such functionality as Arc's, Goto's, Inclusion, Looping etc.

The stuff that is defined in the standard.

The arguments for gradually adding this function are compelling.

If your code is executing out of sequence and you loop to or goto a line of code it is highly possible that it will behave differently to the first time through if your codes are executing out of sequence.

If the C-Code that Teacup is written in didn't execute in a deterministic manner all attempts to get a working firmware would be undermined.

Similarly as the G-Code that the objects are written is is non deterministic attempts to work with machinery at a behavioral level (as opposed to byte streaming) are similarly undermined.

I am struggling at the moment to understand why G-code in this implementation should be exempt form the rigours of Sequence, Selection and Iteration that characterizes all other programing languages. Self modifying code is a complete no no.

We are after all programing the actions of a physical machine through G-Code.


On buffering......

There should be no need to reduce buffering to get correct sequencing. In fact the buffering is great and neccesary consider:-

As we are unable to use the Arc and curve commands of G-Code we are constructing curves and circles at the CAM stage as sequences of short straight lines. These are quite rightly being bufferd to print as a whole artifact ina sensible amount of time.

To get necessary buffering and correct sequence it should be enough on receipt of an immediate instruction to halt download. Process what ever is in the buffer and then do the immediate (without buffering it) On execution of the imediate.

I guess there is a question as to whether all non buffered commands have the same need for immediacy.

Personally I think that most non-buffered commands are actually not immediate at all (is the world going to end if I empty the buffer before reporting how hot the hot end is), they are though a stop or check-point in the execution stream.

The delay or pause command is a very good case in point.

If you are not able to check the status of your machinery at precise points in the execution stream (because they are not executing in sequence) you are unable to verify that the process is as it should be, when it should be, as you have no control at all as to when "when" actually is.

An example of an immediate command that is exactly that, is E-Stop.


In summary, G-Code is a machine programing language, it programs the actions of a controlled piece of machinery in a deterministic manner. Such that the machinery can be made to exhibit precisely defined behaviors under direct control from a controlling host. (If the host has no idea what behavior the machinery is exhibiting because the codes are executing out of sequence, the control is clearly then less than precise and defined)

Some commands can and are best buffered, some commands can not be buffered, and some commands (A very very tiny set) must execute immediately they are received.

The current behaviour of teacup is to treat all non-bufferable commands as immediate, even if this changes the execution order of the commands.

In and of itself, this approach I feel is flawed.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I understand where you're coming from.

That's simple to implement in teacup, simply stick a queue_wait(); at the top of each unbuffered command in gcode_process.c

This may be useful for SD prints but I wouldn't use it when running interactive prints where hostware is involved

Add #define ENFORCE_ORDER to your config and try the attached patch (against current master) and see if you get what you're expecting

---

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