Show all posts by user
People building or using RepRaps.
Re: Teacup Firmware replicatorG & Skeinforge - 15 years ago
If you have to disconnect half of the differential serial bus for communication to work, there's something wrong with your electronics! That's some pretty invasive debug code you've generated there, kudos for keeping it simple. Might I suggest in your RX debug, you test whether the correct data was received, and flash differently or something so you can see if the data is being corrupted? Accesby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Project: Teacup Firmware - 15 years ago
alianmac Wrote: ------------------------------------------------------- > So I have repeated the process looking at the > voltage on Pin 25. I believe that this is the pin > that controls the X step. The voltage on pin 25 s > 0.15V whilst the motor is inactive but only rises > to 0.35V when I issue the G1 X50 command. Is this > correct? That's exactly what I would expect if youby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Project: Teacup Firmware - 15 years ago
alianmac Wrote: ------------------------------------------------------- > Is what you were after? > > I have putty installed, or a Linux machine I could > use if you could take me through what I would need > to do. yep that's lovely. Looks to me like you have no temp sensors, so M105 is returning simply 'ok' and your reprap host is choking. nothing wrong with the firmware- it'sby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Project: Teacup Firmware - 15 years ago
alianmac Wrote: ------------------------------------------------------- > Using > reprap host 20100806 I get this message. I have > made no changes to the config.h file. show us the actual serial data going back and forth. I have no idea how to do this on windows or with reprap hostby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Project: Teacup Firmware - 15 years ago
Traumflug Wrote: ------------------------------------------------------- > 41 minutes. This was quick. May I remember you we > had a release branch already and it didn't work > out? if I recall correctly we had a less stable codebase and fewer testers. Now we're in a position where most of the groundwork is done, and most of the patches coming in are experimental things which frequentlyby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Project: Teacup Firmware - 15 years ago
ok, repository breakage complete. Since master has gone back a few commits, expect git pull to choke without some massaging. has anyone tried the sdcard, eeconfig or multi-extruder branches? They need to be merged into devel I think, or at least rebased...by Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Project: Teacup Firmware - 15 years ago
ok everyone, hold onto your hats, prepare for repository breakage. master will be stable, and I'll create release candidate and devel branches. new stuff goes into devel, when we decide whether or not we like it, it goes in rc, and when rc has been well behaved for a while it goes into master as a new versionby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Project: Teacup Firmware - 15 years ago
ok let's do it. Is 47d8de a good commit to start our stable branch at? It's close to current head, but before the controversial 'internal position in um' commitby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Project: Teacup Firmware - 15 years ago
so we need to work in absolute coordinates- that is, find the relative steps after converting um to absolute position in steps. That way we don't have any wandering because moving 100um will move 33 steps the first time, and 34 steps the next timeby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Per-Axis acceleration - 15 years ago
here it is! Well, it's a start anyway.. looks like it would spit out E steps /way/ too fast in some situations. I think that double layer bresenham will turn out to be really handy. I'm thinking that we may have to ignore acceleration and speed limits on E axis to implement this initially which I'm not particularly keen on, but I think most (all?) current machines can handle it as long as E-onlyby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Per-Axis acceleration - 15 years ago
jv4779 Wrote: ------------------------------------------------------- > send to firmware and > it responds with the prepeocessed moves and host > send them back to firmware to print, or even > better firmware stores the preproocessed data on > SD to do the print. soupcup does this. It takes too much ram and flash to fit on a '328, especially since the SD/FAT code alone takes aboutby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Project: Teacup Firmware - 15 years ago
It looks like you may have an old ThermistorTable.h. Does yours have '#define NUMTABLES 1' at the top? does the definition look like uint16_t temptable[2] PROGMEM = { ? can you git checkout ThermistorTable.h and reproduce the same error? ps: we've passed 1000 posts! thanks everyone!by Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Teacup Firmware replicatorG & Skeinforge - 15 years ago
don't use delays in interrupts. It should be fine in the main loop. If you have access to an oscilloscope it would be great to see what's happening on the serial lines. Failing that, hook some leds with suitable resistors to the serial lines so you can at least see when data is being transferred. I can't test the intercom code myself as I don't have gen3 electronics, but those who have workedby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Teacup Firmware replicatorG & Skeinforge - 15 years ago
Traumflug Wrote: ------------------------------------------------------- > However, what whould you do with the main firmware > on the extruder, other than sending G-Code back > and forth? A simple yes/no on heater and thermistor functionby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Project: Teacup Firmware - 15 years ago
your config shows a zero where your image shows THERMISTOR_EXTRUDER, the zero should work. THERMISTOR_EXTRUDER is defined in ThermistorTable.h which may not be included before config.h in some places. I think we're using the extra value to select different temperature tables for different thermistors, if you're not using that feature a zero should be fine.by Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Per-Axis acceleration - 15 years ago
Traumflug Wrote: ------------------------------------------------------- > BTW., why did you remove ACCELERATION_TEMPORAL? > Wasn't hat meant to be the algorithm of the > future? The code looked good! Except for the > missing acceleration, of course. that's why- I couldn't work out how to get the acceleration in there, so I scrapped it. There comes a time in every project's life wherby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Teacup Firmware replicatorG & Skeinforge - 15 years ago
of course you can't leave it like that.. the protocol between the main board and the extruder doesn't resemble gcode in the slightest. As you've probably already found out it's a fairly simple packed struct packet protocol, basic debug would include pulsing a led when a valid packet is received on both boards, and then perhaps use M253 to dump the received packet data and see if it looks saneby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Teacup Firmware replicatorG & Skeinforge - 15 years ago
hariseldon78 Wrote: ------------------------------------------------------- > So the question is: is there any standard way to > debug the extruder? Is there any way already in > the code to receive feedback from the extruder > firmware? sure, install teacup on the extruder - the main firmware, not the stuff in the extruder folder! You have to disable some features for it to fit, suby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Per-Axis acceleration - 15 years ago
Traumflug Wrote: ------------------------------------------------------- > - acceleration is relative to the direction of the > fast axis > > - the fast axis is both times the same so we need to calculate and keep the results for all axes, as if we were doing per-axis, but then do bresenham within the move itself for geometric precision. That'll boost the ram usage a bit - is it worby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Per-Axis acceleration - 15 years ago
I've found that in terms of accel, all we need to precalculate is start c, minimum c and decel steps for the bresenham master axis. When c <= min_c we have reached our top speed and must stop accelerating. n starts off at 5 so can be set in dda_start. we work out when to start decelerating from the master axis steps remaining counter vs decel steps. Not sure how that fits with your plans forby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Project: Teacup Firmware - 15 years ago
Traumflug Wrote: ------------------------------------------------------- > FWIW, here are two patches which reduce RAM usage > to an amount which easily allows to have an 8 line > move buffer on an '168 again. free ram is far more important than free flash. We can use up the very last byte of flash without issues, but we need free ram for our stack. if it still fits in the '168's flash,by Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Compiling Teacup Firmware, Maybe is a stupid problem... - 15 years ago
firmware already sends "start" when it begins, and is probably trying to say 'unrecognised command' or something like that in response to your messages. you could try setting the baud to a lower value and see if it works better.. in theory, 76800 baud should work best with a 16MHz crystal, see the atmega datasheet for a table of clock frequencies and baud ratesby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Compiling Teacup Firmware, Maybe is a stupid problem... - 15 years ago
try with a serial terminal. what baud rate are you using? does it match the one in your config.h?by Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Project: Teacup Firmware - 15 years ago
cloudmaker Wrote: ------------------------------------------------------- > Hy Triffid, > > on my way of getting Teacup/Ramps/ReplicatorG > playing nicely together, I had to change the > following in "gcode_process.c", because else the > homing G codes would be executed BEFORE the rest > of the queue, which is not the way it should be, > IMHO. That was fixed a month ago,by Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Project: Teacup Firmware - 15 years ago
Sergey Batalov Wrote: ------------------------------------------------------- > Hi. > I'm experiencing the same issue -- printer freezes > after few moves. > kiram9 (or anyone else), could you please describe > your solution to this problem? please check if latest head still locks your queue. The atomics patch above may well address the issue. > Software: teacup tweaked to worby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Project: Teacup Firmware - 15 years ago
I've also tried to clean up the delay stuff a bit, let me know if what I did works for everyone.by Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Project: Teacup Firmware - 15 years ago
hm, what happens when the timer compare triggers before dda_step finishes? the timer interrupt is disabled for that duration, but we re-enable it near the bottom while global interrupts are also enabled, at which point the interrupt will fire instantly- maybe this is smashing our stack? A call to cli() before set_timer at the bottom of dda_step should solve it if that's the issue. We probably shby Triffid_Hunter - Firmware - experimental, borrowed, and future
Re: Gen7...Some Issues - 15 years ago
rebecca.palmer Wrote: ------------------------------------------------------- > > Anything with an > > Rds(on)@Vgs=4.5v of around 10R will be perfect. > I think you mean 10mR... Ah yes I certainly do, thanks for picking that up!by Triffid_Hunter - Controllers
Re: self sourced electronics - 15 years ago
piezopizza Wrote: ------------------------------------------------------- > I want to self source the electronics for my first > reprap for several reasons; cost, the diy feel of > actually knowing how your machine works without > any magical black boxes, and because I really want > to learn what all those little greebles on boards > are for. I know how you feel! I would suggby Triffid_Hunter - Controllers
Re: Different MOSFET for RAMPS - 15 years ago
IRL3803 is my favourite. seems perfectly happy being driven at 62.5KHz PWM direct from my avr's output, and can carry about 15A with no heatsinkby Triffid_Hunter - RAMPS Electronics