Project: Teacup Firmware

Thank you !!
I have to try this but i'm sure this is the good solution. I was thinking that NUM_HEATERS was the total number of heater and not the position in the array.
Your firmware is near perfect. The only thing left is the endstop.
Keep up the good job

rataflo Wrote:
-------------------------------------------------------
> I was thinking that NUM_HEATERS was the
> total number of heater and not the position in the
> array.

that's correct, however the heater_index value in the temperature sensor array is a (zero-based) index

---

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

I am also having trouble getting the the heater to work. I am currently running the release-candidate-triffid branch (commit 01b5c67) and I think I have everything configured correctly.

/***************************************************************************\
*                                                                           *
* 4. TEMPERATURE SENSORS                                                    *
*                                                                           *
\***************************************************************************/

/*
	TEMP_HYSTERESIS: actual temperature must be target +/- hysteresis before target temperature can be achieved.
	  NOTE: format is 30.2 fixed point, so value of 20 actually means +/- 5 degrees

	TEMP_RESIDENCY_TIME: actual temperature must be close to target for this long before target is achieved

	temperature is "achieved" for purposes of M109 and friends when actual temperature is within [hysteresis] of target for [residency] seconds
*/
#define	TEMP_HYSTERESIS				20
#define	TEMP_RESIDENCY_TIME		60

// which temperature sensors are you using? (intercom is the gen3-style separate extruder board)
// #define	TEMP_MAX6675
// #define	TEMP_THERMISTOR
// #define	TEMP_AD595
// #define	TEMP_PT100
#define	TEMP_THERMISTOR

// if you selected thermistor or AD595, what pin is it on? (this value only used to fill ANALOG_MASK for you)
#define	TEMP_PIN_CHANNEL	AIO0_PIN

// ANALOG_MASK is a bitmask of all analog channels used- if you use more than one analog input (more than one temp sensor?), bitwise-or them all together
#define	ANALOG_MASK				MASK(TEMP_PIN_CHANNEL)

// how many temperature sensors do you have?
#define	NUM_TEMP_SENSORS	1

/***************************************************************************\
*                                                                           *
* Fill in the following struct according to your hardware                   *
*                                                                           *
* If your temperature sensor has no associated heater, enter '255' as the   *
*   heater index. Unassociated temperature sensors are still read, but they *
*   do not affect firmware operation                                        *
*                                                                           *
* for GEN3 set temp_type to TT_INTERCOM, temp_pin to 0 and heater index to  *
*   255 - the extruder manages the heater for us                            *
*                                                                           *
* Types are same as TEMP_ list above- TT_MAX6675, TT_THERMISTOR, TT_AD595,  *
*   TT_PT100, TT_INTERCOM. See list in temp.c.                              *
*                                                                           *
\***************************************************************************/

#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_THERMISTOR,  0,  0 }
};
#endif



/***************************************************************************\
*                                                                           *
* 5. HEATERS                                                                *
*                                                                           *
\***************************************************************************/

// number of heaters- for GEN3, set to zero as extruder manages the heater by itself
#define	NUM_HEATERS				2

// check if heater responds to changes in target temperature, disable and spit errors if not
// #define	HEATER_SANITY_CHECK

/***************************************************************************\
*                                                                           *
* Fill in the following struct according to your hardware                   *
*                                                                           *
* If your heater isn't on a PWM-able pin, set heater_pwm to zero and we'll  *
*   use bang-bang output. Note that PID will still be used                  *
*                                                                           *
* If a heater isn't attached to a temperature sensor above, it can still be *
*   controlled by host but otherwise is ignored by firmware                 *
*                                                                           *
\***************************************************************************/

#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 },
	{ &PORTD, PIND5, &OCR0B }
};
#endif

The thermistor seems to work, it reads around 18 at room temp. (currently 22 deg C) and climbs to 27 when I hold the thermistor between my fingers. I just have a resistor and led connected to the heater pin (arduino pin D6). The led is always very dimly lit and there is .01v between the heater pin and ground. This never changes no matter what I set the heater temp to (eg. m104 s100).

The m115 command outputs this:

ok FIRMWARE_NAME:FiveD_on_Arduino FIRMWARE_URL:http1b.com/triffid/FiveD_on_Arduino/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:1 TEMP_SENSOR_COUNT:2 HEATER_COUNT:31236

You'll notice that the HEATER_COUNT is way off and no matter what I do it never changes. Also the TEMP_SENSOR_COUNT is incorrect. I only have one temp sensor defined but this number changes based on how many heaters I define.

I have also noticed that lately instead of "Start ok" on startup I get "Start ok" (the S and the symbol are actually overlapped in the output and only after pasting it here did I notice that the S is actually there).

I am under the impression that because I am using the 168 chip that I cannot enable debugging. Is this correct?

I have attached my entire config.h file in case there is more info the that might help.

Any help is appreciated
Thanks

Great to hear your thermistor is working! I haven't been able to test that code yet

thanks for pointing out that M115- I neglected to double the % in http%3A// so all the values are shifted left by one, and it reads past the end of the stack potentially smashing it. patch pushed.

I don't know what the character before Start would be, perhaps some noise from startup or something? strace may help you find out

The heater not working is vexing- your config looks exactly like mine which worked last time I checked. Unfortunately, my electronics are all packed away for moving house so I can't check on mine.

See what effect M135 (set heater) has.

Debug doesn't fit on the '168 because of all the extra text that goes into flash, and the extra code to wrangle it. Feel free to go through the code and manually enable any debug sections you think may be helpful- just pay close attention to the size table generated after compile.

---

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

Hey guys,

I have managed to get the triffid-release-candidate branch sort of running on my MEGA. Trouble I'm having is with pin assignments. It's probably down to my inexperience but if someone could point me in the right direction I'll be happy to look into the code some more.

It appears that if I assign any pin on PORTC (DIO30-DIO37) for my stepper signals, the moves are not executed correctly if at all. I can run the steppers on different pins but I've ordered a RAMPS board so I need to use the RAMPS pinout.

Any help is greatly appreciated.

#define X_STEP_PIN DIO26 //AIO0
#define X_DIR_PIN DIO28 //AIO1
#define X_MIN_PIN DIO3 //AIO2
#define X_ENABLE_PIN DIO24

#define Y_STEP_PIN DIO38 //AIO3
#define Y_DIR_PIN DIO40 //AIO4
#define Y_MIN_PIN DIO16 //AIO5
#define Y_ENABLE_PIN DIO36

#define Z_STEP_PIN DIO44 //DIO2
#define Z_DIR_PIN DIO46 //DIO3
#define Z_MIN_PIN DIO18 //DIO4
#define Z_ENABLE_PIN DIO42

#define E_STEP_PIN DIO32 //DIO7
#define E_DIR_PIN DIO34 //DIO8
#define E_ENABLE_PIN DIO30

---

[emaker.io]

[emaker.limited]

alternate function for port C is external memory interface, but SRE bit in XMCRA is zero on reboot. Perhaps the bootloader does something, and it must be manually zeroed? Add XMCRA = 0; in mendel.c io_init() somewhere and see what happens.

I can't think of any other reason that that particular port would misbehave, try some simpler programs to test it perhaps

---

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

I found it! analog system assumed that analog pins were on port C, but this is only true for 168/328.

Just pushed a patch to (hopefully) address this bug, release-candidate-triffid branch of course. Please test and tell me if it works!

---

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

Thanks for the response Triffid. I will try the m135 code tonight although I am not sure how to use it. I assume this sets which heater the m104 command sets the temp for. If so then I would try "m135 1" or "m135 2" for heaters 1 and 2 respectively or possibly "m135 0" and "m135 1", I'll try both. What are you using as reference for G and M codes? I have been looking here but it doesn't list m135.

Quote
I don't know what the character before Start would be, perhaps some noise from startup or something? strace may help you find out

Yes this is strange. I first noticed it in this post from cdriko and sure enough the next time I loaded a new version of the firmware it started happening to me. If this were caused by noise would it be so consistent? It happens every time and is always the same character. I would expect noise to be intermittent and not always the same character. I am not sure what strace is, but it sounds like I will be learning something new.

Quote
Feel free to go through the code and manually enable any debug sections you think may be helpful

Just to be certain, if I find a piece of debug code I would like to activate can I just comment out the "ifdef debug" before and the "endif" after?

Quote
It appears that if I assign any pin on PORTC (DIO30-DIO37) for my stepper signals, the moves are not executed correctly if at all.

I think I am having this problem too. I get maybe one or two steps but usually none on my y-axis no matter what position I send to it. I had mentioned it earlier in this post but thought maybe it had been fixed already, until I tried it again last night. My y-axis pins are defined as follows:

#define Y_STEP_PIN AIO3
#define Y_DIR_PIN AIO4
#define Y_MIN_PIN AIO5

I am not sure if these pins are on PORTC or not though (honestly I have no idea what PORTC means in relation to an arduino).

As I was writing this I noticed you have fixed it, I will test and report back.

spaztik Wrote:
-------------------------------------------------------
> Thanks for the response Triffid. I will try the
> m135 code tonight although I am not sure how to
> use it. I assume this sets which heater the m104
> command sets the temp for. If so then I would try
> "m135 1" or "m135 2" for heaters 1 and 2
> respectively or possibly "m135 0" and "m135 1",
> I'll try both. What are you using as reference for
> G and M codes? I have been looking here but it
> doesn't list m135.

From time to time, I need a code that isn't listed, so I pick an unused number. The code in gcode_process.c is all the documentation that exists for FiveD_on_Arduino's particular G/M code set.

> Just to be certain, if I find a piece of debug
> code I would like to activate can I just comment
> out the "ifdef debug" before and the "endif"
> after?

Yep that should work fine

---

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

Thanks triffid, I'll try that later.

spaztik: PORTC is digital IO pins 30-37 on the MEGA, see diagram attached.

---

[emaker.io]

[emaker.limited]

Guys

Dumb question/s time.

To program the compiled hex to a given microcontroler, does it need to have the Arduino bootloader in place ??

I have had a rummage through the makefile etc and it looks like this is the case. Just wanted to check in case I was missing something or other.

Failed miserably with "make program" using an Atmel AVRISP...

Might be worth stating explicitly what the prerequisites are for a successful build/load. Sorry if I have missed this somewhere.

I am just making up a set of firmwares etc for users of the Min644p boards to download and use without them having to go compile everything from scratch. Just makes it a little more user friendly for non programmers.

It might be worth considering doing this (for release versions only) for the boards/controllers directly supported by the firmware.

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

aka47 Wrote:
-------------------------------------------------------
> To program the compiled hex to a given
> microcontroler, does it need to have the Arduino
> bootloader in place ??

no, see below

> I have had a rummage through the makefile etc and
> it looks like this is the case. Just wanted to
> check in case I was missing something or other.
>
> Failed miserably with "make program" using an
> Atmel AVRISP...

Anything that avrdude supports should work, you'll just have to update your Makefile to suit. Change port, baud, programmer type, etc.

I usually program mine using a bootloader, but I also program successfully using a separate ISP programmer for those times when I really need the extra 512 bytes!

> Might be worth stating explicitly what the
> prerequisites are for a successful build/load.
> Sorry if I have missed this somewhere.

I'll put it right here then-
build requires:
gnu make
binutils, gcc and associated tools built for avr target (avr-gcc)
avr-libc
program requires:
avrdude
something that avrdude knows how to talk to (bootloader, isp programmer, etc)

> I am just making up a set of firmwares etc for
> users of the Min644p boards to download and use
> without them having to go compile everything from
> scratch. Just makes it a little more user friendly
> for non programmers.

lovely! Anything that makes it easier is great.

> It might be worth considering doing this (for
> release versions only) for the boards/controllers
> directly supported by the firmware.

That's an excellent idea! I think I'll do exactly that when we're ready for a release!

---

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

I have downloaded the latest commit (eaddc51) and have done some testing.

The m115 command still outputs this:

ok test_FIRMWARE_NAME:FiveD_on_Arduino FIRMWARE_URL:http1b.com/triffid/FiveD_on_Arduino/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:1 TEMP_SENSOR_COUNT:1 HEATER_COUNT:31236

I started wondering if somehow I was compiling old code or maybe it wasn't being uploaded to the board or something so I added the "test_" in front of "FIRMWARE_NAME" to make sure I knew what was on the chip. I have also confirmed that the changes in the most recent commit are in the files I am compiling and uploading.

I tried the m135 command which produced a short flash of the led I have imitating my heater. The flash varied in brightness depending on the value I gave m135 (m135 s50 = dim flash, m135 s250 = brighter flash) but always lasted less than a second.

I am still getting very little movement from the y axis. I have examined it closer and it seems to do the same thing every time I give it new position. For example g0 y50 causes one step then a pause of aprox. 2-3 seconds then 2-3 steps more steps all in the positive direction. If I then tell it g0 y0 the same thing would happen in the negative direction. The number of steps doesn't seem to change with how far y should move.

Well that is what I have to report so far. I hope this helps somehow.

>> Might be worth stating explicitly what the
>> prerequisites are for a successful build/load.
>> Sorry if I have missed this somewhere.
>
>I'll put it right here then-
>build requires:
>gnu make
>binutils, gcc and associated tools built for avr target (avr-gcc)
>avr-libc
>program requires:
>avrdude
>something that avrdude knows how to talk to (bootloader, isp programmer, etc)

I was thinking maybe in the README file that people like myself or newbies might work from when building.....

On Bootloader versus programmer.

I personally like the idea that having an arduino compatible microcontroler ie with functioning bootloader is a prerequisite for the primary route to success. This does though need to be made clear in the source docs. It is easily supportable and reduces the need for in depth device knowledge. Excellent choice

If programming one of the AVR microcontrolers direct rather than through a boot loader there are a few more device specific things that must be done. ie the fuse settings. Where the device you are using is or was an arduino these have already been done for you. If it is a "From the factory" blank chip then you have to do them as well as drop your code in. Or it will fail. (wrong memory arrangement, clock source etc etc)

I have a number of Arduino boards but with the Min644p board (this also takes an atmega1284) I am using factory fresh controllers. In using a 1284 at 20Mhz it is well off the Arduino piste. (I can provide pre-compiled boot-loader firmware and a set of fuse settings that work, if I know I need to do this, as well as instruction on how to apply them)

In helping folk put Amforth onto factory fresh devices the thing that everyone new (or from a purely arduino based route) falls over are the extra steps that they didn't realize needs to be done for a fresh device. Incorrect fuse settings give some pretty quirky results that can look like the software is failing......... When it is not.

The issue (if there is indeed one) is that of support, what can you reasonably offer guidance and support for. You are all great guys and will attempt to help folk with whatever. You can rapidly find yourself spread a little thin though and perhaps distracted from your real interest area........ The firmware.

My suggestion then, is'nt that what is being done is in any way substandard. It is simply that you have a primary route to success that you state (README and build docs), and practice (Makefile). The two need to match up and would perhaps then be your supported route to success. Make it very obvious. Anything else being helped along as a best endeavors. Beware assuming that something you know, another builder will know also (a lot are newbies and don't, where as you guys are gods and do).

Yes of course a bunch of that is the build tools. the big obstacle for some will actually be getting the code onto the microcontroler. Your Makefile and source compiled for me first time clean and will probably do the same for most other folk that down load it. Excellent job well done.

Getting the code onto the chip there are some assumptions made, but not stated that a newbie will fall over and fail.

I responded to your call for folk to test the firmware (the build and load is part of that) and downloaded it onto a cleanish system as if a newbie. Built it like a newbie referring to the README and source docs. Attempted to load it like a newbie onto a factory fresh device following the same docs and failed. (built for 644 and attempted to program it into a 16Mhz 644, sanguino clone)

This failed, so hooked up my Atmega AVRISP II (cos I am not a newbie) changed the device in the make file and attempted to load again. Failed.

Why is obvious to me, but there again I am not a newbie....... I checked the build docs and it is not clear whether I needed a bootloader (this would then have been successful) or needed to find out more about how to program a factory fresh device.

Your makefile assumption (Makes an Ass out of U and Me, particularly when I recommend 5DA to folk who are less aware) is that the firmware would be programmed into a board that is set up to be as an arduino with the bootloader. (State this as your primary route to success, it is actually a very good idea) If the builder is using a blank chip they will have to either program a bootloader onto their chip or use a programming device as well as set the devices fuse links. (State this as alternatives, that someone could choose to follow but need to find out more, and are better to stick to the primary route for success)

It is obvious to us but is not at all to a newbie or someone who has only Arduino experience (Don't all chips come with a bootloader ?????)

I guess finally the give away should be in the tittle of the project (5D on Arduino) but if life were that simple we would not need to print on coffee cups "May be hot".

---

Necessity hopefully becomes the absentee parent of successfully invented children.

As I go about planning my Mendel build, I've been following this thread with great interest . As it stands, do to the Holidays and kids presents, I have to wait to get my presents. so hardware and parts are coming slowly! regardless, I decided to start looking into the code here and getting it installed on my Duemilanove. I have a couple of easyDriver steppers from sparkfun which run a few NEMA17s that I have coded for other projects to be driven by the Duemilanove and all work as expected. I had assumed once the Firmware was installed It was just a matter of wiring the drivers to the PINOUTS and I should get some movement. this does work for 1 stepper but not 2. using either mendel_cmd or mendel_talk I can get M114 and M115 to respond and G0 X10 Y10 will move 1 stepper at a time usually stepper X. once that move is complete no other G codes will respond. I have gone through the config.h code and the makefile and cannot find anything that would lead me to believe that there is anything different I need to do here( I do have power to both stepper drivers so yes, its plugged in ), Does anyone have any other troubleshooting tips on what to do to test the X stepper and Y stepper together ? it seems that turning debug on does not produce any noticeable effects as well nor XONXOFF. I have altered my PINOUTS to those in the config.h file as well as changed the AIO to DIO PINS to test that.
Much thanks in advance,
Karl
Also, Does anyone else have an issue with reloading the firmware? 'make program' works once every 15 tries. I am running on ubuntu 10.10

Architect Wrote:
-------------------------------------------------------
> I decided to
> start looking into the code here and getting it
> installed on my Duemilanove. I have a couple of
> easyDriver steppers from sparkfun which run a few
> NEMA17s

Wow similar setup. I am using a boarduino (w/168 chip) and 4 Sparkfun Easy drivers and maybe having similar troubles as well. Which branch and commit are you using?

> this does work for 1 stepper but not 2.
> using either mendel_cmd or mendel_talk I can get
> M114 and M115 to respond and G0 X10 Y10 will move
> 1 stepper at a time usually stepper X. once that
> move is complete no other G codes will respond.

I have been having trouble getting my y axis to move. I have described it in greater detail here. Is that anything like what you are experiencing? Are mendel_cmd and mendel_talk from the official RepRap software? I have been using this command (in linux):

stty raw ignbrk 115200 < /dev/ttyUSB0 ( cat <&3 & cat >&3; kill %%) 3<>/dev/ttyUSB0

to send single and short strings of commands (ctrl-d to exit). To send entire files of Gcode (and single commands too) I have been using gtkterm but hyperterm should work, under windows, too (xon/xoff needs to be enabled for these).

>( I do have power to both stepper
> drivers so yes, its plugged in ),

Captain Obvious says: "Remember not to unplug the stepper motors from the easy driver while the power is on."

Does anyone have
> any other troubleshooting tips on what to do to
> test the X stepper and Y stepper together ?

A command like g0 x10 y10 should cause X and Y to move to +10 mm at the same time (ie. one move), not sure why that isn't working for you.

> it seems that turning debug on does not produce any
> noticeable effects

The debug options don't fit on the 168 chip but if that was the problem you wouldn't be able to upload to the board. I suspect your Duemilanove is using the 324 chip if you are able to upload the firmware with debug options enabled. Unfortunately that is all I know about debug because I cannot enable it.

> Also, Does anyone else have an issue with
> reloading the firmware? 'make program' works once
> every 15 tries. I am running on ubuntu 10.10

Yes. I have been unable to load the firmware without using the force (-F) option with avrdude. Look here and here for more information. Also lately I have been getting "programmer not responding" every other time I try to upload, even with the -F option. I have been forging ahead though, using brute force and ignorance.

working on it now,
the last commit was from triffid on the 7th (yesterday)
I'm excited to learn (yet another) source control app git :-)

I'm also running this from a Linux command line and Triffid provided the shell scripts which mendel_cmd and mendel_talk are used. very nice

So the way I left it/Its set right now my config is:
#define X_STEP_PIN DIO2 //AIO0
#define X_DIR_PIN DIO3 // AIO1
#define X_MIN_PIN DIO4 //

#define Y_STEP_PIN DIO6 //AIO3
#define Y_DIR_PIN DIO7 //AIO4
#define Y_MIN_PIN DIO8 //AIO5

Y stepper is working but X stepper is not.

also, G1 Y10 - stepper rotates

using mendel_talk:
mendel_talk
m114
ok X:0,Y:0,Z:0,E:0,F:400
g1 y10 // y axis turns
ok
m114
ok X:0,Y:3200,Z:0,E:0,F:50
g0 x0 y0 // y axis returns 2x speed
ok
m114
ok X:0,Y:0,Z:0,E:0,F:400
g1 y10 //y axis turns again
ok
g1 y10 // no response
ok
m114
ok X:0,Y:3200,Z:0,E:0,F:50 //second g1 y10 did not up the y position
g0 x0 y0 // returned to 0
ok
g1 x10 y10 /y turned again
ok
m114
ok X:3200,Y:3200,Z:0,E:0,F:50 // x never turned

I'll try the -F switch.

I think I have a bad pin on my arduino.
#define X_STEP_PIN DIO4 // AIO0
#define X_DIR_PIN DIO5 // AIO1
#define X_MIN_PIN DIO2 // AIO2

#define Y_STEP_PIN DIO6 // AIO3
#define Y_DIR_PIN DIO7 // AIO4
#define Y_MIN_PIN DIO8 // AIO5

both are now working

grrr
this is what I get when I skim the docs.
G1 X10 Y10 moves to 10, 10
G1 X10 Y10 wont do anything cux were already at 10, 10
G1 X5 Y5 moves -5, -5 from current
and so on and so on

If you have a test meter and or good eyesight it might be worth checking out the connections on the board for dry joints etc.
Pins on chips are usually good or bad, very rarely intermittent.

Intermittent working stuff is usually a bad socket contact or dry solder joint.

If you cant see any dry joints re flow all the joints relating to that pin anyway using a fine soldering iron. It may just work again.

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Quote
spaztik
The debug options don't fit on the 168 chip

This is a memory size limitation only, so depending on what you want to debug, you can switch off other parts to allow turning on debug. For example, you can comment out HEATER_PIN in config.h to allow DEBUG and ease debugging of the remaining parts.

Quote
Architect
ok X:3200,Y:3200,Z:0,E:0,F:50 // x never turned

3200 means 3200 mm = 3.2 metres, so it's far out of the mechanical capabilities of most (all?) RepRap machines. You probably run into numerical limitations with such a command. Try something smaller than +-600 mm.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> 3200 means 3200 mm = 3.2 metres, so it's far out
> of the mechanical capabilities of most (all?)
> RepRap machines. You probably run into numerical
> limitations with such a command. Try something
> smaller than +-600 mm.


interesting because i used these commands
ok X:0,Y:0,Z:0,E:0,F:400
g1 y10 // y axis turns
ok
m114
ok X:0,Y:3200,Z:0,E:0,F:50
---------------------------------------------
so y10 = 3200 mm movement? I have my config set at the defaults where I believe it picks up 320 from.

Anyways, forward progress. I was able to get replicatorG to control X and Y steppers for between 5-26 minutes before it became none responsive. I had to change the BUFFER_CNT to 128 and the BAUD_RATE to 56k in the serial.c file as well as change the Start to 's'tart. btw when i did that the strange character in front/over the 'S' went away.
My question to everyone is which Host software running on Ubuntu 10.10 has everyone had the most success with?
I am pretty well versed in Java so I downloaded the source code to change the Driver for the buffer_cnt/baud rate and Start command which I will work on tonight. but I was a bit surprised to see a test run just stop responding a 3rd of the way through. anyone have any thoughts on that. I do not have an extruder hooked up nor Z axis at the moment. stepper drivers are on their way. but the firmware ( or host not sure) cuts out at random places when interpreting Gcode.

Hope all is enjoying the holidays,
-Karl

The Java host software is buggy. Try RepSnapper, it might be less buggy for you I can help with that client software, especially if you come to #repsnapper@freenet (IRC). I haven't actually gotten this firmware to work, should try again now that it seems to mostly work.

Btw. is homing (G28) working yet? I'd like the ability to calibrate the position automatically before I switch to this for production use.

thanks for the reply! i actually was doing a search on RepSnapper and the first entry lead me back here to your response! must be in the cards! For me no, G28 did not produce a response.

-karl

Traumflug Wrote:
-------------------------------------------------------
> ok X:3200,Y:3200,Z:0,E:0,F:50 // x never turned
>
> 3200 means 3200 mm = 3.2 metres, so it's far out
> of the mechanical capabilities of most (all?)
> RepRap machines.

The firmware returns position in steps rather than mm, will have to be changed when hosts actually start using returned positions for stuff

---

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

Architect Wrote:
-------------------------------------------------------
>... I was a bit surprised
> to see a test run just stop responding a 3rd of
> the way through.

That sounds very much like a problem I just got done fighting through.
Read more here

The short version...
I deleted the code that shuts down the arduino. That seems to have fixed it.

Two days ago I spotted an unfortunate bug in gcode_parse.c: decfloat_to_int() overflows pretty easily. For example: Z2 -> 320 steps, Z2.0 -> 320 steps, but Z2.0000 -> 210 steps and Z 2.00000 -> -4 steps.

One part of the fix is to limit reading the number right of the decimal to 4 digits. This can be done with the following code around line 330:

default:
	// can't do ranges in switch..case, so process actual digits here
	if (c >= '0' && c <= '9' && read_digit.exponent < 5) {

That isn't sufficient for all cases, though. In the function it's self the following has to be solved: x = a * b / c, with each of a, b, c having 22 to 24 significant bits and x having 31 significant bits. Using an intermediate 64-bit integer isn't an option, as this pulls in a whoppy 7 kB of library code. Any blessed mathematician out there having a solution for this case?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

One solution would be to send all position commands in microns and eliminate the need to convert from float to int.

To use with standard software, the model would just need to be scaled by 1000.

---

[emaker.io]

[emaker.limited]

After a lot of back an forth, the solution starts to appear: To allow high STEPS_PER_MM, like 3200, as well as low, accurate ones, like 8.192, I attempt to shift the value before doing calculations a few bits to the left, and the same number of bits to the right after having the result. Previously this was done with factors base 10, which is less than optimal on a binary computer, of course. The current code looks like this:

// valid range: 0.001 to 4095.0
#define	STEPS_PER_MM_X				320.000

/*
	Switch user friendly values to coding friendly values

	This also affects the possible build volume. We allow +-20 bits for the value and 12 bits
	for the STEPS_PER_MM multiplicator. Resolution in mm mode is 0.001 mm and 0.0001
	in inch mode. So the step-accurate range is

		2^20 mm / 1000 = +-1048 mm or
		2^20 in / 10000 = +-104 in

	Regarding the multiplicator we extract the upper 12 _used_ bits, providing a resolution of
	1 / 4096 = 0.000244 for both, mm and inch. At runtime, this extraxtion is reversed by
	shifting the calculated number of stepper motor steps by STEPS_xx_x_SHIFT bits to the
	left, leading to a result as accurate as possible with 32-bit integers (and more accurate than
	with 32-bit floats).
*/

#if (STEPS_PER_MM_X < 2^0)
#define STEPS_MM_X_SHIFT 12
#elif ((STEPS_PER_MM_X < 2^1)
#define STEPS_MM_X_SHIFT 11
#elif ((STEPS_PER_MM_X < 2^2)
#define STEPS_MM_X_SHIFT 10
...
#elif ((STEPS_PER_MM_X < 2^11)
#define STEPS_MM_X_SHIFT 1
#elif
#define STEPS_MM_X_SHIFT 0
#endif
#define STEPS_MM_X ((uint32_t) (STEPS_PER_MM_X * 2^STEPS_PER_X_SHIFT))

Then, decfloat_to_int() shrinks to:

int32_t	decfloat_to_int(decfloat *df, int16_t multiplicand, uint8_t shift) {
	uint32_t	r = df->mantissa;

	r *= multiplicand; // 20 bits + 12 bits = 32 bits = safe

	// exponent=1 means we've seen a decimal point but no digits after it, and exponent=2
	// means we've seen a decimal point with one digit so it's too high by one if not zero
	if (df->exponent == 2)
		r /= 10;
	else if (df->exponent == 3)
		r /= 100;
	else if (df->exponent == 4)
		r /= 1000;
	else if (df->exponent == 5)
		r /= 10000;

	r >>= shift;

	// sign
	if (df->sign)
		return -(int32_t)r;

	return (int32_t)r;
}

and can be called with:

next_target.target.X = decfloat_to_int(&read_digit, STEPS_MM_X,
                                      STEPS_MM_X_SHIFT);

This should work well. The drawback is, the preprocessor can't do the pre-maths with all the #ifs, because it's floating point. I hope I can find a solution without calculating this at runtime and comfortable to the user, i.e. asking the user to only set STEPS_PER_MM shall be enough.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

bug report:
for temp results from M105 command and repsnapper
I had to remove the space after "T: " in this line in temp.c

sersendf_P(PSTR("T:%u.%u\n"), temp_sensors_runtime[index].last_read_temp >> 2, c);

I will put a bug into github as well ( if I can figure out how too :-) )

Hey all,

First I just want to say that I'm very impressed with this firmware. I've tried a few different firmwares trying to find something that will work with my setup (A threaded rod driven "Catalyst" mendel) and have had nothing but problems.

I've found that the official firmware consistently has 4ms gaps in the step signals, and it seems to be due to the way the arduino libraries handle serial interrupts. I switched to this firmware and not only were these gaps all but gone (there does still seem to be a skipped step between moves when using REPRAP_ACCELERATION) but the step signal jitter has practically disappeared.

Anyway, I was first trying out the release_candidate branch, and had great success until I started working with the thermistor. I had no luck getting this working, and found a series of patches added in a different branch that seem to address this. As a result, I switched to the release_candidate_triffid branch, and got the heater working but this lead to a few new problems.

Once the heater was working I found that the step signals would show worse gaps than I was seeing with the official firmware, albeit only 2ms instead of 4 but far more often. I traced this down to the TICK_TIME (which surprise surprise was set to 2ms), and changing this to 250 US eliminated the jitter in the step signals however now the temperature readings have ceased to be taken. M115 consistently reads 0.0 where the lowest my thermistor table should ever show is 35.0

This looks like a bug in the timer code, but I'm not dead set on using this branch if there is another that may work better.

Just some relevant detail on my set up:
STEPS_PER_MM = 315.0 (for x,y and z)
Using a Thermistor, and currently not using a pwmable IO pin for the heater control.

Any suggestions are welcome :-)

Jes