slic3r reads binary STLs perfectly for me, at least the ones that cloud.netfabb.com and plater generate!by Triffid_Hunter - Slic3r
fwiw, I find slic3r's gcode to give me absolutely incredible dimensional accuracy. I'm not sure if it's because I force a particular extrusion width or if the accuracy is as good when it chooses the width itself. I can comfortably create holes in my model with a precision of 0.1mm and they come out perfectly in the resulting print, either horizontally or vertically. I can make about 0.05mm spacby Triffid_Hunter - Slic3r
Teacup already does what you just altered sprinter to do, hence the saner pulse widthsby Triffid_Hunter - Firmware - experimental, borrowed, and future
Dave X Wrote: ------------------------------------------------------- > I have a couple teensy boards lying around, and it > looked like it would fit: 25 IO/11analog 7 PWM, > USB, 32K. Assuming 32k is enough for teacup and the LUFA usb<->serial library, you should be good. Beware of ram usage, we need at least a couple k unused for stack. > There seem to be a couple significby Triffid_Hunter - Firmware - experimental, borrowed, and future
Sublime Wrote: ------------------------------------------------------- > Also G28 is not a homing code but the early RepRap > firmware improperly implemented it as homing and > sprinter, marlin etc have continued doing it > wrong. Teacup is the only firmware for RepRap that > I know of that implemented the code correctley. G28 now causes teacup to home, so as to be compatible withby Triffid_Hunter - Slic3r
I use a 12v, 50w downlight as a 5v load on mine, works perfectly and doubles as a work lightby Triffid_Hunter - General
ramps doesn't support anything smaller than the 1280. no current reprap electronics use a 328. the errors you're seeing are accurate- after you defeated the CPU check, you get the reason we have a CPU check in the first place- RAMPS uses a lot of pins that don't exist on the 328! perhaps you've selected the wrong config? you may also wish to find out which chip you actually have!by Triffid_Hunter - General
ooh I didn't mean for you to use the hysteresis when turning the heater on and off! it'll never settle down like that! I meant more like this: currentTemp = tempSensor->getTemp(); if (currentTemp > MAXTEMP) { // error condition! power down! targetTemp = 0; powerOff(); sendMessageToHost("heater exceeded safety limit! shuttiby Triffid_Hunter - Firmware - experimental, borrowed, and future
awesome, thanks for bearing with me Just one more thing: like sjfw, you have a very simple test for 'on target'. There are quite a number of reprappers (including myself) who swear by hysteresis and residency- that is, the actual temperature must be within +/- for seconds before 'on target' is asserted. This means that if we have a hot-end with overshoot, we can make it wait for the oscillaby Triffid_Hunter - Firmware - experimental, borrowed, and future
hardtoe Wrote: ------------------------------------------------------- > once the queue has an item to process, the > pipeline stage will retrieve the command from the > queue and process it. then it will use the > protothread library to wait for space in the > destination queue to put the results. > > the CircularBuffer class is managed internally > using size, enqueuePby Triffid_Hunter - Firmware - experimental, borrowed, and future
Getting rid of the reliance on speedy ramp generation for eradicating inter-move delays is interesting with this architecture- you need to somehow insert a marker to pull the next set of directions and step masks into the step time queue- perhaps a zero value, or a -1? Then you can queue up multiple blended moves if possible/necessary complete with direction changes. hardtoe Wrote: -------------by Triffid_Hunter - Firmware - experimental, borrowed, and future
buket of water Wrote: ------------------------------------------------------- > now to work out why my stl files come out really > tiny. > im using solidedge v18. you're probably exporting with units set to inches. Reprap is a metric project, so everything expects millimeters. You need to either scale them by 25.4, or tell your CAD program to export with millimeter units.by Triffid_Hunter - Australia, Brisbane RepRap User Group
more likely that the pololu is dead, switch the motor with a working one and see what happens. ps: we're all using pronterface and sfact instead of repsnapper these daysby Triffid_Hunter - Australia, Brisbane RepRap User Group
fyi, teacup has a 4-D bresenham implementation that can easily be extended to any number of dimensions, and does not store any concept of a master axis. It's hard-coded for 4 but could easily be stuck in a 'for' loop or a C++ class. buffering step times is an interesting optimisation, you could fill it easily during coast. As we tend to use pretty high accel if we can get away with it, even a smby Triffid_Hunter - Firmware - experimental, borrowed, and future
Traumflug Wrote: ------------------------------------------------------- > I think eeconfig could be generalised to a runtime > configuration system > > I think you're the natural candidate to do this. possibly, perhaps someone will beat me to it.. I haven't looked at that code in so long that I'd be seeing it with fresh eyes anyway! > BTW., your pushes didn't hit the public yetby Triffid_Hunter - Firmware - experimental, borrowed, and future
I think eeconfig could be generalised to a runtime configuration system like sjfw. then if we add SD card autorun.g support, we can store the configuration on a SD card. I've pushed all my interesting local branchesby Triffid_Hunter - Firmware - experimental, borrowed, and future
MicWit Wrote: ------------------------------------------------------- > Cool, thanks for that. Still close enough that I > can call in when on the way up the coast sometime. sure, I'm up for that > Do you sell any (even if they are pre-ordered on a > per order basis) kits that have all the parts > (even the ones sourced from elsewhere)? I fully intend to do exactly that, howeveby Triffid_Hunter - Australia, Brisbane RepRap User Group
I've started a web shop at Create3D.com.au if you're interested, although I'm closer to tweed nowby Triffid_Hunter - Australia, Brisbane RepRap User Group
using 4.7 instead of 6.8 is fantastic, I think nothing of warm-up times with a 4.7by Triffid_Hunter - Firmware - experimental, borrowed, and future
ADC6 and ADC7 are analog inputs only, they cannot be used for GPIO. PINC6 is totally separate from ADC6. For some reason, they're set as inputs in io_init, which assumes that they're dual analog/gpio pins. you should be safe to comment out lines 25 and 26 in extruder.c so it'll behave. we probably should alter the definitions for AIO6 and AIO7 in arduino_168_328p.h to find other spots where weby Triffid_Hunter - Firmware - experimental, borrowed, and future
so.. marlin handles endstops poorly? still sounds like a firmware bug to me- sprinter does something sensible in this situationby Triffid_Hunter - Firmware - experimental, borrowed, and future
brnrd Wrote: ------------------------------------------------------- > I'll give this a try then. > > Right now, I just want to be able to print even at > 40 mm/s without the head vibrating and creating > blobs when going around curves and circles. I'm > not going after super high res or supersonic speed > yet. this requires trajectory planning and move blending, somethingby Triffid_Hunter - Firmware - experimental, borrowed, and future
Traumflug Wrote: ------------------------------------------------------- > A longer > movement will fill the whole movement queue, so > there's nothing to prepare if a few quick ones > follow. I think what you mean to say is, a longer movement allows the move queue to fill with prepared moves, so a subsequent few very short moves will have no delay. And by "very short", we mean downby Triffid_Hunter - Firmware - experimental, borrowed, and future
brnrd Wrote: ------------------------------------------------------- > I've tried a couple of times but I've never been > successful in running my Mendel with RAMPS 1.2 > with Teacup. One problem that I have is that I > just can't get to all the source codes when I open > it in Arduino. There's not enough horizontal room > to show all the tabs and not enough vertical room > tby Triffid_Hunter - Firmware - experimental, borrowed, and future
BenJackson Wrote: ------------------------------------------------------- > The startup problem is solved with a silicone > wiper. That's one feature of my MakerBot that I > really miss on my Prusa. The wiper makes it > possible to create a startup sequence that starts > raftless prints consistently. My printer has an X position that's beyond the edge of my bed. I simply wipe myby Triffid_Hunter - Firmware - experimental, borrowed, and future
if I recall correctly that was intended to protect the timer variables during setTimer(), and between setTimer() and rti. The step interrupt is re-enabled during setTimer(), so if we're running /really/ fast, we might trigger between there and rti. We absolutely do not want to re-enter the step interrupt before returning from it, or we will definitely end up smashing our stack! If code has chanby Triffid_Hunter - Firmware - experimental, borrowed, and future
if you want to do your own retraction or whatever at the end, G92 E0 first!by Triffid_Hunter - General
My printer uses M6 threaded rods. I have simple vinyl tube connecting them to my Z motors, for a (very!) flexible connector. One of my rods waves around like a worm half out of the ground, yet my walls show zero sign of misalignment as a result. I am thinking of getting into making kits here in Australia, and after reading this thread my idea of keeping the M6 rods for Z seems far more sensibleby Triffid_Hunter - General
Andrew Diehl Wrote: ------------------------------------------------------- > Is there a simple way to change the jerk value in > the firmware? It would be cool if this was > something that could be included in the config > file to tinker with. not implemented yet unfortunatelyby Triffid_Hunter - Firmware - experimental, borrowed, and future
instead of a particular angle, we usually use a 'jerk' value- an instantaneous change in velocity on each axis. This is effectively used as a start/stop speed, as well as a blend value on curves. Any sharper curves must ramp to a velocity where the jerk isn't exceeded. We can't just look at two adjacent moves either- in the case where we're going fast and a gentle curve ends in a sudden sharp coby Triffid_Hunter - Firmware - experimental, borrowed, and future