Welcome! Log In Create A New Profile

Advanced

Project: Teacup Firmware

Posted by Triffid_Hunter 
Re: Project: Teacup Firmware
March 09, 2011 02:44PM
***Note**** I am compiling and Flashing Teacup using the Aruduino 022 Development Environment.

Thus not using gnu make with the Makefile.



@ Architect

The connection times out with No connection using Teacup with Repsnapper.

During the time it takes for the time out you can send commands (ie before time out occurs )

These commands can be used.. Jog X , jog Y jog Z , home X,Y or Z Home All heater on .

It is as if there is a missing responce / handshake / Checksum that Repsnapper is expecting.

If I reflash the Motherboard with the Tonokip RepRap firmware build Repsnapper retains the serial connection. (no time out).

@ elmom

I only seem to be able to get the Makerbot firmware to work with Replicator G

The Tonokip RepRap firmware to work with Repsnapper.

And the Reprap Firmware to work with the RepRaphost.

I am using the Gen3 Atmega 644 V1.1 Mother boards.

I have yet to try Eriks Ultimaker firmware.
I've built a Ramps not tested it yet as I missing one A3984 stepper board... (out of stock everywere).

Edited 1 time(s). Last edit at 03/09/2011 02:59PM by BodgeIt.


Bodge It [reprap.org]
=======================================

BIQ Sanguinololu SD LCD board BIQ Stepcon BIQ Opto Endstop
BIQ Heater Block PCB BIQ Extruder Peek clamp replacement BIQ Huxley Seedling
BIQ Sanguinololu mounting BIQ standalone Sanguinololu or Ramps mounting Print It Stick It Cut it


My rep strap: [repstrapbertha.blogspot.com]

Buy the bits from B&Q pipestrap [diyrepstrap.blogspot.com]
How to Build a Darwin without any Rep Rap Parts [repstrapdarwin.blogspot.com]
Web Site [www.takeaway3dtech.com]
Re: Project: Teacup Firmware
March 09, 2011 02:52PM
i will look when i get home but I seem to recall modifying repsnapper to accept [sS]tart you can modify teacup to change the "start" response to "Start" to test this.
often times I also just reset my board just as i hit the connect button in repsnapper to get it to catch the start/ok response too.
Re: Project: Teacup Firmware
March 09, 2011 03:07PM
So I got my machine working with Teacup (and only teacup)! It prints objects and no longer freezes! I am super happy winking smiley
I put up some pics and descriptions here
The Knot was the first successful print I made. So far all my custom electronics and extruder are working wonderfully! Special thanks to Triffid_Hunter who helped me hunt down strange issues in the firmware.
Re: Project: Teacup Firmware
March 09, 2011 03:16PM
Yep I had alredy spotted that and tried that ~ I think I changed it from 'S'tart to 's'tart though..

I was comparing it with Tonokip RepRap firmware serial output.

I have tried diffrent Baud rates ~ even adding an extra stop bit PC side to give more space between the data ~ an old cure all for serial race conditions.


Could it possibly be some thing compiling diffrently in the Aruduino 022 Development Environment.?

I have never managed to get the Makerbot Firmware to work correctly using extruder controllers I built 4 Extruder controllers I got them to work with the RepRap firmware thou... Strange ...

I dont use any of the 4 extruder controllers now just the Gen3 644 V1.1 motherboards one with an onboard 644 & one with the Sanguino piggy backed on to it.

Edited 1 time(s). Last edit at 03/09/2011 03:34PM by BodgeIt.


Bodge It [reprap.org]
=======================================

BIQ Sanguinololu SD LCD board BIQ Stepcon BIQ Opto Endstop
BIQ Heater Block PCB BIQ Extruder Peek clamp replacement BIQ Huxley Seedling
BIQ Sanguinololu mounting BIQ standalone Sanguinololu or Ramps mounting Print It Stick It Cut it


My rep strap: [repstrapbertha.blogspot.com]

Buy the bits from B&Q pipestrap [diyrepstrap.blogspot.com]
How to Build a Darwin without any Rep Rap Parts [repstrapdarwin.blogspot.com]
Web Site [www.takeaway3dtech.com]
Re: Project: Teacup Firmware
March 09, 2011 09:00PM
just looking at some of my code here at home and I remembered I changes the Baud rate in serial.c to 57600 to play nice with repsnapper. not sure if that is where you had changed yours but that I'd post it up just in case.
Re: Project: Teacup Firmware
March 11, 2011 11:44AM
Bug in sermsg.c
void serwrite_hex16(uint16_t v) 
{
	serwrite_hex8(v >> 8);
	serwrite_hex8(v & 0xFF);
}

void serwrite_hex32(uint32_t v) 
{
	serwrite_hex8(v >> 16);
	serwrite_hex8(v & 0xFFFF);
}

Should be:
void serwrite_hex16(uint16_t v) 
{
	serwrite_hex8(((uint8_t) v >> 8));
	serwrite_hex8(((uint8_t) v & 0xFF));
}

void serwrite_hex32(uint32_t v) 
{
	serwrite_hex16(((uint16_t) v >> 16));
	serwrite_hex16(((uint16_t) v & 0xFFFF));
}

Ideally you should be casting and serwrite_hex32 is calling the wrong function
Re: Project: Teacup Firmware
March 11, 2011 12:15PM
I think your casts are in the wrong place and the ANDs are unnecessary.

void serwrite_hex16(uint16_t v) 
{
	serwrite_hex8((uint8_t) (v >> 8));
	serwrite_hex8((uint8_t) v);
}

void serwrite_hex32(uint32_t v) 
{
	serwrite_hex16((uint16_t) (v >> 16));
	serwrite_hex16((uint16_t) v));
}


[www.hydraraptor.blogspot.com]
Re: Project: Teacup Firmware
March 11, 2011 04:43PM
Forgive me my ignorance, but what's the difference between

serwrite_hex8((uint8_t)v);

and

serwrite_hex8(v);

if serwrite_hex8 accepts uint8's only anyways?


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
March 11, 2011 04:58PM
annodomini2 Wrote:
-------------------------------------------------------
> Bug in sermsg.c
>
> void serwrite_hex16(uint16_t v)
> {
> serwrite_hex8(v >> 8);
> serwrite_hex8(v & 0xFF);
> }
>
> void serwrite_hex32(uint32_t v)
> {
> serwrite_hex8(v >> 16);
> serwrite_hex8(v & 0xFFFF);
> }
>
>
> Should be:
>
> void serwrite_hex16(uint16_t v)
> {
> serwrite_hex8(((uint8_t) v >> 8));
> serwrite_hex8(((uint8_t) v & 0xFF));
> }
>
> void serwrite_hex32(uint32_t v)
> {
> serwrite_hex16(((uint16_t) v >> 16));
> serwrite_hex16(((uint16_t) v & 0xFFFF));
> }
>
>
>
> Ideally you should be casting and serwrite_hex32
> is calling the wrong function

hm, i fixed this a week or two ago, must be in one of my branches but definitely belongs in master. Ps it works fine with implicit casts.

Well spotted smiling smiley


-----------------------------------------------
Wooden Mendel
Teacup Firmware
Re: Project: Teacup Firmware
March 11, 2011 06:22PM
@Traumflug,
A lot of compilers give a truncation warning without the cast. Other than that, no difference.

However, annodomini2,s version would throw the top bits away before the shift, so would not work.


[www.hydraraptor.blogspot.com]
Re: Project: Teacup Firmware
March 12, 2011 10:50AM
Need some help. I have my extruder using pwm on pin 13 of my atmega1280 and for some reason there is noise on that pin I can't find, but pwm is working.
I switched pins to pin 2 and pwm doesn't seem to be working on this pin. I switched the port, pin and timer in the heater def as described in the notes in the config.
I'm looking at the pwm setting in Mendel.c and wondering if anyone else has this working.
Re: Project: Teacup Firmware
March 12, 2011 12:12PM
well, found the noise on pin 13. my heater unit is missing a ground from the sig to 5v. grounded the 12v and 5v together and the noise went away. but still, I would like to have this over on pin 2 if possible.
heres is how I have my Heater defined

DEFINE_HEATER(extruder, PORTE, PINE4, OCR3B ) ; (  not sure if the Timer should be OCR3BL or OCR3B )


this is on a 1280.

Timer masking in mendel.c is

#ifdef	TCCR3A
		TCCR3A = MASK(WGM30);
		TCCR3B = MASK(WGM32) | MASK(CS30);
		TIMSK3 = 0;
		OCR3A = 0;
		OCR3B = 0;

TCCR3A is defined for this board.

thanks
Re: Project: Teacup Firmware
March 12, 2011 07:49PM
Architect Wrote:
-------------------------------------------------------
> DEFINE_HEATER(extruder, PORTE, PINE4, OCR3B ) ; (
> not sure if the Timer should be OCR3BL or OCR3B )

I think it should be OCR3BL since we only use the lower 8 bits anyway. no compiler warnings for OCR3B? I would have thought gcc would complain about strict aliasing or something like that, creating a uint8 pointer from a uint16 value


-----------------------------------------------
Wooden Mendel
Teacup Firmware
Re: Project: Teacup Firmware
March 12, 2011 08:00PM
nope no warnings from the compiler. eye rolling smiley
Re: Project: Teacup Firmware
March 14, 2011 10:15AM
I spent most of the last 48 hrs working, reworking and working again on getting my temp sensor on my heater calibrate and turn it with PWM. i started out at 150C and was very happy with the success there. when i pushed it to 240. it failed miserably. I could not get it past 235. no matter what changes i made to PID. i re calibrated my thermistor matched the ref Voltage exactly in my temp chart calculations and did significant testing on my heater controller. I knew my heater could go above 235 from earlier testing on it so I didn't understand why it would be having issues when introducing PID (again). out of frustration I reverted back to base testing and put in BANG/Bang again. now I get very accurate readings up to 255C. with a nominal 3C drop. i.e. if I set my temp to 253 I get a very steady 250 on my thermistor and a DMM with an external thermistor inside the barrel. so my question is why? I am thinking for now that perhaps it would be better to Wrap PI logic around BANG_BANG to get the temp up to my target and I am wondering why we are using PWM inside of PID which from my understanding @ 10 millisecond is itself a PWM of sorts. This was how the last version of the firmware i had, had it and I was able to get stable results back then. but I believe my earlier testing were only at the 100c level while I was getting comfortable working with this tech.
anyways thanks all. btw this post was quiet this weekend. hope you all had some fun.

Trout ><,`>
Re: Project: Teacup Firmware
March 14, 2011 11:00AM
Guys

Is there an IRC channel on freenode for teacup ??


Necessity hopefully becomes the absentee parent of successfully invented children.
Re: Project: Teacup Firmware
March 14, 2011 11:05AM
that would be cool...
Re: Project: Teacup Firmware
March 14, 2011 11:54AM
I have been on #Reprap and #Repsnapper this morning and am amazed at the biodiversity going off in the Reprap ecosphere.

What I really need to know though is what is the best host ware to use with teacup.

The reprap wiki suggests it works with anything, but I am not convinced about RepG24

Somewhere to chew these sorts of things over would be good.


Necessity hopefully becomes the absentee parent of successfully invented children.
Re: Project: Teacup Firmware
March 14, 2011 12:03PM
i have it working pretty good with RepG & repsnapper. i prefer rep G for the skeinforge comparability, but i use repsnapper for editing raw gCode or sending raw gcode (but more so now with just the line commands) . message me if you like. I'm at work now but might be able to help.
or you can put your reg and teacup questions up on the other posting and i can help you there.
Re: Project: Teacup Firmware
March 14, 2011 12:12PM
Probably better on other posting. as its about RepG. Heading over that way now.


Necessity hopefully becomes the absentee parent of successfully invented children.
Re: Project: Teacup Firmware
March 14, 2011 02:43PM
Just had a go on freenode there looks to be an irc channel already called teacup, that is something to do with novels.
Gonna try ProjectTeacup


Necessity hopefully becomes the absentee parent of successfully invented children.
Re: Project: Teacup Firmware
March 14, 2011 02:50PM
irc channel #ProjectTeacup on freenode is good to go.


Necessity hopefully becomes the absentee parent of successfully invented children.
Re: Project: Teacup Firmware
March 14, 2011 02:53PM
Quote

I am not convinced about RepG24

Seen your complaints on #reprap. As long as this host can't show the the communications going to and coming from the controller somehow, trying to find out what's going on is like stepping in the dark. First step towards a solution would probably to fix RepG in that part.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
March 14, 2011 03:49PM
repG logs all communication into the replicatorG.log file. as well as displays it in its terminal box.
this goes for both send and receive commands. I use both these when troubleshooting and debug messages works well enough. I do recommend at the least something like vim for the windows env to grep through the file.
Re: Project: Teacup Firmware
March 14, 2011 07:02PM
I am struggling to find a log file anywhere, even did searches etc for log files and checked /tmp. not a sign.

Although I can see the terminal window fine. Turned the logging up to all.

Been discussing RepG in Reprap managed to slide a little something on topic into the mix. Maybe time to plat up a copy of repsnapper tomorrow. While I continue debuging the hardware.

Traumflug, complaining is probably a bit strong. At the moment looking for valuable input, and in the mean time had come to the same conclusion as your self. Unfortunately logging looks to be broken and RepG refuses to talk to my socat virtual serial port (error in terminal window claims it isnt a serial port).

.replicatorg only has firmware stuff in.


Necessity hopefully becomes the absentee parent of successfully invented children.
Re: Project: Teacup Firmware
March 15, 2011 04:38AM
BodgeIt Wrote:
-------------------------------------------------------
>
> @ Architect
>
> The connection times out with No connection using
> Teacup with Repsnapper.
>
> During the time it takes for the time out you can
> send commands (ie before time out occurs )
>
> These commands can be used.. Jog X , jog Y jog Z
> , home X,Y or Z Home All heater on .
>
> It is as if there is a missing responce /
> handshake / Checksum that Repsnapper is
> expecting.
>
Yes, It's expecting a "start", but you can disable that in the settings, it's a checkbox next to the baudrate setting.
>
> @ elmom
>
> I only seem to be able to get the Makerbot
> firmware to work with Replicator G
>
Well, it should work. Most likely it's something small and trivial. Be sure to use the reprap driver. Note that I haven't really tried with recent versions.
Re: Project: Teacup Firmware
March 15, 2011 04:50AM
I've been trying ReplicatorG 24 with the latest Teacup firmware and not had much luck. After resetting it a bunch of times I can occasionally get it to control the heater and do a couple of jogs in the control panel. But it always eventually freezes RepG hard, sometime just the first time clicking on a jog button or a temperature field. I have to go into Task Manager and kill javaw.exe. Anybody else seeing this?
Re: Project: Teacup Firmware
March 15, 2011 07:16AM
Yeah,
This seems to happen about every third time I run repG. As I have been more concerned with the firmware I have not tried debugging it.
So far, I have not seen anything that points to what might be causing the freeze up. Usually I have to kill the process as well and try again.
The other bug in repG I've noticed is if you stop a print, you won't be able to run another one unless you restart the app. I'm not sure where to report
This error and figured I'd do so once I started focusing on the app and not my firmware/hardware. I've been using repG with teacup alot over the last month
Or so, and it does complete my print jobs pretty reliably once it starts.
The freeze up it really annoying me now that I've got things on the firmware working more reliably. I might look more deeply into this tonight.
A side note, I misspoke on my earlier post regarding logs for repG. I run it for the source code in my IDE eclipse. This provides me the console output I use for logging and communicTion monitoring. The same output can be had by running repG from a command line. At least on a unix box. Haven't tried it in a windows env.
Re: Project: Teacup Firmware
March 15, 2011 10:17AM
nophead Wrote:
-------------------------------------------------------
> I think your casts are in the wrong place and the
> ANDs are unnecessary.
>
>
> void serwrite_hex16(uint16_t v) 
> {
> 	serwrite_hex8((uint8_t) (v >> 8));
> 	serwrite_hex8((uint8_t) v);
> }
> 
> void serwrite_hex32(uint32_t v) 
> {
> 	serwrite_hex16((uint16_t) (v >> 16));
> 	serwrite_hex16((uint16_t) v));
> }
>

Not been on for a little while, the AND's (bit masking) are typically used if the code could be used on different architectures (e.g. 32 bit), different compilers handle the casting situation in different ways and on 8 and 16 bit micro's the math implementation can have a big impact.

If your code is intended to be as generic as possible, bit masking ensures that only the intended data is copied (e.g. some 32bit micro's treat everything as 32bit irrelevant of the data type), if not, this can cause problems downstream if the data is used in calculations or comparisons. It can also make the issue very difficult to diagnose if there is a problem as generally the issue occurs upstream of where the problem is reported.

Explicit casting is beneficial for the reader as it covers that you are converting from one type to another, so this is easy to read.

As someone said i believe, some compilers will complain about implicit casts from a larger to a smaller type depending on the settings.

Not using explicit casts can also sometimes cause quirky behaviour with optimisers.

Many industry coding standards e.g. MISRA, DO-178B etc. require explicit casting as a standard, especially when going from a larger to a smaller type. e.g. 32bit -> 16bit.

My brackets were in the wrong place, I was ill and wanted something to keep my mind occupied:

void serwrite_hex16(uint16_t v) 
{
	serwrite_hex8((uint8_t) ((v >> 8) & 0xFF));
	serwrite_hex8(((uint8_t) (v & 0xFF));
}

void serwrite_hex32(uint32_t v) 
{
	serwrite_hex16((uint16_t) ((v >> 16) & 0xFFFF));
	serwrite_hex16((uint16_t) (v & 0xFFFF));
}

You may also want to bit mask the upper word, you're explicitly asking for specific behaviour.

Triffid,
I would also suggest giving your parameters more descriptive names, the code begins to read more like English if you do this and generally requires fewer comments to explain an operation.

The parameter name length will have no impact on the size of the binary, and a few bytes of text added to the code file size isn't really significant.
Re: Project: Teacup Firmware
March 15, 2011 11:26AM
Quote

The parameter name length will have no impact on the size of the binary, and a few bytes of text added to the code file size isn't really significant.

Oh, we can reduce the binary size by shortening function names? Excellent idea, didn't think of that. That would allow '168 users to turn on an additional feature or two.

So I immediately tried and shorted 4 function names by 6 characters each. The binary size lost only 4 of those 24 chars, though.

Regarding "renaming everything": IMHO, Teacup is already fairly good in it's naming conventions. But I'm also the guy seeing new bugs instead of advantages in new features.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Sorry, only registered users may post in this forum.

Click here to login