Project: Teacup Firmware

Quote
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.

Thanks that worked. I am now able to make and make program without errors. However when I try to run ./sender.sh I get these errors:

./sender.sh: line 6: waitfor: command not found
./sender.sh: line 10: read: 0.1: invalid timeout specification

I think I don't have the correct software packages installed but I have no idea which package to install to get the command waitfor. I am running Debian Lenny btw.

Triffid_Hunter Wrote:
-------------------------------------------------------
> spaztik Wrote:
> --------------------------------------------------

> > 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() 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.


That should work. We really should get a working endstop implementation though. One problem which nophead pointed out is that if the endstops aren't utterly, completely, and totally reliable, you'll get skipped steps during a print if they're tested when printing. Since the endstop wiring shares space with stepper wiring (which is high current, high switching frequency - i.e. very, very noisy) it's easy to get getting momentary false positives on the endstops, which looks like missed steps b/c the stepper doesn't move but the position is still updated. It's updated every step in mainline firmware, and at the end of each move in this firmware.

Much worse, as I found out, unlike the standard firmware, this firmware will often stop a move in the middle if the endstops are noisy. Since location is updated at the end of a move even for improperly aborted moves, this results in the position being WAY off. The standard firmware will skip steps (and get off postion) when an endstop gives a momentary false positive, and a skipped step or two probably won't completely ruin a print. This firmware will (currently, if endstop testing is un-commented) get much, much farther off, and will almost certainly completely ruin the print and possibly crash the head.

It's aborting because it's testing for "did we step" to see if a move is finished, rather than "could we have stepped if the endstops weren't interfering" which the standard fimware does. Obviously, my endstops are giving occasional false positives. I've got some 18/2 shielded that I've decided to replace the endstop wiring with...

The point being that the current implementation is broken. Who wants to end up with a failed print because you didn't know that when you run the dishwasher (on the same circuit in your house) the endstops occasionally (every ten minutes or so) give a false positive? Better to ignore endstops while actually printing, and use them solely as a "reset hardware to known position" asset.

It would be better to ignore the endstops when printing, only using them to rezero when specifically requested to do so.

Nophead's implementation of this is a completely separate homing loop. I don't know if that's really the way to go or not. Wouldn't be too difficult to implement. One problem with that approach is that it (somewhat) breaks the "set home position" (G92) I.E. If "go home" (G28) is replaced with "seek endstops" then it stops working as expected after G92 is issued.

I think that the correct implementation is a separate "max speed" loop to go home seeking the endstops, with a flag set when G92 is received which changes G28's behavior to "go to 0,0,0" instead of "seek endstops". With a separate M-code assigned for "seek endstops" so that functionality is still available for those who wish to use it in combination with "set home position." We would have to record the absolute position when "set home" was done, and reset the relative position correctly after seeking is finished.

That way existing implementations (skeinforge and reprap host, to name two) that expect "go home" (G28) to actually do a "seek endstops and reset position to 0,0,0" would still work as expected, code that expects "go home" to actually "go home" would still work as expected, and code that's aware of the distinction can ask for either or both as appropriate.

No, I don't have a (working) patch to do this. I DO have a non-working patch that takes a completely wrong approach to fixing this endstop bug. That's why I have an opinion on "how I should have done it." If left to my own devices, I might eventually submit a patch that does all this correctly, but right now I've got to get my cold end working properly, and replace the wiring on my endstops, and build my hot end, and calibrate for printing.

---

--
I'm building it with Baling Wire

jgilmore Wrote:
>
> That should work. We really should get a working
> endstop implementation though. One problem which
> nophead pointed out is that if the endstops aren't
> utterly, completely, and totally reliable, you'll
> get skipped steps during a print if they're tested
> when printing. Since the endstop wiring shares
> space with stepper wiring (which is high current,
> high switching frequency - i.e. very, very noisy)
> it's easy to get getting momentary false positives
> on the endstops, which looks like missed steps b/c
> the stepper doesn't move but the position is still
> updated. It's updated every step in mainline
> firmware, and at the end of each move in this
> firmware.

What endstops are you using? H21LOB? -- I am using that ones and I didn't know about that problem you talk about.

Nice to know this problems... I am using right now this code on dda_step():

if ((current_position.X != dda->endpoint.X) && (x_min() != dda->x_direction)) {

I will test tomorrow and see if I get any problems, of movement. Also I will look on signal using oscilloscope.

---

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

[www.3dprinting-r2c2.com]

From a physical point of view, there are a number of ways to reduce noise on the endstops:

* Make sure current is always flowing - Basically pull-up and pull-down resistors, so that no matter what the state of the opto, current flows. This means you need to choose the values carefully to keep a residual current but allow switching levels to be clean. You also have to avoid burning out the opto transistor. I don't believe the values in the current optos or board implementations were worked out to really avoid this situation, and were simply chosen as "they should be suitable values".
* Schmitt trigger inputs - avoids false triggers.
* Avoid running opto signals next to motor signals - Cuts down the inducement of current.
* Ground any spare wires - Acts a bit like shielding, and avoids induced currents in those wires inducing current elsewhere. Grounding the steel rods the wire is run along is also doable and potentially viable.
* Shielding - Use of shielded cable helps immensely.
* Properly tie down any unused opto inputs - Even small traces on a board can get an induced current, especially if they're near motor drivers.

From a software side, multiple sampling should help.

Basically: If you see an endstop trigger during a move, STOP. Then check the endstops again (a few ms afterwards). if they're clear, resume movement. If not, then you've actually hit an endstop, react accordingly. Effectively using multi-sampling to re-create a Schmitt trigger like arrangement.

It'll be juddery if your endstops are noisy, but it should avoid random endstop noise completely ruining a print. It could even be recorded in the firmware and reported back (eg: number of false endstop detections), which lets people know they should do something about their endstops (eg: shielding).

spaztik Wrote:
-------------------------------------------------------
> Thanks that worked. I am now able to make and make
> program without errors. However when I try to run
> ./sender.sh I get these errors:
>
> ./sender.sh: line 6: waitfor: command not found
> ./sender.sh: line 10: read: 0.1: invalid timeout
> specification
>
> I think I don't have the correct software packages
> installed but I have no idea which package to
> install to get the command waitfor. I am running
> Debian Lenny btw.

try

( cat <&3 & cat >&3; kill %! ; ) 3<>/dev/arduino

for a super simple talker. set port up with stty first, see func.sh for more thoroughly tested examples

If you enable xon/xoff flow control, you can paste rather large chunks of gcode in and it won't miss any

---

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

another way to make the endstops more reliable is to put a buffer at the end-stop end of the cable. That way, the signal wire can have a low impedance at both ends. suitable capacitors will lessen motor noise while still allowing signal to get through.

As far as firmware goes, jgilmore thanks for the in-depth exploration of end-stops and related issues. I think moving the end-stop check out of dda_step and into the main loop is a great idea. that will also make adding counters for spurious signal rejection easier.

One of the patches I want to make soon is some way to keep the main loop spinning without accepting new characters from the host. There are a couple of ways to do this, and I haven't decided which I like the best. There are a few functions which would use this feature, dwell and wait-for-temp to name just a couple. If the end-stops are checked in this loop, we could simply spin it really fast when homing as a very simple implementation of what you suggest.

---

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

Triffid_Hunter Wrote:
-------------------------------------------------------
> try ( cat <&3 & cat >&3; kill %! ; )
> 3<>/dev/arduino for a super simple talker. set
> port up with stty first, see func.sh for more
> thoroughly tested examples
>
> If you enable xon/xoff flow control, you can paste
> rather large chunks of gcode in and it won't miss
> any

Oh, sender.sh is a host side talker, for some reason I thought it was what sent the code to the arduino. I realized late last night that in fact "make program" is what actually programs the arduino (seems obvious in retrospect), but was still unsure what sender.sh did. Unfortunately I made this discovery because after I plugged in my arduino I started getting errors when I would run "make program". Previously I had been trying to get "make" and "make program" to run without the arduino attached because I did not have linux box next to my repstrap. Anyway, the errors I get now are these:

avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.

I found this bug report which seems to be about the same or similar issue. The odd thing is the bug report says the issue occurs on avrdude versions 5.7 and 5.8, and it was closed as the trouble seemed to "clear up" in later versions. I have tried this on Debian Lenny (avrdude ver. 5.5) and Debian Squeeze (avrdude ver. 5.10) on both my Boarduino (which is connected to my repstrap) and an Arduino Diecimila I had kicking around. Both of these boards I can program without issue using the Arduino IDE. I get a different error when I try to run avrdude from Windows. Something about it not being in sync.

I will probobaly try using the -F option to force avrdude next but I suspect that will just cause a verification error as is seen in the bug report linked earlier.

I realize this is getting to the point that I should be posting on the avrdude forum or maybe the arduino one but I figured I'd try here first and see if anyone can give me some ideas.

P.S. As I write this I am not at my computer so I cannot verify the output that I have posted. When I get home I will double check this post and correct or add as needed.

Hello
I'm trying to use FiveD for Arduino with an repstrap with arduino
- steppers motors drivers V1
- extruder stepper
- without endstops

under Ubuntu Lucid

I modify the code in config.h and dda.c to avoid endstops

but :
1 - I can't compile under arduino 0018 (or more recent) because can't find "sys/time.h"
2- So I compile it with succes with avrdude BUT
replicatorg0013 say everytime 'machine reset called'
but a can open controlpanel and move the machine.

replicatorg0017 seems don't understand messages from machine :
[17:54:36] Initializing Serial.
[17:54:36] Unknown: Start
[17:54:36] Ready.

but can't open control pannel


I've several questions about config.h :
- there are reserved pins : does the A9 & A10 are ?
- can I use pins 10 to 13 if I use a thermistor instead of MAX6675 ?


anybody can help me ?

cdriko Wrote:
-------------------------------------------------------
> 1 - I can't compile under arduino 0018 (or more
> recent) because can't find "sys/time.h"

The only branch I have successfully compiled with the arduino IDE is "release-candidate"

> 2- So I compile it with succes with avrdude BUT
> replicatorg0013 say everytime 'machine reset
> called'
> but a can open controlpanel and move the machine.
>
> replicatorg0017 seems don't understand messages
> from machine :
> [17:54:36] Initializing Serial.
> [17:54:36] Unknown: Start
> [17:54:36] Ready.
>
> but can't open control pannel

Try the "release-candidate-triffid" branch as it seems the most recent development has been in this branch lately.

> - can I use pins 10 to 13 if I use a thermistor
> instead of MAX6675 ?

I am using those pins (10-13) for my x-axis. I commented out the max6675 pins when I was using the "release-candidate" branch but those pins seem to be unused in the "release-candidate-triffid" branch.

spaztik Wrote:
-------------------------------------------------------

> Anyway, the errors I get now
> are these:
>
> avrdude: Device signature = 0x000000
> avrdude: Yikes! Invalid device signature.
...

> I will probobaly try using the -F option to force
> avrdude next but I suspect that will just cause a
> verification error as is seen in the bug report
> linked earlier.

So, forcing avrdude worked. I just re-ran the avrdude line with a -F, like this

avrdude -cstk500v1 -F -b19200 -patmega168 -P/dev/ttyUSB0 -C/etc/avrdude.conf -U flash:w:mendel.hex config.h

in case anyone else runs into this problem.

Guys

I think you have probably done the opto end stop thing to death.

I agree that the best way is to add a bit of signal processing at the end stop, end (Buffer, emitter follower or what ever) and drive the line harder.

It can also be filtered (Pi filter) with a couple of small value caps and an inductor.

However......

Cheapest and simplest route is to throw out the opto end stops and use micro switches. Yes they do bounce but you can use a very simple capacitor resistor de-bounce circuit (Hardware) or look once on a change over then look again in a couple of milliseconds to see what it stabilized at (Software).

Yeah I know they are old and low tech but work. (there's plenty available on the surplus market too).

A simple explanation of de-bouncing can be found here :-

[www.all-electric.com]

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I was thinking something more like this. I haven't used the "SEARCH_FEEDRATE" stuff here yet. And I haven't gotten into other things that might be going on - watchdog, a/d conversions, temp ticks, etc. Also doesn't work if you happen to have MAX endstops instead of MIN endstops on some axises. (I have a MAX on my Z, but no MIN. X and Y have MIN, I think. I'll have to double-check the handedness of my hardware at some point here.

I haven't tested this at all as my endstops are unreliable, but I think it's at least a half-decent first stab.

From what I hear you saying it should work to put together a generic "tick" or "update_stuff" function which does things like watchdog & temp updates etc, and which doesn't care how often it's called as long as it's called often enough. Call it in the main loop, and wherever else we're looping, like this hit_endstops function, dwell, etc. Is that the kind of thing you where thinking about?

---

--
I'm building it with Baling Wire

aka47 Wrote:
-------------------------------------------------------
> Cheapest and simplest route is to throw out the
> opto end stops and use micro switches.

Uhm, actually that's what I'm using, and getting false positives on. It's a matter of the endstops being located next to the motor in all cases, and the wiring running along the motor wiring out to where the motor is. Makes for plenty of interference, which I didn't notice until I started using this firmware and uncommented the endstop code.

The right answer in my case is to fix the hardware. And I have some 18/2 shielded in my copper pile that I plan to use for just that purpose. But that doesn't mean that the firmware shouldn't be much more robust too.

---

--
I'm building it with Baling Wire

Yes I get false positives from normally closed micro switches that connect the input to ground if I run them next to stepper motor wires. So no amount of buffering is going to fix it, it would need shielding and / or filtering. As I only use them in a homing loop I simply wait a little and if not still at the home position I home again. For the sake of simplicity I don't de-bounce them as the only effect of the false positive is a few milliseconds pause in my homing sequence.

There is only any need to monitor in the dda loop if the machine will damage itself if it bangs into the endstop (but then it should be done entirely in fail safe hardware). If not then it is more reliable to ignore them after homing.

---

[www.hydraraptor.blogspot.com]

Hello

as I said before, i'm working a reprap
- steppers motors drivers V1
- extruder stepper
- without endstops
- arduino 328

I success to connect to it with the ReplicatorG-5Dsupport of ErikDeBruijn

with little modifications :
- in serial.c
#define BUFSIZE 64
(to corresponds to RepRap5DDriver.java)

- in mendel.c
serial_writestr_P(PSTR("start\nok\n"));
(instead "Start" that's not recognised by replicatorg)


At this state, I success to connect to the machine !
But
- only X and Z motors works with the control panel

- the temp is everytime at zero

About the temp, when the controlpanel is open, replicatorg send :
"Sent: T0 M105" 16 times
and AFTER, the machine responds :
"18 nov. 2010 15:53:46 replicatorg.drivers.RepRap5DDriver readResponse
INFO: T: 0.0
18 nov. 2010 15:53:46 replicatorg.drivers.RepRap5DDriver readResponse
GRAVE: Unknown: T: 0.0"

16 times too

I'll try to find a queue somewhere

I've a question about the pins :
on the stepperdriverV1 there are 3 connectors :
STEP
DIR
ENABLE

in config.h
there are only STEP and DIR pins
or the STEPPER_ENABLE_PIN is for all the steppers ?

My port of this firmware to ARM Cortex-M3 LPC1768 is almost working. X, Y and Z axis are working correctly. E (extruder) axis gives problems and I found that are overflow of 32bits variables like int32_t current_position.E.

There are other problems like because code looks to simple (maybe because the limitations of Arduino program memory??), for example in the implementation of G92 (set home) is not complete for each axis, and so I get G92 E0 from Skeinforge at end of each layer and that makes real problems on printing, because it sets home for all the axis :-)

Right now I am trying to deal with E axis problems and I hope soon be able to print and right after sharing my code.

JTAG debugger is being really valuable on finding bugs and test the code.

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

---

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

[www.3dprinting-r2c2.com]

cdriko Wrote:
-------------------------------------------------------

> I success to connect to it with the
> ReplicatorG-5Dsupport of ErikDeBruijn
>
> with little modifications :
> - in serial.c
> #define BUFSIZE 64
> (to corresponds to RepRap5DDriver.java)
>
> - in mendel.c
> serial_writestr_P(PSTR("start\nok\n"));
> (instead "Start" that's not recognised by
> replicatorg)

I wonder if this will help with connecting to repsnapper? Currently all connection attempts time out. Gcodes are received and executed in the time between when you hit the connect button and when the connection attempt times out, though. I will test.

> - only X and Z motors works with the control
> panel

I get this trouble too when using the release-candidate-triffid branch. The best I get is 2-3 steps, but usually no movement at all, no matter what gcodes I send to move the y axis. I have switched back to the master branch which doesn't seem to have this trouble.

> in config.h
> there are only STEP and DIR pins
> or the STEPPER_ENABLE_PIN is for all the steppers
> ?

I believe there is only one STEPPER_ENABLE_PIN for all steppers. Someone please correct if I am mistaken.

I used repsnapper to generate some gcode from an .stl file. The resulting gcode had four decimal positions and no ;s at the end of the lines. When I ran some of this gcode it caused erratic behavior. The axis crashed into the (mechanical) end stops and some of the positions returned by m114 were negative, despite all the moves being in the positive direction. When I removed the fourth decimal positions and added ;s the gcode seemed to run properly. I think the trouble is with the decimal positions as I have manually run many gcodes without ;s and had no trouble. I will need to do more testing to be sure what the trouble is.

Is the position returned by the m114 command in number of steps? If so, is this correct or should it return position in mm or inches depending on which units you are using?

spaztik Wrote:
-------------------------------------------------------
> cdriko Wrote:
> --------------------------------------------------
> -----
>
> > I success to connect to it with the
> > ReplicatorG-5Dsupport of ErikDeBruijn
> >
> > with little modifications :
> > - in serial.c
> > #define BUFSIZE 64
> > (to corresponds to RepRap5DDriver.java)
> >
> > - in mendel.c
> > serial_writestr_P(PSTR("start\nok\n"));
> > (instead "Start" that's not recognised by
> > replicatorg)
>
> I wonder if this will help with connecting to
> repsnapper? Currently all connection attempts time
> out.

I can now use RepSnapper to control my board. The problem is the incorrect format of M105 answer -- I wrote before about it and my solution :-)

---

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

[www.3dprinting-r2c2.com]

Quote
spaztik
Is the position returned by the m114 command in number of steps? If so, is this correct or should it return position in mm or inches depending on which units you are using?

I don't have any return with talking to the arduino via the serail console
even setting the XONXOFF

casainho Wrote:
-------------------------------------------------------
> There are other problems like because code looks
> to simple (maybe because the limitations of
> Arduino program memory??), for example in the
> implementation of G92 (set home) is not complete
> for each axis, and so I get G92 E0 from Skeinforge
> at end of each layer and that makes real problems
> on printing, because it sets home for all the axis
> :-)

You are correct about the normal implementation - you can even specify something other than 0! I'm surprised, and this makes my implementation of endstops incorrect, and the implementation of the G28 command always incorrect. We should have a special M-code for re-zeroing from the endstops instead of borrowing the go home command. (Say, then we could return the error amount as well, that'd be nice...)

---

--
I'm building it with Baling Wire

jgilmore Wrote:
-------------------------------------------------------
> casainho Wrote:
> --------------------------------------------------
> -----
> > There are other problems like because code
> looks
> > to simple (maybe because the limitations of
> > Arduino program memory??), for example in the
> > implementation of G92 (set home) is not
> complete
> > for each axis, and so I get G92 E0 from
> Skeinforge
> > at end of each layer and that makes real
> problems
> > on printing, because it sets home for all the
> axis
> > :-)
>
> You are correct about the normal implementation -
> you can even specify something other than 0! I'm
> surprised, and this makes my implementation of
> endstops incorrect, and the implementation of the
> G28 command always incorrect. We should have a
> special M-code for re-zeroing from the endstops
> instead of borrowing the go home command. (Say,
> then we could return the error amount as well,
> that'd be nice...)

My ARM Cortex M3 board now seems to print well - I just can't put on the Wade extruder the PLA because extruder hot end is jammed :-( -- I am now taking care of it...

My implementation of G28 and G92 that are working:

                          // G28 - go home
                          case 28:
                          if (next_target.seen_X)
                          {
                            zero_x();
                            axisSelected = 1;
                          }

                          if (next_target.seen_Y)
                          {
                            zero_y();
                            axisSelected = 1;
                          }

                          if (next_target.seen_Z)
                          {
                            zero_z();
                            axisSelected = 1;
                          }

                          if (next_target.seen_E)
                          {
                            zero_e();
                            axisSelected = 1;
                          }

			  if(!axisSelected)
			  {
			    zero_x();
			    zero_y();
			    zero_z();
			  }

                          startpoint.F = SEARCH_FEEDRATE_X;
                          break;

                          // G92 - set home
                          case 92:
                          /* wait for queue (all movements) to complete */
                          for (;queue_empty() == 0 {}

                          if (next_target.seen_X)
                          {
                            startpoint.X = current_position.X = 0;
                            axisSelected = 1;
                          }

                          if (next_target.seen_Y)
                          {
                            startpoint.Y = current_position.Y = 0;
                            axisSelected = 1;
                          }

                          if (next_target.seen_Z)
                          {
                            startpoint.Z = current_position.Z = 0;
                            axisSelected = 1;
                          }

                          if (next_target.seen_E)
                          {
                            startpoint.E = current_position.E = 0;
                            axisSelected = 1;
                          }

                          if(!axisSelected)
                          {
                            startpoint.X = current_position.X = \
                            startpoint.Y = current_position.Y = \
                            startpoint.Z = current_position.Z = \
                            startpoint.E = current_position.E = 0;
                          }
                          break;

---

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

[www.3dprinting-r2c2.com]

cdriko Wrote:
-------------------------------------------------------
> > Is the position returned by the m114 command in
> number of steps? If so, is this correct or should
> it return position in mm or inches depending on
> which units you are using?
>
>
> I don't have any return with talking to the
> arduino via the serail console
> even setting the XONXOFF

No feedback at all? Not even "ok"s?

Here is some of the feedback I get from the firmware.

On start up (after aprox. 15-20 sec.);
Start
Ok

After each G or M code I send I get;
Ok

In response to m114 and m115 I get x,y,z, and e positions and feedrate and firmware version information respectively.
There are other commands that should return values as well like "get extruder temp" etc. I know that in the "release-candidate" tree the m114 and m115 commands are broken but It does return something as well as it respondes with "Ok" after each command.

I am not sure what is causing you not see this output, but I would suspect it has to do with settings in the terminal program. Do you see the commands that you type on the screen? If not try turning on local echo.

If you are running linux you could try running this command

stty raw ignbrk 115200 < /dev/ttyUSB0 ( cat <&3 & cat >&3; kill %%) 3<>/dev/ttyUSB0 - (Thanks for this triffid, it is great for debugging)

You should get output from this. Use ctrl-d to exit.

Edited 1 time(s). Last edit at 11/19/2010 02:09PM by spaztik.

casainho, I had no idea that the G28 and G92 were used for particular axes. I will add a patch soon

for those of you having trouble with axes, I pushed a new config.h.dist recently as the previous one was enabling the analog subsystem on some pins by default which may have been interfering. defining ANALOG_MASK as zero should have the same effect in your current firmware if that is indeed the issue.

spaztik, the gen3-compatible branches (such as my release-candidate-triffid branch) accept both a unified stepper enable/power pin and separate enables for each stepper. As I started with an atmega168, there simply weren't enough pins for a separate enable for each stepper! poor design decision on my part, now rectified to a certain extent.

---

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

Hi Triffid

thanks a lot.
In the arduino console : no responses, but
with your method : ok

here somme conversation :

Start
ok
G1 X4
ok
M114
ed checksum ok
M115
E: Bad M-code 115
ok
M105
 T: 0.0
ok
GO X7
ok
G1 Z4
ok

Finally my ARM Cortex-M3 board prints - and it uses the "FiveD on Arduino" firmware and many more tweaks I had to do to put it working.

I wanted to take some pictures of the prototype but I forgot my camera - I will do tomorrow.

Thanks everyone! -- I will share my code soon as possible and right now I wrote some info about the board I will commercialize: [reprap.org]

While debug the firmware using JTAG:




Edited 1 time(s). Last edit at 11/24/2010 08:04AM by casainho.

---

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

[www.3dprinting-r2c2.com]

Just a small update: I created a ReplicatorG patch to allow an uppercase "Start" to also work. It will probably take some time before it's integrated in the upstream version.

---

Regards,

Erik de Bruijn
[Ultimaker.com] - [blog.erikdebruijn.nl]

There is a bug on sersendf.c:

while ((c = format[i++])) {
  if (j) {
    switch(c) {
    case 'l':
    j = 4;

It should have a break, so for example sersendf(%ld, (uint32_t) counter); do works:

while ((c = format[i++])) {
  if (j) {
    switch(c) {
    case 'l':
    j = 4;
    break;

---

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

[www.3dprinting-r2c2.com]

Hello,
i'm new to reprap and i work on a repstrap powered with arduino 328, pwm driver 2.2, pololu stepper driver and thermistor.
This what i do to make my machine work on reprap software (release candidate):

The temperature output have an extra blank space (ok__T:=> ok_T: is good).
The "Start" is not good, i change it to "start".
After some headache with Y axis i figure that stepper on analog port is not a good choice (i didnt work at all). On digital port is goo.
One thing i can figure so help me please :
To use the thermistor i add this on gcode_parse:

case 104:
				temp_set(next_target.P, next_target.S);
				if (next_target.S) {
                                        enable_heater();<= id add this.
					power_on();
				}
				else {
					disable_heater();
				}
				break;

When in send a M104 S100 or M104 S0.7 the pwm start but never stop, temperature increase and increase. I have ton send M104 S0 to stop it.

my config:

#define	TEMP_THERMISTOR
#define	TEMP_PIN_CHANNEL	AIO0_PIN
#define	ANALOG_MASK				MASK(TEMP_PIN_CHANNEL)
#define	NUM_TEMP_SENSORS	1


#ifdef	TEMP_C
struct {
	uint8_t						temp_type;
	uint8_t						temp_pin;

	uint8_t						heater_index;
} temp_sensors[NUM_TEMP_SENSORS] =
{
	// type         pin heater
	{ TT_INTERCOM,  0,  1 }
};
#endif

#define	NUM_HEATERS				1

// #define	HEATER_SANITY_CHECK

#ifdef	HEATER_C
struct {
	volatile uint8_t	*heater_port;
	uint8_t						heater_pin;
	volatile uint8_t	*heater_pwm;
} heaters[NUM_HEATERS] =
{
	// port   pin    pwm
	{ &PORTD, PIND6, &OCR0A }
};

I use arduino IDE to compile on wondows. I install an unbuntu that's the same story (but on ubuntu you can't send command with arduino IDE).
And when i used DEBUG no output is send for M104.

Thanks and sorry for my bad english.

rataflo Wrote:
-------------------------------------------------------
> When in send a M104 S100 or M104 S0.7 the pwm
> start but never stop, temperature increase and
> increase. I have ton send M104 S0 to stop it.

Well, your code that manage the temperature is not working. Or it is reading wrong values of temperature or the PID control is not working.

With a debugger you would find the problem in 2 minutes.

---

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

[www.3dprinting-r2c2.com]

rataflo Wrote:
-------------------------------------------------------
> To use the thermistor i add this on gcode_parse:

> enable_heater();<= id add this.

if you need to add that for the heater to start, there's something wrong elsewhere. That command manually sets the heater pwm to a fixed value, bypassing closed loop temperature control.

You've set the heater index to 1, but you only have one heater at index 0, so the closed loop control will be disabled. Also, you've specified an 'intercom' type sensor instead of your thermistor. Your temp_sensors[NUM_TEMP_SENSORS] should look like { TT_THERMISTOR, AIO0_PIN, 0 }.

The 'intercom' type sensor is for when you have a separate extruder controller doing temperature sensing and closed loop control, ala gen3 electronics.

thanks for trying this firmware!

ps: your english is perfectly understandable

---

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