Project: Teacup Firmware

Found it.
sersendf_P("X:%ld,Y:%ld,Z:%ld,E:%ld,F:%ld\n",....
should be:
sersendf_P(PSTR("X:%ld,Y:%ld,Z:%ld,E:%ld,F:%ld\n"),....

and now M114 works. a quick "grep ser.*_P *.c" seems to indicate that this is the only place in the code where that little macro was forgotten. Figures that I'd find the one place it was done wrong to emulate...

== edit ==
Further investigation shows that this bug is already fixed upstream. Merged upstream.

Edited 1 time(s). Last edit at 10/28/2010 07:41PM by jgilmore.

---

--
I'm building it with Baling Wire

Traumflug Wrote:
-------------------------------------------------------
> What are the delay units?
>
> Clock ticks, or 1/16,000,000 seconds. You can
> adjust this by using the correct F_CPU.

I did: #define F_CPU 100000000L /* 100MHz */, because my ARM it's running at 100MHz.

It's because of this: // linear acceleration variables: c and end_c are 24.8 fixed point timer values, n is the tracking variable that timer is always called like this: setTimer(dda->c >> 8);?? --> 24 + 8 = 32 bits? (dda->c is of uint32_t).

I get stepper motor pulses however they are slow, like if G1 Fxxx value is very low. I tested my setTimer() and it works well, in CPU ticks (1/100MHz).

Edited 2 time(s). Last edit at 10/29/2010 01:34PM by casainho.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

I have been working on getting endstops working. There is a DDA issue that I am not sure how to solve.

If you just skip the step on an axis that hits the endstop that can cause the DDA to abort when did_step=0.

If I do all the normal logic for a step except setting the actual step pin the DDA doesn't get aborted, but then it has to run the full course (ie along time when doing a -250 on the G28 home) before the DDA ends.

If I set the current_position to the dda.endposition for the axis that hit the endstop and set did_step = 1, that doesn't end the DDA right away, but the next time the timer comes around and expects to step that axis, but it is at the end alredy did_step=0 and it gets aborted.

Jeremy

casainho Wrote:
-------------------------------------------------------
> I did: #define F_CPU 100000000L /* 100MHz */,
> because my ARM it's running at 100MHz.
>
> It's because of this: // linear acceleration
> variables: c and end_c are 24.8 fixed point timer
> values, n is the tracking variable that timer is
> always called like this: setTimer(dda->c >> 8);??
> --> 24 + 8 = 32 bits? (dda->c is of uint32_t).
>
> I get stepper motor pulses however they are slow,
> like if G1 Fxxx value is very low. I tested my
> setTimer() and it works well, in CPU ticks
> (1/100MHz).

As a kludge, set your F_CPU to 20MHz and multiply by 5 inside setTimer(), however this needs to be fixed properly. With that many MHz, you could probably get away with boosting that to a 64-bit integer, perhaps 56.8 to keep the precision that some of the code sections seem to want.

jv4779 Wrote:
--------------------------------------------------
> I have been working on getting endstops working. There is a DDA issue that I am not sure how to solve.
>
> If you just skip the step on an axis that hits the endstop that can cause the DDA to abort when did_step=0.
>
> If I do all the normal logic for a step except setting the actual step pin the DDA doesn't get aborted,
> but then it has to run the full course (ie along time when doing a -250 on the G28 home) before the DDA ends.

> If I set the current_position to the dda.endposition for the axis that hit the endstop and set did_step = 1,
> that doesn't end the DDA right away, but the next time the timer comes around and expects to step that axis,
> but it is at the end alredy did_step=0 and it gets aborted.
>
> Jeremy

This is an unforeseen bug.. I think reordering the nested if blocks in dda_step should allow you to set did_step without actually stepping.. something like

if ([shoud step math]) {
  did_step = 1;
  if (end stops and can step)
    actually_step();
}

---

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

Triffid_Hunter Wrote:
> jv4779 Wrote:
> --------------------------------------------------
>
> > I have been working on getting endstops working.
> There is a DDA issue that I am not sure how to
> solve.
> >
> > If you just skip the step on an axis that hits
> the endstop that can cause the DDA to abort when
> did_step=0.
> >
> > If I do all the normal logic for a step except
> setting the actual step pin the DDA doesn't get
> aborted,
> > but then it has to run the full course (ie along
> time when doing a -250 on the G28 home) before the
> DDA ends.
>
> > If I set the current_position to the
> dda.endposition for the axis that hit the endstop
> and set did_step = 1,
> > that doesn't end the DDA right away, but the
> next time the timer comes around and expects to
> step that axis,
> > but it is at the end alredy did_step=0 and it
> gets aborted.
> >
> > Jeremy
>
> This is an unforeseen bug.. I think reordering the
> nested if blocks in dda_step should allow you to
> set did_step without actually stepping.. something
> like if () {
> did_step = 1;
> if (end stops and can step)
> actually_step();
> }

Is that a bug? If an endstop is hit, it's an error condition, yes?

This is what I have:
#if ENDSTOPS_OK_VALUE == 1
#define z_min() READ(Z_MIN_PIN)
#define z_max() READ(Z_MAX_PIN)
#else
#define z_min() !READ(Z_MIN_PIN)
#define z_max() !READ(Z_MAX_PIN)
#endif
And then the dda logic is:
if ((current_position.X != dda->endpoint.X)
#ifdef X_MAX_PIN
&& ( !dda->x_direction || x_max() )
#endif
#ifdef X_MIN_PIN
&& ( dda->x_direction || x_min() )
#endif
) {
/*unmodified below this point*/
And it's true that did_step doesn't get set, resulting in a premature termination of the dda.
That's OK though! When going home we just need to set a perfect diagonal, so each step steps all steppers. Wait, that won't work if the axises have different steps/mm settings.
OK, we'd need to make the "home" command four commands: diagonal, and then each axis individually.
I don't think there can be a better way to do it, as the home command should be aborted only when all axises have hit an endstop. OK, I suppose we could add a bit of code to abort if and only if all three endstops are triggered, but that'd get messy, as it's incorrect behavior when not homing.

Hrm. Thinking about it, shouldn't it be possible to feed the DDA false numbers (directly, instead of a coordinate) that would allow us to both skip the distance calculations and get each axis to traverse at maximum speed? Right now it's a max_x*2 guesstimate. (should be sqrt(max_x²+max_y²+max_z²) which in theory we can pre-calculate)

Hrm, false numbers:
c=max_axis_speed
total_steps=max_axis_speed*bed_size
x_delta = ( x_max * bed_size) * ( max_x / max_axis_speed )
x_counter = - total_steps / 2
endpoint.x= -bedsize
x_direction=0
Then each axis will traverse at max speed for a distance up to the twice the bed size. And all these numbers are constants, so we could stick them in program memory and copy them in. If you combined that with a conditional "abort only if all axis at endstops" you'd have something. You could even add some code to reverse those constants if for some reason "home" is towards the max endstop on the x axis.

My actual problem right now is false positives on the endstops, probably caused by electrical interference from the stepper wires they are running parallel to. Other than that it works OK as far as I can test.

It's worth keeping in mind that "home" is 0,0,0 and in traditional g-code doesn't correspond to "the point at which all endstops are triggered" but instead can be (and frequently is) modified by issuing a G92. But that's easily emulated by setting endpoint.x to zero instead of -bedsize.

---

--
I'm building it with Baling Wire

Yes if you run your endstop wires parallel to the stepper wires you will get false positives. I do on a machine that uses a normally closed microswitch. Ideally stepper cables and endstop cables should be screened.

I only use my endstops for homing, which I do with a simple foreground loop. My interrupt driven Breshenham code does not use the endstops at all. If you do use them you need to de-glitch them well, otherwise they will make the machine less reliable. I think this is probably why Makerbot got rid of them.

---

[www.hydraraptor.blogspot.com]

Hi everyone,

my name is Stephan and I have been playing around with the FiveD code a bit. I wrote the simulation code (since I still haven't received my PCB and motors, I have no choice ;-).

There have been complaints that the Arduino IDE would pick up the simulation files as well when compiling the firmware, so I moved everything into a subdirectory. I made a pull request on triffid's master or you can just check out [github.com]

If you want to compile the simulation, go to the simulation/ directory and run "make sim". It should work on any Linux system. If not - let me know.

I also added a shell script to plot positions and speeds using gnuplot. See the attached images for an example. The G-code used was this:

G1 X24 Y13 F200
G1 Y41
G1 X0 Y55
G1 X-24 Y41
G1 Y13
G1 X0 Y0 F1

I'm aware that my code is far from perfect. Especially the timers are difficult to simulate; I don't know whether I'm even getting close to the speed and precision that you have on a microcontroller.

In any case I'll be glad to hear your comments and I hope I can soon run the firmware on my own electronics and motors.

Cheers,
Stephan

Edited 1 time(s). Last edit at 10/30/2010 03:24PM by sw.

Quote

In any case I'll be glad to hear your comments

My comments? This simulation stuff is awesome!

I hope you don't mind if this doesn't get into the repo immediately. It's just because this stupid fact a day has only that many hours and my WolfStrap still isn't doing anything useful despite all parts needed for building the "Wade's" are lying around.


P.S.: I've seen you're a committer already. Feel welcome

Edited 1 time(s). Last edit at 10/31/2010 03:51AM by Traumflug.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Question about distance/interrupt time

If we do not have acceleration, having constant velocity (F), we have on the code: dda->c = (move_duration / startpoint.F); and later setTimer(dda->c);. Shouldn't we subtract to dda->c the time already passed since the interrupt fired?

And I would like to understand better this expression constants:

uint32_t move_duration = ((distance * 2400) / dda->total_steps) * (F_CPU / 40000);

Why 2400 and 40000?

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

Quote

Shouldn't we subtract to dda->c the time already passed since the interrupt fired?

Setting the timer to some value doesn't mean the timer counter is reset to zero. The counter for the next firing starts at when the last interrupt fired.

Quote

And I would like to understand better this expression constants:

uint32_t move_duration = ((distance * 2400) / dda->total_steps) * (F_CPU / 40000);

Why 2400 and 40000?

To avoid 32 bit overflow. Earlier calculation formulas are in the comments above this code line and explain what's achieved here.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> Shouldn't we subtract to dda->c the time already
> passed since the interrupt fired?
>
> Setting the timer to some value doesn't mean the
> timer counter is reset to zero. The counter for
> the next firing starts at when the last interrupt
> fired.

Good. In my code I am not doing it, so I need to implement it :-)

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

Traumflug Wrote:
-------------------------------------------------------
> And I would like to understand better this
> expression constants:
>
> uint32_t move_duration = ((distance * 2400) /
> dda->total_steps) * (F_CPU / 40000);
>
> Why 2400 and 40000?
>
> To avoid 32 bit overflow. Earlier calculation
> formulas are in the comments above this code line
> and explain what's achieved here.

Ok, I got it - now I understand all that and it's very good to know a bit more of this technology ;-)

I went for 64bits on a few variables nd now my code is:

uint64_t move_duration = ((((distance / 1000.0) * 60) / dda->total_steps) * (F_CPU));

1000 to convert distance from um to mm and 60 because it's mm per minute. F_CPU is 100MHz (100*10^6). This is working, I verified with oscilloscope.

I am being using serial terminal to send commands to board, all works. Now I am trying RepRap software and I am back to this error/problem -- I will try now to get help and know how to compile and debug that java code on Eclipse, I am using Eclipse also to program and debug the firmware on ARM :-)
Using RepSnapper, it connects just for more or less 1 second and disconnects, so the firmware should have some problem...

Edited 2 time(s). Last edit at 11/04/2010 12:09PM by casainho.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

two thoughts- I'm not sure if this firmware is sending temperature responses after "ok" on the same line at the moment, host may be expecting that. I think there are some relevant patches in my release-candidate-triffid branch. Also, host may expect CRLF line terminators, but firmware only sends LF at the moment

---

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

Triffid_Hunter Wrote:
-------------------------------------------------------
> two thoughts

Also, host
> may expect CRLF line terminators, but firmware
> only sends LF at the moment

I changed all sersendf to print the \r\n like this:

sersendf("ok T:%u.0 B:0.0\r\n", current_temp); /* for RepRap software */

But I still got the same problem.


- I'm not sure if this firmware is
> sending temperature responses after "ok" on the
> same line at the moment, host may be expecting
> that. I think there are some relevant patches in
> my release-candidate-triffid branch.

Yes, it was that problem. I changed the gcode_parse.c to not print the ok at the end of line on M105 command:

// process
process_gcode_command();

/* do not reply the "ok" when M105 command is done */
if (!(next_target.seen_M == 1 && next_target.M == 105))
{
    serial_writestr("ok\r\n");
}

RepRap software now get correctly the temperature. RepSnapper software now do not unconnected however it do not show the temperature... there are other problem somewhere... later I will contact RepSnapper devs on IRC channel. I can understand the Java code of RepRap software but the C(C++ ??) code of RepSnapper is hard for me to understand.

Now I tested to run the X axis motor and I got a very low velocity... I need to have a bit more time to debug it but I saw that setTimer() is getting very high values...

Edited 1 time(s). Last edit at 11/06/2010 11:15AM by casainho.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

Finally the code works :-) -- I need further tests like trying to print and put PID working for extruder.

First boards may be shipped with this ""FiveD on Arduino" on ARM" firmware code but after I may go back to C++ official RepRap firmware code, because it already supports more than 1 extruder and is what I am looking for. Also I was thinking in trying to support RepRap host and other softwares like RepSnapper but I found that RepSnapper is not ready yet for more than 1 extruder...

While Atmel AVR core used on Arduino do not support multiply and division, the ARM core I am using support them: "hardware division, single cycle multiply". So I guess is not big advantage on using "FiveD on Arduino" for my case (at least for now while I do not grow for a more complex application).

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

Hi all,

I've pushed a ton of patches to my release-candidate-triffid branch, including the exciting multi temp and unified timer algorithms, a start on gen3 out-of-the-box configuration options, an implementation of a temporal step algorithm for experimenting, and about as much work as I can do on atmega1280 compatibility without having one. I've done just enough testing to see the motors working and the heater tracking a target temperature.

I don't want to commit anything to release-candidate that hasn't been thoroughly tested by a few different people on a few different setups - on this score I need help! bugs? regressions? comments on new features? better ways to do things?

---

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

Hi

I am a bit github challenged. Would you please post a link to the release candidate. I have a Mega pololu with thermistor on extruder and bed. If 5DA has the capability to support this configuration I will hopefully find some time to try it out.

Edited 1 time(s). Last edit at 11/09/2010 10:02AM by emt.

---

Regards

Ian

Quote

on this score I need help!

I'll happily help soon again. Currently I'm working on another piece of software: [sourceforge.net] , but that should be done by the end of the week.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

emt Wrote:
-------------------------------------------------------
> Hi
>
> I am a bit github challenged. Would you please
> post a link to the release candidate. I have a
> Mega pololu with thermistor on extruder and bed.
> If 5DA has the capability to support this
> configuration I will hopefully find some time to
> try it out.

git clone git://github.com/triffid/FiveD_on_Arduino.git
cd FiveD_on_Arduino
git branch -r
git checkout release-candidate-triffid
cp config.h.dist config.h

now read README, edit config.h and Makefile to suit your setup, then

make
make program

Some of my recent patches have been attempts to make things easier to configure for people unfamiliar with this firmware, please tell me how you go.

PID tuning is still a bit rough, you need to compile with debug flag and use a serial terminal (func.sh has one), then M111 S1, set a target temperature and play with the M13* commands (gcode_process.c) until it looks good, or reset if temp runs away. I will try to make this easier soon.

---

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

Hi Triffid

Thanks.

I installed git and got the files on a windows PC.

I assume you can no longer use the Arduino IDE ( my only experience of microcontrollers to date) so I am now going through the same process on a Ubuntu PC.

I think I understand most of the config.h apart from this section:-

#ifdef TEMP_C
struct {
uint8_t temp_type;
uint8_t temp_pin;

uint8_t heater_index;
} temp_sensors[NUM_TEMP_SENSORS] =
{
{
TT_INTERCOM,
0,
0
}
};
#endif

I am using a thermistor so I have #define TEMP_THERMISTOR

What do I put in for temp_type?


Also am I correct in understanding it will only support an extruder heater and not a bed heater in the current version?

---

Regards

Ian

Ian, if you're seeing that particular code block in the config, then you have a version that supports as many temperature sensors and heaters as pins and memory allow!

The temp type is TT_THERMISTOR, the pin is simply a number, or you can use PINA5 or similar, and the heater index specifies an associated heater from the similar heater array below. List as many as you have

see temp.c for how the values are used.

---

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

Hi

Well you asked for comments.

As normally a Windows user this has been an adventure.

I am using Ubuntu 10.04 LTS

I first had to install Arduino using GIT.

Then build it with ant which meant I had to install ant and then a Java JDK of the correct flavour.

This took a while to figure out with a lot of false steps but eventually all done and Arduino works.

Next was the 5DA make.

That worked without reported errors.

Then make program.

That failed as it could not locate arduino .

I changed the make file to the correct directory.

Now I get this error which I do not know how to over come.

ian@ian-laptop:~/FiveD_on_Arduino$ make program
stty 57600 raw ignbrk hup < /home/ian/Arduino
stty: standard input: Inappropriate ioctl for device
make: *** [program] Error 1
ian@ian-laptop:~/FiveD_on_Arduino$

---

Regards

Ian

> ian@ian-laptop:~/FiveD_on_Arduino$ make program
> stty 57600 raw ignbrk hup < /home/ian/Arduino
> stty: standard input: Inappropriate ioctl for
> device
> make: *** Error 1
> ian@ian-laptop:~/FiveD_on_Arduino$

That piece of code seems to be trying to program the AVR/Arduino! The bin/hex file maybe went build ok already.

The problem may be because as root you can write/read the serial port. Maybe if you do "sudo make program" it will work. Or even try to execute the line that programs with sudo: "sudo stty 57600 raw ignbrk hup < /home/ian/Arduino".

Hey, welcome to Linux ;-)

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

stty and friends want to talk to a serial port. "inappropriate ioctl for device" basically means it tried to do something that works on serial ports on something that isn't a serial port. is /home/ian/Arduino a serial port (or a symlink to one)? You may want to replace with /dev/ttyUSB0 or whichever port is your arduino.

---

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

For me everything works fine without these stty calls. That's Ubuntu 10.04 AMD64 using the autogenerated USB device.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

OK

Well I spent Friday afternoon lost in Linux.

However after a lot of reading and learning I have now got 5DA compiling and uploading to my Mega using the make commands.

I now need to understand the config files.

More immediately I changed some of the files and I had to revert to the originals (I have now set my editor to version backup so it should not happen again).

I did this by deleting my local 5DA directory and going through the git process from scratch which does not seem the best way to operate.

What are the git command for:-

1) keeping your local copy up to date with any files that have been updated on the server.

2) pulling down a complete new set of files overwriting any changes you may have made locally if you need to start from scratch.

---

Regards

Ian

I am nearing completion of my Mcwire cartesian bot and have been using this firmware to test so far. I have been using the release-candidate branch to date as it is the only one I can get to compile in the Arduino IDE. I have tried a few times to compile this firmware using make with winavr on windows and on my Debian machine with no luck. Most recently I have tried release-candidate-triffid and have found make completes without errors if I do not edit the makefile. However as soon as I set MCU_TARGET = atmega168 and PROGBAUD = 19200 I get a string of errors about undeclared pins in 'io_init'.

Here is the output:

spaz@Lab:~/Desktop/triffid-FiveD_on_Arduino-3b63269$ make
CC mendel.o
mendel.c: In function ‘io_init’:
mendel.c:36: error: ‘DIO15_WPORT’ undeclared (first use in this function)
mendel.c:36: error: (Each undeclared identifier is reported only once
mendel.c:36: error: for each function it appears in.)
mendel.c:36: error: ‘DIO15_PIN’ undeclared (first use in this function)
mendel.c:36: error: ‘DIO15_DDR’ undeclared (first use in this function)
mendel.c:37: error: ‘DIO18_WPORT’ undeclared (first use in this function)
mendel.c:37: error: ‘DIO18_PIN’ undeclared (first use in this function)
mendel.c:37: error: ‘DIO18_DDR’ undeclared (first use in this function)
mendel.c:38: error: ‘DIO20_WPORT’ undeclared (first use in this function)
mendel.c:38: error: ‘DIO20_PIN’ undeclared (first use in this function)
mendel.c:38: error: ‘DIO20_DDR’ undeclared (first use in this function)
mendel.c:40: error: ‘DIO21_WPORT’ undeclared (first use in this function)
mendel.c:40: error: ‘DIO21_PIN’ undeclared (first use in this function)
mendel.c:40: error: ‘DIO21_DDR’ undeclared (first use in this function)
mendel.c:43: error: ‘DIO19_WPORT’ undeclared (first use in this function)
mendel.c:43: error: ‘DIO19_PIN’ undeclared (first use in this function)
mendel.c:43: error: ‘DIO19_DDR’ undeclared (first use in this function)
mendel.c:46: error: ‘DIO23_WPORT’ undeclared (first use in this function)
mendel.c:46: error: ‘DIO23_PIN’ undeclared (first use in this function)
mendel.c:46: error: ‘DIO23_DDR’ undeclared (first use in this function)
mendel.c:47: error: ‘DIO22_WPORT’ undeclared (first use in this function)
mendel.c:47: error: ‘DIO22_PIN’ undeclared (first use in this function)
mendel.c:47: error: ‘DIO22_DDR’ undeclared (first use in this function)
mendel.c:48: error: ‘AIO6_WPORT’ undeclared (first use in this function)
mendel.c:48: error: ‘AIO6_PIN’ undeclared (first use in this function)
mendel.c:48: error: ‘AIO6_DDR’ undeclared (first use in this function)
mendel.c:66: error: ‘DIO16_WPORT’ undeclared (first use in this function)
mendel.c:66: error: ‘DIO16_PIN’ undeclared (first use in this function)
mendel.c:66: error: ‘DIO16_DDR’ undeclared (first use in this function)
mendel.c:67: error: ‘DIO17_WPORT’ undeclared (first use in this function)
mendel.c:67: error: ‘DIO17_PIN’ undeclared (first use in this function)
mendel.c:67: error: ‘DIO17_DDR’ undeclared (first use in this function)
make: *** [mendel.o] Error 1

I have attached my makefile and config.h for more information as these are the only two files I have modified.

As for the config.h, I am not completely certain how to configure this for my set up. I assume that because I am not using official Gen3 electronics that I should comment out #define gen3 and #define host. Also I have changed a number of setting with regard to temp sensor from TEMP_INTERCOM to TEMP_THERMISTOR. This is all likely moot as I don't have a heater and or thermistor connected yet. I did notice it seems TEMP_PIN_CHANNEL and X_STEP_PIN are both set pin AIO0 so I moved X_STEP_PIN, X_DIR_PIN and X_MIN_PIN to DIO10, DIO11 and DIO12 respectively. Is this right or am I missing something.

I read a few posts back that end stops are not yet implemented. In the mean time would it be possible have a more sane interpretation of G28 (home command), perhaps instead of going off in search of end stops it will never find the machine could just return to 0,0,0. It seems to me that end stops are not required for general operation of the machine and really only come into play when G28 is received. It might even be good enough to have the machine search out the end stops on power up then set that position to 0,0,0 and return to 0,0,0 anytime G28 is received. I am not sure I am just brainstorming here.

Finally I would like to thank everyone who has contributed to this awesome project. I am glad to see not everyone has given up on the lowly arduino (and not just because it means I have to buy less hardware for my repstrap). I would also like to say that I am willing and eager to aid in testing this firmware, unfortunately I will not be a great help when it comes to actually coding it though.

Edited 1 time(s). Last edit at 11/13/2010 07:40PM by spaztik.

spaztik Wrote:
-------------------------------------------------------
> Most recently I have tried
> release-candidate-triffid and have found make
> completes without errors if I do not edit the
> makefile. However as soon as I set MCU_TARGET =
> atmega168 and PROGBAUD = 19200 I get a string of
> errors about undeclared pins in 'io_init'.

This happens if you leave 'GEN3' defined, as the GEN3 electronics use pins (and uarts) that don't exist on a '168. I think it's defined both in the Makefile and in config.h at the moment- I probably should fix that.

> As for the config.h, I am not completely certain
> how to configure this for my set up. I assume that
> because I am not using official Gen3 electronics
> that I should comment out #define gen3 and #define
> host. Also I have changed a number of setting with
> regard to temp sensor from TEMP_INTERCOM to
> TEMP_THERMISTOR. This is all likely moot as I
> don't have a heater and or thermistor connected
> yet. I did notice it seems TEMP_PIN_CHANNEL and
> X_STEP_PIN are both set pin AIO0 so I moved
> X_STEP_PIN, X_DIR_PIN and X_MIN_PIN to DIO10,
> DIO11 and DIO12 respectively. Is this right or am
> I missing something.

sounds fine to me. My electronics are completely custom too, and so are traumflug's afaik. The gen3 support came from jakepoz wanting to use this on normal electronics!

you can leave HOST defined, just remove GEN3 (and check makefile too) if you don't have a separate extruder controller at the other end of a uart.

> I read a few posts back that end stops are not yet
> implemented. In the mean time would it be possible
> have a more sane interpretation of G28 (home
> command), perhaps instead of going off in search
> of end stops it will never find the machine could
> just return to 0,0,0. It seems to me that end
> stops are not required for general operation of
> the machine and really only come into play when
> G28 is received. It might even be good enough to
> have the machine search out the end stops on power
> up then set that position to 0,0,0 and return to
> 0,0,0 anytime G28 is received. I am not sure I am
> just brainstorming here.

end stops have an implementation, but it's commented out by default as no-one has tested it (let alone reported it working). have a look at dda_step() [dda.c] lines 492, 507, 522.

I think those who have printed with this do their homing manually- position is zero coming out of reset, so if you remove the G28 from your files and print when the head is at a suitable position, you may be ok.

> Finally I would like to thank everyone who has
> contributed to this awesome project. I am glad to
> see not everyone has given up on the lowly arduino
> (and not just because it means I have to buy less
> hardware for my repstrap). I would also like to
> say that I am willing and eager to aid in testing
> this firmware, unfortunately I will not be a great
> help when it comes to actually coding it though.

you're most welcome! All help is appreciated, and you may learn some code artistry on the way As it is, you're already pointing out things that must be made clearer and easier before we can do a release.

---

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

Quote

1) keeping your local copy up to date with any files that have been updated on the server.

git pull

Quote

2) pulling down a complete new set of files overwriting any changes you may have made locally if you need to start from scratch.

As you have a copy of the whole repository local, in the .git directory, there's no nee to "pull down" anything. To revert all modifications, do in your project directory:

rm *
git checkout .

Yes, there's a "rm *", so take care to not accidently type this in your home directory. Without it, all git-tracked files get reverted as well, but the non-tracked ones, e.g. config.h, stay intact.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Markus

Many thanks, I am beginning to see how git works.

---

Regards

Ian