Welcome! Log In Create A New Profile

Advanced

Project: Teacup Firmware

Posted by Triffid_Hunter 
Re: prints interrupted
June 05, 2011 05:45AM
hariseldon78 Wrote:
-------------------------------------------------------
> you are right it's something other. i edited the
> message, please look it. is it possible to talk on
> irc or google chat or something?

#reprap on irc.freenode.net is very active smiling smiley


-----------------------------------------------
Wooden Mendel
Teacup Firmware
Re: prints interrupted
June 05, 2011 01:38PM
I just added active cooling and I am having a hard time reaching my target temp of 220 because of a small amount of air hitting my heater block. It hovers around 217.25, I do plan to insulate the heater block to solve the problem but wondered if there was a way to increase the output. After looking through the code I found /// default scaled I limit #define DEFAULT_I_LIMIT 384 . Is this where I would increase the default output. I also noticed that the L.E.D. attached to the heater never lights up using teacup but does using sprinter because of the teacups PID .


FFF Settings Calculator Gcode post processors Geometric Object Deposition Tool Blog
Tantillus.org Mini Printable Lathe How NOT to install a Pololu driver
Re: prints interrupted
June 05, 2011 01:51PM
Sublime Wrote:
-------------------------------------------------------
> I just added active cooling and I am having a hard
> time reaching my target temp of 220 because of a
> small amount of air hitting my heater block. It
> hovers around 217.25, I do plan to insulate the
> heater block to solve the problem but wondered if
> there was a way to increase the output. After
> looking through the code I found /// default
> scaled I limit #define DEFAULT_I_LIMIT 384 . Is
> this where I would increase the default output. I
> also noticed that the L.E.D. attached to the
> heater never lights up using teacup but does using
> sprinter because of the teacups PID .

you can change the pid factors stored in the eeprom using M130-M134, read source for details. Changing the defaults once the eeprom has a valid checksum won't alter anything. Note that the 3 factors are scaled by PID_FACTOR, but the limit isn't. I may change this in the future.

You don't want I_FACTOR * I_LIMIT to be more than about 192 I think, or your integrator can wind up too much. If you need the pid output to go above 192 to reach steady state, you can go beyond that, just try to keep the product as low as possible, while exploring settings that work.

It is indeed the integrator that homes in on the target temperature when steady state has been achieved by the other two factors smiling smiley


-----------------------------------------------
Wooden Mendel
Teacup Firmware
print interrupted - SOLVED - and presentation of my fork
June 06, 2011 11:06AM
ok, i finally kind of understand my problem: the interrupted prints are not due to the firmware but to something in serial communication between replicatorg and the board. If i use replicatorg as interface to skeinforge and then send the gcode from gtkterm all goes well, and i've been able to complete a bunch of ugly looking but strong objects with this procedure smiling smiley

So up and printing, i'm very happy. Now, in the process of debugging and troubleshooting i made a number of features in my firmware, and decided to publish them for other people who find them useful. Here is the github address:

https://github.com/hariseldon78/Teacup_gen3_customized

Here the list of features, most of them are optional (some are related to gen3, but not all of them):

- ALWAYS_CHECK_Z_MIN (still developing) Provide a way to always check the z min stopper. Useful for calibration phase where the printer can loose track of home and crash into the bed.
- MOTOR_OVER_INTERCOM Use the intercom to drive the extruder motor. This allows to remove the little cable from sda-sdl motherboard to d9-d10 pins of the extruder controller. More free pins, less cables. This works very well and i'm using it always.
- FAN_INTERCOM Allows to control a fan attached to the extruder board (wasn't able to configure it as a heater or similar..). Works perfectly.
- DEBUG MODES This allows to write little debug program which starts instead of the main loop, to allow very low level debugging while keeping all the good teacup environment like pins definitions, config options, intercom functions and so on. They are hidden inside debug.c and there is only a little #ifdef in the main function. This has been foundamental to be able to solve all my intercom and configuration problems.
- DEBUG_LED_FEATURE This activate some nice led blinking with configurable patterns during startup, pauses (G4 Pxxx), temperature waits (M109 Sxxx) and possibly other moments. Very useful and nice to see. Now your reprap can speak to you!
- ALWAYS_ON Start the atx power switch at boot and never put it in standby mode. This was foundamental for me because the standby mode turn off my extruder controller board, so intercom stops working, temperatures are lost, and all sort of bad things happens.
- REST_TIME This cause the printer to stop printing for one minute after REST_TIME seconds of printing. Activate DEBUG_LED_FEATURE to see when the machine is resting. Useful if boards or power switch are overheating. It keep track of idle time, so it only put the machine to rest while it is effectively working. Works well and i configured 900 seconds. My power switch stopped randomly shutting down with this feature.

There are a bunch of changes to the code, not configurable from config.h. Please tell me if i got something wrong or if you feel that some of them are dangerous or something..
- i moved the temp-achieved check into the 1 second clock function. There is no need to check it more often..
- i added a boot-time second counter, with an output from the m115 command. Useful to know when your board last reboot was, maybe only for debugging purpouse
- i added an output of all the moves in the queue at the m250 command
- i added a UCSR0B=0 in the extruder main, this was necessary to make intercom working for me. Maybe this will help others gen3 guys..
- some others that i don't remember smiling smiley

All these feature are very little, from 16 bytes (fan over intercom) of compiled code to a maximum of 300 byte (motor over intercom, maybe i can make it smaller).

For the official developers team: if you feel that some of these features are good to import into the official code please tell me so i can clean up them where needed and produce patches against the official branch. I don't think a git-pull would produce good results at the actual state..

So, please anybody curious have a look at it, and leave me comments or critics!

Edited 2 time(s). Last edit at 06/06/2011 11:14AM by hariseldon78.
Re: prints interrupted
June 06, 2011 07:15PM
heh again with graphical talkers being the issue...

That's a serious amount of debug code you've dropped into teacup! There's a few of your features that jump out at me as being useful:
* always check endstops- I think we've had this feature on and off, maybe setting it per axis is a good idea
* fan over intercom- is this just an extension of the GPIO features of the intercom protocol? setting DEFINE_HEATER(HEATER_fan, EXTRUDER_GPIO_3) or similar with EXTRUDER_GPIO_3_PORT=&intercom_packet.dio and EXTRUDER_GPIO_3_PIN = 3 should basically do it, if dio3 is the right pin for the fan.
* boot clock, for checking uptime as you say. I think we had one a while back, seems to have vanished at some point.

And a few comments on some of your features:
* motor_over_intercom- this will savagely limit your print quality with the current intercom code, especially at higher speeds. the axes need to remain tightly synchronised during a move, and the current intercom code introduces a delay up to 250ms or so. Ideally, the E axis should lead the others, and certainly should never ever trail them.
* always_on - I had similar issues with the idle timer, so I created a patch that makes the idle timeout optional, allowing me to control the power by M190 and M191 manually. git cherry-pick 2e7a756f13 if you're interested.


Thanks for posting your changes! Even though they mostly don't belong in the main repository, I will be pointing people here for help debugging their electronics smiling smiley

I'll have a proper look through your repository in a bit


-----------------------------------------------
Wooden Mendel
Teacup Firmware
Re: prints interrupted
June 07, 2011 05:56AM
Triffid_Hunter Wrote:
-------------------------------------------------------
> * fan over intercom- is this just an extension of
> the GPIO features of the intercom protocol?

Surely not, i don't even know what you are talking about smiling smiley
I just made the motherboard send the m106 command to the other side and the extruder board catch it and turn on the fan. same for m107..

> setting DEFINE_HEATER(HEATER_fan, EXTRUDER_GPIO_3)

I'll give it a try. Surely it's not so simple to configure, and the intercom-fan takes just 16 bytes on the motherboard firmware. I didn't check the size on the extruder side, but is just a couple "case" statements..

> * motor_over_intercom- this will savagely limit
> your print quality with the current intercom code,
> especially at higher speeds. the axes need to

Well, i have to make some experiments comparing the 2 features. There is a surely cap to the speed you can drive the extruder at, because the intercom transfer all the e_step() commands (the unstep is done automatically on the extruder side). i tried to insert a block in clock.c called more often than 10 ms, and do the transfer from there. Anyhow i then removed it because i needed to debug other problems and i didn't want to insert too much complexity.. I can probably retry with it.

> remain tightly synchronised during a move, and the
> current intercom code introduces a delay up to
> 250ms or so. Ideally, the E axis should lead the
> others, and certainly should never ever trail
> them.

you mean that it takes 250ms from the motherboard start_send() to the extruder switch-case? or you refer to the fact that the intercom start-send was called in the 250ms clock block?
Because in my code i send the e-step request, if needed, in the 10ms clock block, and i can try to check it more often. I also raised the intercom speed to 115200, it works well so there's no need to stay at 57600 as it was.. maybe it can be raised more?
Mostly i think this feature is useful if you want to attach some other electronics, like an lcd display. With all the multiplexing possible i don't think that we can control one with less than 3 pins, and the sanguino just had too few free pins. So i thought why not using the intercom as much as possible to free some pins? But i'm not much of an electronic guy, more a software one.. so, if someone knows how to control an lcd display with just 1 or 2 pins please give me some directions..
endstops ignored, STEPS_PER_MM_E
June 09, 2011 02:29PM
I've got a problem with my endstops, but I'm not totally sure if it is a hardware or firmware problem. I only noticed it with the X endstop so far, and I'm using micro-switches, mostly because I still had a number of them left over from another project. I already replaced the switch once, but it didn't make a difference.
When using the arduino serial console, after power up:

g161 x (home the x axis successfully, back off after triggering the switch)
g0 x20 (move away a bit)
g161 x (now it runs into the x endstop, seemingly ignoring the switch)
at that point I normally power it down
m200 (my new command to report the endstop status, it reports x_min IS triggered)

I could imagine that some configuration of the x_min input gets lost, but I've got not enough experience with the platform to debug this. Does anyone have suggestions what to look for? I did a grep on the Teacup sources, and the configuration of the input pin is only touched at startup.

And I'm a bit frustrated by the calculations required for STEPS_PER_MM_E . Information about what value is required exactly seems to be spread out over lots of blog entries and Wiki pages, and additionally the value seems to depend on the host software. Is there a definite reference what to set for which host software?
Re: endstops ignored, STEPS_PER_MM_E
June 09, 2011 08:29PM
Jens_R Wrote:
-------------------------------------------------------
> I could imagine that some configuration of the
> x_min input gets lost, but I've got not enough
> experience with the platform to debug this. Does
> anyone have suggestions what to look for? I did a
> grep on the Teacup sources, and the configuration
> of the input pin is only touched at startup.

this is a strange bug, I can think of no reason why this might occur, especially if M200 is reporting the status correctly. Check that M200 is reporting correctly before and after the first homing operation too. G161/G162 trigger the code in home.c which is very simple, perhaps add some debug stuff there.

> And I'm a bit frustrated by the calculations
> required for STEPS_PER_MM_E . Information about
> what value is required exactly seems to be spread
> out over lots of blog entries and Wiki pages, and
> additionally the value seems to depend on the host
> software. Is there a definite reference what to
> set for which host software?

for everything except SF40/41, how many steps to generate 1mm of extrudate. For SF40/41, how many steps to push 1mm of filament into the extruder. SF40/41 also requires your filament diameter (measured rather than nominal) so it can figure out what volume is being extruded. If you're measuring rather than calculating, do it for 50mm or something and divide so you get the required precision.


-----------------------------------------------
Wooden Mendel
Teacup Firmware
Re: endstops ignored, STEPS_PER_MM_E
June 10, 2011 03:52AM
Triffid_Hunter Wrote:
> this is a strange bug, I can think of no reason
> why this might occur, especially if M200 is
> reporting the status correctly. Check that M200 is
> reporting correctly before and after the first
> homing operation too. G161/G162 trigger the code
> in home.c which is very simple, perhaps add some
> debug stuff there.

It is stuck inside the home loop, so I can't run M200 without doing a reset. I can do several g161 in a row without problems, if fails only after I run a g0. What is strange is that all the endstops are on portb, which is only used by the heaters otherwise. None of the stepping or movement code should touch that port.
I added code to switch the fan on in the true branch and the fan off on the false branch, so that I can watch the LED. If the home works I can see the LED on and off when I press the endstop, and after I do a move it stays dark.
I copied the code from mendel.c into the home function that initialises the pin configuration and pull-up, and then it works even after a move. It stays working after I comment out the line setting the pin to input, but it fails if I remove the code that sets the pull-up. So something related to the movement code resets the pull-up configuration on port b.
I'm still investigating.
Can anyone else with mechanical endstops reproduce this, or is everyone else using optical endstops? (Btw, I'm on an Gen7 1.1 board, which uses pb7/dio7 for xmin.)
Interestingly, M200 reports ymin and zmin still working after a move, only xmin stays off.

In timer.c it writes to SCK a 1 and a 0. The datasheet says that is the SPI bus clock. Is that code active/required in normal builds, or if you're not using SPI devices?

Edited 3 time(s). Last edit at 06/10/2011 04:41AM by Jens_R.
Re: endstops ignored, STEPS_PER_MM_E
June 10, 2011 05:15AM
Jens_R Wrote:
-------------------------------------------------------
> It is stuck inside the home loop, so I can't run
> M200 without doing a reset. I can do several g161
> in a row without problems, if fails only after I
> run a g0. What is strange is that all the endstops
> are on portb, which is only used by the heaters
> otherwise. None of the stepping or movement code
> should touch that port.
> I added code to switch the fan on in the true
> branch and the fan off on the false branch, so
> that I can watch the LED. If the home works I can
> see the LED on and off when I press the endstop,
> and after I do a move it stays dark.
> I copied the code from mendel.c into the home
> function that initialises the pin configuration
> and pull-up, and then it works even after a move.
> It stays working after I comment out the line
> setting the pin to input, but it fails if I remove
> the code that sets the pull-up. So something
> related to the movement code resets the pull-up
> configuration on port b.
> I'm still investigating.
> Can anyone else with mechanical endstops reproduce
> this, or is everyone else using optical endstops?
> (Btw, I'm on an Gen7 1.1 board, which uses
> pb7/dio7 for xmin.)
> Interestingly, M200 reports ymin and zmin still
> working after a move, only xmin stays off.

time to post your config I think

> In timer.c it writes to SCK a 1 and a 0. The
> datasheet says that is the SPI bus clock. Is that
> code active/required in normal builds, or if
> you're not using SPI devices?

That's a debug output thing. my diecimila has the debug led connected to SCK. probably should be removed.


-----------------------------------------------
Wooden Mendel
Teacup Firmware
Re: endstops ignored, STEPS_PER_MM_E
June 10, 2011 05:27AM
Triffid_Hunter Wrote:
> > In timer.c it writes to SCK a 1 and a 0. The
> > datasheet says that is the SPI bus clock. Is
> that
> > code active/required in normal builds, or if
> > you're not using SPI devices?
>
> That's a debug output thing. my diecimila has the
> debug led connected to SCK. probably should be
> removed.

What about adding a DEBUG_LED_PIN to config.h, and test for this #define in timer.c? In case someone has the self-destruct circuit wired to SCK. smiling smiley
I removed that code and now it works fine for me.
(SCK is port b / pin 7 on the ATMEGA644 on my Gen7 board.)
For example:
diff --git a/timer.c b/timer.c
index f881ab3..e31e370 100644
--- a/timer.c
+++ b/timer.c
@@ -77,7 +77,9 @@ ISR(TIMER1_COMPA_vect) {
        // Check if this is a real step, or just a next_step_time "overflow"
        if (next_step_time < 65536) {
                // step!
-               WRITE(SCK, 1);
+               #if defined( DEBUG_LED_PIN )
+                       WRITE(DEBUG_LED_PIN, 1);
+               #endif
 
                // disable this interrupt. if we set a new timeout, it will be re-enabled when appropriate
                TIMSK1 &= ~MASK(OCIE1A);
@@ -87,7 +89,9 @@ ISR(TIMER1_COMPA_vect) {
                queue_step();
 
                // led off
-               WRITE(SCK, 0);
+               #if defined( DEBUG_LED_PIN )
+                       WRITE(DEBUG_LED_PIN, 0);
+               #endif
                
                // Enable the timer1_compa interrupt, if needed, 
                // but only do it after disabling global interrupts.

Edited 2 time(s). Last edit at 06/10/2011 05:36AM by Jens_R.
Re: Project: Teacup Firmware
June 10, 2011 05:35AM
Guys as ever great things happening here.

Just been having a play with the extract.py script. and found a couple of things.

1. The script as it comes from the repository is missing the execute permission so won't run on Linux/Unix unless this is set first. ( chmod +x extract.py ). It is probably worth considering setting the permission on the file in the repository though. Like it is for the other python scripts.

2. extract.py fails when executed with the following :-

[email protected]:~/Data/Common/development/Teacup_Firmware$ ./extract.py
./extract.py: line 8: syntax error near unexpected token `('
./extract.py: line 8: `re_comment = re.compile(r"\s*//\?\s?(.*)")'

The thing I was working towards was looking to see if Gcode commands had been implemented to manipulate the eeprom values for the PID settings??


A last question.

Running quickly through the code it looks a bit like the PID values are the same for both the Bed and Extruder heaters.

Is this actualy so or am I getting it all horribly wrong ??

The reason I ask is that the time constants and thermal characteristics of a Bed heater are very different from those for the Extruder heaters. Probably sufficiently enough to give poor control to what ever they were not optimized for.

IE, optimizing for the Extruder heater/s will leave the Bed heater with poor control. and vice versa.


I guess the bed temps being a little out is not going to affect the results too much. It does though have an impact on when you are waiting for example for both temps to come to their set points.

As the hysteresis and dwell parameters are common to both. Having one or other not settling because the PID values are optimized for the other may cause it to wait for ever.

Thoughts for what they are worth.

Cheers

AKA47


Necessity hopefully becomes the absentee parent of successfully invented children.
Re: endstops ignored, STEPS_PER_MM_E
June 10, 2011 05:35AM
So is it simply the fact you have no external pull up? If the pin is floating it can be affected by pins and tracks nearby.

You should always use an external pullup resistor as the internal ones are anything between 20 and 50K, which will be prone to noise. I use 2K2 on my endstops and even those will pick up noise when the switch is closed if the wires are bundled with the stepper wires.


[www.hydraraptor.blogspot.com]
Re: endstops ignored, STEPS_PER_MM_E
June 10, 2011 05:41AM
nophead Wrote:
-------------------------------------------------------
> So is it simply the fact you have no external pull
> up? If the pin is floating it can be affected by
> pins and tracks nearby.

No, it looks like it was related to the debug-led pin on one hardware being the port configuration for x_min on my hardware. The patch above should disable the offending code while still allowing a debug-led if required.

> You should always use an external pullup resistor
> as the internal ones are anything between 20 and
> 50K, which will be prone to noise. I use 2K2 on my
> endstops and even those will pick up noise when
> the switch is closed if the wires are bundled with
> the stepper wires.

It seemed to work for y and z, and now it works for x as well. Though I guess it is a good idea to add them when I do my next electonics component order. Do I have to switch off the internal pull-ups, then?
Re: Project: Teacup Firmware
June 10, 2011 05:44AM
aka47 Wrote:
> 2. extract.py fails when executed with the
> following :-
>
> [email protected]:~/Data/Common/development/Teacup_
> Firmware$ ./extract.py
> ./extract.py: line 8: syntax error near unexpected
> token `('
> ./extract.py: line 8: `re_comment =
> re.compile(r"\s*//\?\s?(.*)")'

Linux probably thinks it is a shell script.

Try either:
run python manually, i.e. "python extract.py". This is what I normally do.
add the line
#!/usr/bin/python
to the top of extract.py .
Re: Project: Teacup Firmware
June 10, 2011 05:45AM
Jens_R Wrote:
-------------------------------------------------------
> I removed that code and now it works fine for me.

Cool, so that was the problem with your X endstop? I'll put that one down as a bug for backporting to master

aka47 Wrote:
-------------------------------------------------------
> Guys as ever great things happening here.
>
> Just been having a play with the extract.py
> script. and found a couple of things.
>
> 1. The script as it comes from the repository is
> missing the execute permission so won't run on
> Linux/Unix unless this is set first. ( chmod +x
> extract.py ). It is probably worth considering
> setting the permission on the file in the
> repository though. Like it is for the other python
> scripts.
>
> 2. extract.py fails when executed with the
> following :-
>
> [email protected]:~/Data/Common/development/Teacup_
> Firmware$ ./extract.py
> ./extract.py: line 8: syntax error near unexpected
> token `('
> ./extract.py: line 8: `re_comment =
> re.compile(r"\s*//\?\s?(.*)")'

I have no idea what this script is or what it's for!

> The thing I was working towards was looking to see
> if Gcode commands had been implemented to
> manipulate the eeprom values for the PID
> settings??

See M130-134, they've been there since I added PID smiling smiley

> A last question.
>
> Running quickly through the code it looks a bit
> like the PID values are the same for both the Bed
> and Extruder heaters.
>
> Is this actualy so or am I getting it all horribly
> wrong ??

M130 P0 Snn sets extruder, M130 P1 Snn sets bed. P word is an index to the heaters array. Same for M131-M136.

Having same PID params for both would totally defeat the purpose of having PID in the first place!

M104, M105 and M109 also support a P word for index to temp sensors array. M140 is simply a shortcut for M104 P1 (assuming bed is 2nd sensor). I decided that having a new M-code for each heater/sensor pair wasn't forwards compatible so I made my own protocol addition smiling smiley

NOTE: M130-M136 index heaters array, but M104/5/9 index temp sensors array! Most configurations will have both arrays matching but it's not necessary and not assumed by teacup anywhere that I know of.


-----------------------------------------------
Wooden Mendel
Teacup Firmware
Re: Project: Teacup Firmware
June 10, 2011 05:47AM
that extract.py works like this for me:

python2.6 extract.py && cat gcode_doc.txt

doesn't work in python3 and doesn't have a shebang so can't be called directly


-----------------------------------------------
Wooden Mendel
Teacup Firmware
Re: Project: Teacup Firmware
June 10, 2011 06:09AM
Triffid_Hunter Wrote:
-------------------------------------------------------
> Jens_R Wrote:
> --------------------------------------------------
> -----
> > I removed that code and now it works fine for
> me.
>
> Cool, so that was the problem with your X endstop?
> I'll put that one down as a bug for backporting to
> master

Yes. I guess the movement code set the timer, which triggered the debug-led, which (on my board) switched off the pull-up resistor.
Re: endstops ignored, STEPS_PER_MM_E
June 10, 2011 07:34AM
Quote

It seemed to work for y and z, and now it works for x as well. Though I guess it is a good idea to add them when I do my next electonics component order. Do I have to switch off the internal pull-ups, then?

No they won't do any harm.


[www.hydraraptor.blogspot.com]
Re: Project: Teacup Firmware
June 10, 2011 05:16PM
OK

I use mechanical micro-switches for my end-stops.

Attached is a schematic.

It less clever in reality as the capacitor and resistor are soldered directly across the micro-switch contacts and no PCB is needed.

It uses the same VCC and GND feeds that an Opto endstop would use.

Basically when in a stable (at end-stop, no at end-stop) state the output is either hard switched to GND or VCC as appropriate.

Given that logic circuitry (particularly CMOS) is measured against the supply rails (even if noisy) then the signal will have a small degree of noise immunity.

The capacitor and resistor form a de-bounce circuit that cleans up the signal as the contacts change over (ie as you activate or release the end-stop). Micro-switches when wired this way have the property of not bouncing between the two outer contacts only that the common connection bounces on the contact is is being pushed towards. The de-bounce circuit then gives the signal a value during the period when the contacts are all disconnected from each other ie in motion. It also makes sure that as the contacts make/break ie bounce there is a signal maintained that matches that which the output will have when the contacts come to rest.

I think I used the values of 1K and 100n for the capacitor and resistor, these were " what have I got in my scrap box that feels about right values" there was no calculation for them.

However there are optimum values for these, I just wanted to have a life as well.

Hope this is useful to someone as an opto end-stop alternative.

Cheers

aka47


Necessity hopefully becomes the absentee parent of successfully invented children.
Attachments:
open | download - endstop.jpg (57.1 KB)
Re: Project: Teacup Firmware
June 10, 2011 06:19PM
sliptonic Wrote:
-------------------------------------------------------

>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 just finished the switch to the weekly Master and am having the exact same problem.
Even with Hysteresis values of 20 and Residency of 0 and 1 it still takes a few minutes to say "temp achieved"

I'm using bang bang with 0 and 255 for my on/off. Doing constant M105's has let me know the heater settles down to +-3 deg very quickly, but still it waits.

The march 3rd version of teacup reliably reported temp achieved within seconds of the first "off"

I've attached my current config if that helps.
Any insights?

Thanks!
Attachments:
open | download - config.h (20 KB)
Re: Project: Teacup Firmware
June 10, 2011 10:24PM
My electronics is in a state of disarray after receiving a mega and a bunch of printed parts to further advance my printer, so I can't be terribly helpful right at this moment. Feel like doing a git bisect to try and track down a commit that introduces this regression, since you've found a good and a bad commit?


-----------------------------------------------
Wooden Mendel
Teacup Firmware
Re: Project: Teacup Firmware
June 11, 2011 01:20AM
aka47, the cap looks good. For the resistor, ATmega's internal pullup resistor might work as well. Just #define USE_INTERNAL_PULLUP in config.h. The internal one has 10K.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
June 11, 2011 02:13AM
It doesn't need a pullup if you use both halves of the switch and the cap for de-bounce will work better without it. Not sure bounce on a limit switch matters though.


[www.hydraraptor.blogspot.com]
Re: Project: Teacup Firmware
June 11, 2011 02:13AM
It doesn't need a pullup if you use both halves of the switch and the cap for de-bounce will work better without it. Not sure bounce on a limit switch matters though.


[www.hydraraptor.blogspot.com]
Re: Project: Teacup Firmware
June 11, 2011 06:02AM
One advantage of using a normally-closed switch with an internal pull-up or the pull-up on the main circuit board is that you get a "triggered" signal if the wire to the switch gets disconnected. That's safer than the opposite case where the hardware thinks the switch is not triggered when it is disconnected.
Re: Project: Teacup Firmware
June 11, 2011 09:00AM
Using Teacup (Master Branch from 15 may),Ramps,ReplicatorG.

acceleration = reprap
extrusion set to relative

Encounter the following problem: (occurs with Skeinforge35,39 and also with Skeinforge40 generated GCodes)

After printing the first layers of a single walled square test object, the extruder stepper stops before the destination of the current G command is reached. He then restarts for the next few G commands, and stops again in a (non specific) G command before the destination is reached. This goes on until the end of the build.

First I thought it were the extruder reversels that somehow broke the E-axes counter, but that is not the problem.

To me it looks as if:

a) an internal counter?? overflows because he is not set to zero at each new G command
b) the E axes step count has reached its target *before* X & Y axis.
c) an acceleration calculation problem?

When I disable acceleration completely, the problem also occurs, only around 10 layers later in the print.


I tried to find something in the dda.c, but for now I don't yet fully understand the working.

Any clues or suggestions where I can search?

Thanks in advance

Edit: Added info when acceleration is disabled completely.

Edited 2 time(s). Last edit at 06/11/2011 09:20AM by cloudmaker.
Re: endstops ignored, STEPS_PER_MM_E
June 11, 2011 09:09AM
On PID values.

Yes I fully agree they need to be different for each heater (bed versus extruder).

They are both set to the same though in the file heater.c via the default PID values.

My understanding then is that :-

They need to be changed manually after download, via M commands. As they are by default the same.

Might be worth documenting that somewhere for newbies to pick up on.

Looking through the code, it looks to me like once set in the eeprom (by the firmware, not as part of the chip programming) they are intended to survive a reload of the firmware.

Is this correct ??

Cheers

AKA47

BTW I can confirm that I haven't managed to get printing to resume after the M109 to set the extruder temperature either and I am also using the master branch. This is why I am rummaging around in the heater code to work out if it is perhaps my lack of understanding or a bug/feature.


Necessity hopefully becomes the absentee parent of successfully invented children.
Re: Project: Teacup Firmware
June 11, 2011 09:18AM
cloudmaker Wrote:
-------------------------------------------------------
> Using Teacup (Master Branch from 15
> may),Ramps,ReplicatorG.
>
> acceleration = reprap
> extrusion set to relative
>
> Encounter the following problem: (occurs with
> Skeinforge35,39 and also with Skeinforge40
> generated GCodes)
>
> After printing the first layers of a single walled
> square test object, the extruder stepper stops
> before the destination of the current G command is
> reached. He then restarts for the next few G
> commands, and stops again in a (non specific) G
> command before the destination is reached. This
> goes on until the end of the build.
>
> First I thought it were the extruder reversels
> that somehow broke the E-axes counter, but that is
> not the problem.
>
> To me it looks as if:
>
> a) an internal counter?? overflows because he is
> not set to zero at each new G command
> b) the E axes step count has reached its target
> *before* X & Y axis.
> c) an acceleration calculation problem?
>
> I tried to find something in the dda.c, but for
> now I don't yet fully understand the working.
>
> Any clues or suggestions where I can search?

post your config and the failing gcode. Do you have E_ABSOLUTE defined? This affects the only code that treats E differently from the other axes.


-----------------------------------------------
Wooden Mendel
Teacup Firmware
Re: endstops ignored, STEPS_PER_MM_E
June 11, 2011 09:23AM
Jens_R Wrote:
-------------------------------------------------------
> One advantage of using a normally-closed switch
> with an internal pull-up or the pull-up on the main
> circuit board is that you get a "triggered" signal if
> the wire to the switch gets disconnected.

You could do both- have the switch pull low for run and high for triggered, and enable the pull-up so when the switch is operating normally you'll get a nice low impedance signal line, and if the line breaks it registers as triggered.

aka47 Wrote:
-------------------------------------------------------
> They need to be changed manually after download,
> via M commands. As they are by default the same.

yes that's true

> Might be worth documenting that somewhere for
> newbies to pick up on.
>
> Looking through the code, it looks to me like once
> set in the eeprom (by the firmware, not as part of
> the chip programming) they are intended to survive
> a reload of the firmware.

yep that's true. Unfortunately we don't check if the heater array has changed, so if you program in some values, then rearrange your heaters, they may behave poorly until sorted.

I think the most sensible thing to do is pick some reasonable defaults and not write them unless M135 is called, this way most users don't worry about it but it's still sitting there for those who like to fiddle.


-----------------------------------------------
Wooden Mendel
Teacup Firmware
Sorry, only registered users may post in this forum.

Click here to login