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
-----------------------------------------------
Wooden Mendel
Teacup Firmware
-------------------------------------------------------
> 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
-----------------------------------------------
Wooden Mendel
Teacup Firmware
|
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
-----------------------------------------------
Wooden Mendel
Teacup Firmware
-------------------------------------------------------
> 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
-----------------------------------------------
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
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
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.
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
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
I'll have a proper look through your repository in a bit
-----------------------------------------------
Wooden Mendel
Teacup Firmware
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
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
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..
-------------------------------------------------------
> * 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
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..
|
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.
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:
Edited 2 time(s). Last edit at 06/10/2011 05:36AM by Jens_R.
> > 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.
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: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 :-
>
> andy@quicksilver:~/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
> 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
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
-------------------------------------------------------
> 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 :-
>
> andy@quicksilver:~/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
> 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
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
Sorry, only registered users may post in this forum.