Project: Teacup Firmware

VikOlliver Wrote:
-------------------------------------------------------
> > ((x_min() == 0 ) || (dda->x_direction != 0))) {
> > for all 3 axes.
> >
> > I do something similar for all axis but only for
> MIN as thats is all I have:
> > if (x_min() != dda->x_direction)
>
> These are not equivalent - for me at least.
>
> Vik :v)

Doesn't x_min ==0 and x_dir ==0 mean you are going backwards on the x axis and your x endstop has been tripped?

Almost. Going backwards and my X min endstop hasn't been tripped yet.

x_min reports 16 when my endstop is tripped.

Vik :v)

There are some timer issues (at least on my 644P).

If I set the TICK_TIME to anything other then 65535 the motors won't run smoothly at high speeds. The problem is in timer.c if delay <= TICK_TIME happens (Line 102) and the timer overflow interrupt happens before the compare interrupt, the compare interrupt gets set to next_step_time which is too much if TICK_TIME is anything other than 65535. I'm not sure how to fix it correctly, but I'm not sure why TICK_TIME should be anything other than 65535.

The other problem if TICK_TIME is below 1 MS TICK_TIME_MS is zero and this causes the clock_xxms function to stop working.

VikOlliver Wrote:
-------------------------------------------------------
> Almost. Going backwards and my X min endstop
> hasn't been tripped yet.
>
> x_min reports 16 when my endstop is tripped.
>
> Vik :v)


Interesting, maybe that's why I'm not seeing any of the reported noise on my endstops. mine all go Low (0) when tripped anything else is ignored. I'm using endstops from another incomplete project optoswitches from sparkfun. Are you using the REPRAP endstop electronics? is this the default for those?

Markus Amsler Wrote:
-------------------------------------------------------
> There are some timer issues (at least on my
> 644P).
>
> If I set the TICK_TIME to anything other then
> 65535 the motors won't run smoothly at high
> speeds. The problem is in timer.c if delay <=
> TICK_TIME happens (Line 102) and the timer
> overflow interrupt happens before the compare
> interrupt, the compare interrupt gets set to
> next_step_time which is too much if TICK_TIME is
> anything other than 65535.

well spotted, hadn't thought of that possibility

> I'm not sure how to fix
> it correctly

I'm fixing it so it compares next_tick_time instead of delay, please test

> I'm not sure why TICK_TIME
> should be anything other than 65535.

At 65535 (or MAX), our clock period is 4.096ms which is probably quite usable, but then all our clock stuff must be multiples of that value, and it doesn't make much difference to use a lower value unless there are bugs elsewhere

> The other problem if TICK_TIME is below 1 MS
> TICK_TIME_MS is zero and this causes the
> clock_xxms function to stop working.

why would you want a TICK_TIME below 1MS, when all the clock stuff works on a 1MS base increment? It's certainly possible to do, but you'll have to change all the clock stuff to use TICK_TIME_US which you'll have to define somewhere, also you'll need to increase the width of clock_counter_10ms so it can count to 10,000 instead of 10, or perhaps redo the math there so it counts up to CLOCK_TICKS_PER_10MS which you'll also have to define

---

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

Triffid_Hunter Wrote:
-------------------------------------------------------
> I'm fixing it so it compares next_tick_time
> instead of delay, please test
The motor now runs smoothly, but too slow at high speeds. Looks like there's some cap. If the timer overflow happens every TICK_TIME and TCNT1 gets reset to 0 it should work IMHO. So I'm not sure what's going on anymore, this timer stuff is a bit confusing.

> why would you want a TICK_TIME below 1MS, when all
> the clock stuff works on a 1MS base increment?
I was just messing around with some config values, and my motors happend to run better with TICK_TIME set to 0.1 MS. Which is of course a wrong way to "fix" bugs.

Yeah the timer stuff is confusing, perhaps we need a more thoroughly tested module that can fire an interrupt at 2us to 1s in the future while providing the clock flags for main loop timing stuff

---

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

I tried the input-float branch over the weekend. I noticed Make reported it used 100% of the ram on the 168. It also didn't give a "start ok" on boot and would not respond to any commands. So that is the extent of the testing I can do on that branch.

I also found that if I don't define any heaters I can enable debug which let me get more information about the other issues I am having. Unfortunately I am not having much luck making heads or tales of some of it and will likely need to ask for help interpreting it in the near future.

I am currently trying the latest commits which don't allow me to not define any heaters. I see that I can enable bang bang heater control to the same end. I can compile when I uncomment the bang bang lines (no other changes to heaters) but when I enable both bang bang and debug I get these errors:

heater.c: In function ‘heater_tick’:
heater.c:181: error: ‘t_error’ undeclared (first use in this function)
heater.c:181: error: (Each undeclared identifier is reported only once
heater.c:181: error: for each function it appears in.)
heater.c:181: error: ‘heater_p’ undeclared (first use in this function)
heater.c:181: error: ‘heater_d’ undeclared (first use in this function)
heater.c:181: error: ‘pid_output_intermed’ undeclared (first use in this function)
make: *** [heater.o] Error 1

Edited 1 time(s). Last edit at 02/07/2011 09:53PM by spaztik.

100% ram probably means 'more than all' which leaves zero room for stack- I think 90% is a sane upper limit. beyond that, expect breakage

latest commit allows DEBUG and BANG_BANG

it lets me compile with no heaters, as long as I also have no temp sensors. I think this new subsystem needs a lot more work before we can use it unfortunately, or at least we should ditch using the names

---

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

Triffid_Hunter Wrote:
-------------------------------------------------------
> 100% ram probably means 'more than all' which
> leaves zero room for stack- I think 90% is a sane
> upper limit. beyond that, expect breakage
>

Yeah, I thought that might be a bad sign.

> latest commit allows DEBUG and BANG_BANG

Yes it does and I'll just confirm that it loads and works on the 168. Thanks for that.

>
> it lets me compile with no heaters, as long as I
> also have no temp sensors. I think this new
> subsystem needs a lot more work before we can use
> it unfortunately, or at least we should ditch
> using the names

I only disabled the heater to get debug running. DEBUG and BANG_BANG is better.

VikOlliver Wrote:
-------------------------------------------------------
> Well, if it was me I'd have a look in temp.c, put
> in a sersend to output the analogue value of the
> thermistor pin (or maybe use existing debug).

Triffid_Hunter Wrote:
-------------------------------------------------------
>for those of you who have linux boxen, room for DEBUG and have worked out how to use func.sh,

>mendel_readsym adc_result

>will spit out the whole buffer in hex

So, I get this.

mendel_readsym adc_result
M253S909P16
D6030000000000000000000000000000

I think this means the the thermistor reading is d603 in hex which is 54787 in decimal. In temp.c I find this line in the temptable.

{54, 255},

Which might mean that at 255 degrees the thermistor should read 54*1024=55296. I suppose a reading of 54787 could translate to 297.

I am however just guessing and probably have it all wrong because none of this matches what I actually measure across the thermistor (125k at room temp) or the temp. table in the datasheet for my thermistor which translates the125k to 20 deg. C. I am using the temp sensor kit and a thermistor (not the one included with kit) from Makerbot. Unless Makerbot changed thermistors between when I bought mine and now it's a B57560G104F. Its a 100k thermistor, is this the same/similar to what the temptable is built on?

I am not really sure what to make of this. Any help is appreciated.

Edited 1 time(s). Last edit at 02/08/2011 02:17AM by spaztik.

AVR is little endian, so D603 is actually 0x03D6, or 982. According to the last two entries in the default table, that's 18 degrees.

linear interpolation goes like this, for all your manual checking needs:
result = (value - oldmin) * (newmax - newmin) / (oldmax - oldmin) + newmin
where oldmin/oldmax are the left column (ADC readings), and newmin/newmax are the right column (temperatures)

The ADC is only 10 bit so you will never get a reading greater than 1023.

If you're just looking at the first entry in the table, mendel_readsym_uint16 should give you 982 (or whatever) directly. I haven't added support for arrays or pointer arithmetic to the mendel_readsym family yet, patches welcome

---

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

Ok I found the issue with the timer after some sleep .

The overflow interrupt sets the wrong comparator timeout. It takes TICK_TIME-TCNT1 from setTimer to the overflow interrupt. At the overflow interrupt TCNT1 is zeroed, so adjust next_step_time by (TICK_TIME-TCNT1) + TCNT = TICK_TIME.
Do I make any sense? hard to explain.

Anyway the attached patch works here.

heh I'll believe you, patch pushed, thanks!

---

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

Hello Guys!

I found a mistake in the firmware which causes it not to turn off all electronics on m191 command.
In the gcode_process.c or pinio.c the inclusion of config.h is missing. He doesn't know about the pin PS_ON_PIN from the config and the command power_off() will not put this pin to input mode!

Triffid, may you fix that?

Edit: I found an other problem: I am not able to heat the mendel manual because the firmware turns off after 30 seconds. Why does it turns off when I am heating???

Edited 1 time(s). Last edit at 02/08/2011 01:07PM by Jacky2k.

Here are 3 minor patches, which are lurking around in my tree:

- make *_MIN_PIN defines optional
- G28: home all axis if no axis is selected
- Add Extruder.pde, so extruder is compilable with Arduino IDE

thanks Jacky2K, Marcus, patches pushed! tell me how you go

---

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

pinio.c line 15 is missing a semicolon.

---

--
I'm building it with Baling Wire

thanks, pushed

---

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

The firmware seems to work on Gen7 now. Heated bed not tested yet.
I have a suggestion for the firmware, maybe it was already discussed earlier, don't know
What about seperated config files for electronics and the mechanicals? And a easy way to choose between those "board support packages". The user won't have to edit the config files for his hardware, he just selects the hardware in the main config file and everything works. So there should be configs for all boards existing.
And one configuration for the printer, where to set steps per mm etc...

Jacky2k Wrote:
-------------------------------------------------------
> The firmware seems to work on Gen7 now. Heated bed
> not tested yet.
> I have a suggestion for the firmware, maybe it was
> already discussed earlier, don't know
> What about seperated config files for electronics
> and the mechanicals? And a easy way to choose
> between those "board support packages". The user
> won't have to edit the config files for his
> hardware, he just selects the hardware in the main
> config file and everything works. So there should
> be configs for all boards existing.
> And one configuration for the printer, where to
> set steps per mm etc ...

I am not sure if this is what you mean but there has been some discussion about separate config files based on board type. I believe the idea is that you could choose your hardware type in the Make file and it would choose the appropriate config for that board. In the latest commit there is evidence of this starting to happen (or maybe it is complete already). I believe the discussion started at or around this comment.

Edited 1 time(s). Last edit at 02/09/2011 06:23PM by spaztik.

So, there is a lot of very useful information that goes by in this thread. Much of it is very difficult for us mere user to glean from the code itself. As an example, take Triffid_Hunter's reply to my most recent question. I know I have had trouble finding some of this info again even though I have seen it before and know it exists. I can't imagine the difficulty a new user might have trying to find these bits of info in this massive thread.

There was a commenter who suggested mining the information out of the thread and putting it into an easier to digest form. I believe this user also expressed an interest in taking on this challenge themselves. To whomever that user was, I would like to say that I would be interested in assisting such an effort. If you are still interested please PM and we can discuss how to best to go about it.

Hopefully this is the last timer patch.

The old implementation with an overflow interrupt for the clock and a comparator interrupt for stepping, had an unsolvable bug: If the comparator interrupt should happen very shortly (down to 1 cpu clock cycle) after the overflow interrupt the comparator interrupt would miss. And with 2 comparators the implementation is more straightforward.

Currently all steps are a bit too long. That's because the time from step interrupt, to the next call of setTimer is not subtracted from the delay. At (very) high speeds with acceleration that's up to 20% longer steps. It looks like the official firmware has the same issue. This patch also addresses this.

I tested this pretty throughly, with a house shaking gcode script. And I got 500mm/s out my x-axis with acceleration before missing steps, not sure if that's a reprap record

That's my first bigger chunk of avr code, so suggestions are welcomed.

To add to this config per board theme, I submitted a pull request that turns the placeholder config.ramps.h into one that functions on RAMPS v1.1. I tested manual axis and extruder movement using repsnapper, but haven't actually tried printing anything.

Just an attempt at lowering the barriers for anyone interesting in trying out this firmware on RAMPS.

that's excellent markus! It's taken me a bit to wrap my head around what you've done, and it makes heaps more sense than the method I was trying to use - evidently, because it works better

---

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

Quote

Hopefully this is the last timer patch.

I'm surprised there is so much going on in timer.c I still use a version from months ago (what was once the "release-candidate"), it's much simpler than the unpatched and patched version on master and works flawlessly, as far as I can tell.

Quote

with 2 comparators the implementation is more straightforward.

My impression is, this old version actually uses two timers. The only problem was, the clock timer had a higher priority than the stepper timer. Swapping both is not possible, because the higher priority timer lacks resolution.

Quote

Currently all steps are a bit too long. That's because the time from step interrupt, to the next call of setTimer is not subtracted from the delay.

The idea was, the timer counter is set to zero at interrupt time. So, while the interrupt code is executed, it's already counting. To be accurate, one just shouldn't reset the timer counter to zero in SetTimer().

This test G-Code is very welcome, how does one see wether the timer works well or not?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> I'm surprised there is so much going on in timer.c
> I still use a version from months ago (what was
> once the "release-candidate"), it's much simpler
> than the unpatched and patched version on master
> and works flawlessly, as far as I can tell.
>
At low speeds (F<1500 on a belted mendel) or short moves the problems are hard to see.
With something like G1 F3000 G1 Y0 G1 Y200 you should hear the steppers running not smoothly, there are some irregularities in the timers.
Also for close speeds (like F1400 and F1300) you hear the motors are running at the same speed, which they shouldn't

> My impression is, this old version actually uses
> two timers. The only problem was, the clock timer
> had a higher priority than the stepper timer.
> Swapping both is not possible, because the higher
> priority timer lacks resolution.
There's only one 16 bit timer on this microchips. The other two (or more?) are 8bit timers and are used/reserved for PWM as it seems.
The 16 bit timer has 4 interrupts according to the specs:

13 $0018 TIMER1_CAPT  Timer/Counter1 Capture Event
14 $001A TIMER1_COMPA Timer/Counter1 Compare Match
15 $001C TIMER1_COMPB Timer/Counter1 Compare Match
16 $001E TIMER1_OVF   Timer/Counter1 Overflow

With their priority in this order. The old used TIMER_COMPA for stepping, TIMER_OVF for 10ms clock. The stepper interrupt actually could have interrupted the clock, but you would have to mess around with nested interrupts (not sure if that's possible at all).
The new implementation uses COMPA for stepping, COMPB for clock. What make's it simpler is that the two interrupts are independant. You donn't have to care for COMPA in COMPB or the other way round. In the old implementation you always had to care for COMPA in the OVF interrupt.

> > Currently all steps are a bit too long. That's
> > because the time from step interrupt, to the next
> > call of setTimer is not subtracted from the
> > delay.
>
> The idea was, the timer counter is set to zero at
> interrupt time. So, while the interrupt code is
> executed, it's already counting. To be accurate,
> one just shouldn't reset the timer counter to zero
> in SetTimer().
It would have certainly been possible to fix that issue with the "old" code.

> This test G-Code is very welcome, how does one see
> wether the timer works well or not?
You don't see it you hear and feel it. It should slowly shake your machine faster, and sounds towards the end like a jet fighter taking off . You can hear if different speeds are more or less correctly executed. It was generated with this php script:

<?php
	for ($i=100; $i<=10000; $i*=1.01){
		echo "G1 F" . round($i) ."\n";
		echo "G1 Y" . round($i/1000, 2) . "\n";
		echo "G1 Y0 X0\n";
	}

?>

I have choosen the parameters, so that it doesn't run for hours and covers a wide range of speeds. But you can adjust them, to simulate an accelerating turtle.

Edit:
I just realized that the timer from months ago was more or less the same like in the official firmware. So my answer may or may not fit. I'm not sure what was the reason to change the original timer code (which certainly worked better than the one I'm fixing here), it might have to do with the 10ms clock, or the fact it was adjusting the timer resolution for slow speeds.

Edited 1 time(s). Last edit at 02/10/2011 07:09AM by Markus Amsler.

Markus Amsler Wrote:
-------------------------------------------------------

> At low speeds (F<1500 on a belted mendel) or short
> moves the problems are hard to see.
> With something like G1 F3000 G1 Y0 G1 Y200 you
> should hear the steppers running not smoothly,
> there are some irregularities in the timers.
> Also for close speeds (like F1400 and F1300) you
> hear the motors are running at the same speed,
> which they shouldn't

This sounds like the exact same bug I encountered back in December, both with the release_candidate and again with master after it was merged. I however encountered it at much lower speeds as I'm using a threaded rod drive. My work around was much the same as what was mentioned above... shortening the step time and patching the 10ms counter to be 16 bits instead of 8. I'm looking forward to trying this patch which will hopefully let me crank a little more out of my setup!

Many thanks Markus!

Triffid_Hunter Wrote:
-------------------------------------------------------
> AVR is little endian, so D603 is actually 0x03D6,
> or 982. According to the last two entries in the
> default table, that's 18 degrees.

I still can't get m105 to report a sane temp reading. The ADC readings seem correct, 18.75 is what m105 used to report at room temp.

spaztik Wrote:
-------------------------------------------------------
> I am also having trouble with my y axis. When I
> move my extruder any distance, then try to move y
> both the y axis and the extruder move.

Triffid_Hunter Wrote:
-------------------------------------------------------
>sounds like gcmd.seen_E isn't being reset or something, but it's clearly being reset on lines 350 >and 364 of gcode_parse.c.. really not sure what's going on there

This feedback seems to support that theory.

g1 y10
G1Y3200
ok 
{DDA_CREATE: [0,3200,0,0] [ts:3200,ds:9834] }

g1 x10
G1X3200
ok 
{DDA_CREATE: [3200,0,0,0] [ts:3200,ds:9834] }

g1 e10
G1E3200
ok 
{DDA_CREATE: [0,0,0,3200] [ts:3200,ds:10000] }

g1 x0
G1X0
ok 
{DDA_CREATE: [-3200,0,0,3200] [ts:3200,ds:9834] }

g1 y0
G1Y0
ok 
{DDA_CREATE: [0,-3200,0,3200] [ts:3200,ds:9834] }

g1 z10
G1Z3200
ok 
{DDA_CREATE: [0,0,3200,3200] [ts:3200,ds:10000] }

g1 f1500
G1F1500
ok 
{DDA_CREATE: [0,0,0,3200] [ts:3200,ds:10000] }

g1 e0
G1E0
ok 
{DDA_CREATE: [0,0,0,0] [ts:0] }

g1 z0    
G1Z0
ok 
{DDA_CREATE: [0,0,-3200,0] [ts:3200,ds:10000] }

g1 f1500
G1F1500
ok 
{DDA_CREATE: [0,0,0,0] [ts:0] }

So far I have tried to prove my electronics good by loading the firmware onto two different arduinos (boarduino and diecimila, both atmega168). Then I swapped the atmega168 on the diecimila with an atmega328p I had stashed away. Finally I downloaded a fresh copy of the source (not the first time) and made the config.h as vanilla as possible. None of this made any difference.

I now have debug enabled to help troubleshooting but don't really know what to look for. Anyone with any ideas on how to track these bugs down please let me know.

Quote

g1 x0
G1X0
ok
{DDA_CREATE: [-3200,0,0,3200] [ts:3200,ds:9834] }

Clearly you want to find out how this second 3200 gets in there. As you can apparently reproduce and document the misbehaviour easily, the harder part of the work is done already. Next steps would be to find out what's passed to dda_create() (likely the same mistake, but checking for facts is always a good idea). Then look at the data sent from the G-Code interpreter, section for G1. If yes, compare it to the handling of the X axis. If not, go step by step back to find out where it gets in ... and so on.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Currently the intercom for GEN3 extruder controller only supports one temperatur reading and one temperatur setting. I have connected sensor/heater extruder, sensor/heater bed, fan to my extruder controller and there are still some pins left.

The official firmware has an ascii protocol running over intercom, which seems a bit overkill (and I'm no fan of ascii for machine <-> machine communication). Also the official firmware only reads the temperatur on request (M105), where FDoA polls on a 10ms intervall.

My proposed intercom:
Host sends all 10ms(or less) all needed data to the controller. Controller sends back all 10ms all his readings/status to the host. Communication is asynchronus, unreliable and has a fixed packet length(something like UDP). Unreliable is no problem as in another 10ms everything is sent again.

Packet structure:

Byte Bit  Description
0    0    Digital output 0 on/off 
     1    Digital output 1 on/off
     2    Digital output 2 on/off
     3    Digital output 3 on/off
     4    Digital output 4 on/off
     5    Digital output 5 on/off
     6    Digital output 6 on/off
     7    always set, to mark start of packet
1    0-2  controller number (up to 8 exturder controllers)
     3-6  unused
     7    0
2    0-6  Temp 1 bits 7-13
     7    0
3    0-6  Temp 1 bits 0-6
     7    0
4    0-6  Temp 2 bits 7-13
     7    0
5    0-6  Temp 2 bits 0-6
     7    0
6    0-6  Temp 3 bits 7-13
     7    0
7    0-6  Temp 3 bits 0-6
     7    0
8    0-6  Error/status code
     7    0
9    0-6  Checksum Sum(Byte0-Byte9) modulo 128 = 0
     7    0

The temperatur is 12.2 fixed point. The error codes need to be defined.
The same packet is used for setting/getting values. If the host sends a packet the meaning of the temperatur is target temperatur. If the host receives a packet the meaning is current temperatur readings.
The packet is 10 bytes=80 bits every 10ms results in 8000Baud. So bandwith seems no problem.
Receiving a packet is simple. Just look if the 7th bit is set, than read the next 9 bytes and check the ckecksum. Only 2 status required: Waiting for packet, receiving packet. After the Packet is received, it copies it's values (dependant on the config) into the intern data structures.

The only problem i'm not sure of, is how many collisions this, uncoordiated sending/receiving will produce.