cloudmaker Wrote: ------------------------------------------------------- > Using Teacup (Master Branch from 15 > may),Ramps,ReplicatorG. > > acceleration = reprap > extrusion set to relative > > Encounter the following problem: (occurs with > Skeinforge35,39 and also with Skeinforge40 > generated GCodes) > > After printing the first layers of a single walledby Triffid_Hunter - Firmware - experimental, borrowed, and future
Teacup already does something similar to this. It continually samples the ADC inputs in an interrupt loop, and fills a volatile array with the results so any code that wants a reading has instant access to them.by Triffid_Hunter - Firmware - experimental, borrowed, and future
My electronics is in a state of disarray after receiving a mega and a bunch of printed parts to further advance my printer, so I can't be terribly helpful right at this moment. Feel like doing a git bisect to try and track down a commit that introduces this regression, since you've found a good and a bad commit?by Triffid_Hunter - Firmware - experimental, borrowed, and future
jim_blag Wrote: ------------------------------------------------------- > A Portmon trace of the Serial comms shows that > Teacup is returning the correct values, but oddly, > RepSnapper M105 response works with Sprinter FW > though. I'm not sure I understand why that is. Would have to dig around in repsnapper source to figure that one out.. maybe they're using some weird version ofby Triffid_Hunter - Firmware - experimental, borrowed, and future
that extract.py works like this for me: python2.6 extract.py && cat gcode_doc.txt doesn't work in python3 and doesn't have a shebang so can't be called directlyby Triffid_Hunter - Firmware - experimental, borrowed, and future
Jens_R Wrote: ------------------------------------------------------- > I removed that code and now it works fine for me. Cool, so that was the problem with your X endstop? I'll put that one down as a bug for backporting to master aka47 Wrote: ------------------------------------------------------- > Guys as ever great things happening here. > > Just been having a play with the extby Triffid_Hunter - Firmware - experimental, borrowed, and future
Jens_R Wrote: ------------------------------------------------------- > It is stuck inside the home loop, so I can't run > M200 without doing a reset. I can do several g161 > in a row without problems, if fails only after I > run a g0. What is strange is that all the endstops > are on portb, which is only used by the heaters > otherwise. None of the stepping or movement code >by Triffid_Hunter - Firmware - experimental, borrowed, and future
Jens_R Wrote: ------------------------------------------------------- > I could imagine that some configuration of the > x_min input gets lost, but I've got not enough > experience with the platform to debug this. Does > anyone have suggestions what to look for? I did a > grep on the Teacup sources, and the configuration > of the input pin is only touched at startup. this is aby Triffid_Hunter - Firmware - experimental, borrowed, and future
brnrd Wrote: ------------------------------------------------------- > Does sprinter work with the reprap host? reprap host is well known to be broken, and I've been finding that all the graphical hosts have issues. Kliment's pronsole seems to be far more reliable. Other command-line based hostwares seem effective too, such as send.py and Teacup's func.sh:mendel_print. I have no idea why mixby Triffid_Hunter - Firmware - experimental, borrowed, and future
stefanst Wrote: ------------------------------------------------------- > Here you go mentioning Soupcup again! That is of > course wetting my appetite. Is this at a stage > where we can try it out? I'm always willing to > assist with troubleshooting whatever will run on > my hardware. It's at the stage where it accepts gcode with a fairly generic parser, performs a lot of fancy mby Triffid_Hunter - Firmware - experimental, borrowed, and future
stefanst Wrote: ------------------------------------------------------- > Triffid: > How difficult would it be to implement separate > acceleration values for the different axis? the code is already in soupcup, I just need to port it across at some point. I'm planning on working out how to implement a start/stop speed too so I can put all the math in at once. Basically the way the matby Triffid_Hunter - Firmware - experimental, borrowed, and future
this pdf is an interesting read, especially page 15by Triffid_Hunter - Firmware - experimental, borrowed, and future
jamesdanielv Wrote: ------------------------------------------------------- > thanks. so basically there is minimal benefit as > long as your not doing check-sum right? why would checksumming make any significant difference?by Triffid_Hunter - Firmware - experimental, borrowed, and future
jamesdanielv Wrote: ------------------------------------------------------- > anther thing. atmel data sheets state ATmega1280 > has 8k of sram why not increase buffer to use 4k? You have to be careful of the stack. On atmegas, it starts at the end of RAM and builds backwards towards the start. There is NO provision for detecting if it's encroached on variable space (which builds up fromby Triffid_Hunter - Firmware - experimental, borrowed, and future
It's a lovely algorithm, but we need to rearrange it into a midpoint (bresenham) style algorithm: Say we divide a 2D space into regular rectangles (not squares! X and Y can have different steps/mm! A square is a special type of rectangle). We have a current rectangle, and we need to know which of the 8 neighbouring rectangles is closest to the bezier curve, moving in the proper direction. If weby Triffid_Hunter - Firmware - experimental, borrowed, and future
heh again with graphical talkers being the issue... That's a serious amount of debug code you've dropped into teacup! There's a few of your features that jump out at me as being useful: * always check endstops- I think we've had this feature on and off, maybe setting it per axis is a good idea * fan over intercom- is this just an extension of the GPIO features of the intercom protocol? setting Dby Triffid_Hunter - Firmware - experimental, borrowed, and future
Sublime Wrote: ------------------------------------------------------- > I just added active cooling and I am having a hard > time reaching my target temp of 220 because of a > small amount of air hitting my heater block. It > hovers around 217.25, I do plan to insulate the > heater block to solve the problem but wondered if > there was a way to increase the output. After >by Triffid_Hunter - Firmware - experimental, borrowed, and future
stefanst Wrote: ------------------------------------------------------- > I've been busy printing some new parts for the > Mendel, so I have not been able to check into this > problem in more detail. But at least my Mendel is > working with my home-built electronics running > Teacup! The results are OK-ish so far, but I'm > sure I can improve. congratulations! Always good to aby Triffid_Hunter - Firmware - experimental, borrowed, and future
hariseldon78 Wrote: ------------------------------------------------------- > you are right it's something other. i edited the > message, please look it. is it possible to talk on > irc or google chat or something? #reprap on irc.freenode.net is very activeby Triffid_Hunter - Firmware - experimental, borrowed, and future
floating point is not forbidden in steps_per_mm defines, mine were as follows to generate the output above: #define STEPS_PER_MM_X 10.0 #define STEPS_PER_MM_Y 10.0 #define STEPS_PER_MM_Z 1000.0 #include #define STEPS_PER_MM_E (3200.0 * 39.0 / 11.0 / 6.75 / M_PI)by Triffid_Hunter - Firmware - experimental, borrowed, and future
cannot reproduce: start ok M114 ok X:0.000,Y:0.000,Z:0.000,E:0.000,F:50 X:0,Y:0,Z:0,E:0,F:50 UMX:100,UMY:100,UMZ:1,UME:1 G1 X0.1 ok M114 ok X:0.100,Y:0.000,Z:0.000,E:0.000,F:50 X:100,Y:0,Z:0,E:0,F:50 UMX:100,UMY:100,UMZ:1,UME:1 G1 Y0.1 ok M114 ok X:0.100,Y:0.100,Z:0.000,E:0.000,F:50 X:100,Y:100,Z:0,E:0,F:50 UMX:100,UMY:100,UMZ:1,UME:1 G1 X0 ok M114 ok X:0.000,Y:0.100,Z:0.000,E:0.000,F:50 X:by Triffid_Hunter - Firmware - experimental, borrowed, and future
that looks toally wrong, I'll see if I can reproduceby Triffid_Hunter - Firmware - experimental, borrowed, and future
jim_blag Wrote: ------------------------------------------------------- > @Triffid_Hunter: Quick question about G161. It's > not listed on the RepRap GCodes page, but based on > the comments in the code I get the general gist of > what it is supposed to do. However, when I send > the command the axis moves away from the Min > Endstop. > > If I nudge the axis in the positiby Triffid_Hunter - Firmware - experimental, borrowed, and future
jamesdanielv Wrote: ------------------------------------------------------- > also there is something on arduino form to sleep > the cpu during analog sample. technically it's a good idea, but we can't afford to shut down the timers or our step rate will get mangled, so that one's out for teacupby Triffid_Hunter - Firmware - experimental, borrowed, and future
Since the pic32 and other larger variants are so much more capable than the atmega, check out Soupcup as another possibility for your codebase. It's another project I'm working on rather more quietly than teacup, with quite a different approach. I intend to run them both in parallel since they have quite different design goals and fill different niches in the firmware field. Soupcup is where I inby Triffid_Hunter - Firmware - experimental, borrowed, and future
Sublime Wrote: ------------------------------------------------------- > Unfortunately reducing the acceleration makes > curves really really really slow. We actually need > a minimum constant speed to be ramping up > from so the acceleration can be set somewhere > usable. I'm in the process of preparing myself to write exactly that. The reprap acceleration already has the math, aby Triffid_Hunter - Firmware - experimental, borrowed, and future
jim_blag Wrote: ------------------------------------------------------- > * With the latest RepSnapper I don't get reliable > temperature readings (e.g. switch heat on and > temperature stays the same, never indicates > correct temp). The value used by the Teacup FW > must be correct, since it does start to switch the > heater off by watching the flashing of the LED. This is aby Triffid_Hunter - Firmware - experimental, borrowed, and future
nophead Wrote: ------------------------------------------------------- > Sounds more like an electronic problem with ground > noise than an OS / host problem. The two numbers > seem to correspond with the 0 and full scale ADC > values. How would the host produce those other > than by an amazing coincidence? > > Would the Windows PC be a laptop by any chance? A fine point yoby Triffid_Hunter - Firmware - experimental, borrowed, and future
stefanst Wrote: ------------------------------------------------------- > Now if just the > documentation in the wiki were 10% as good as the > forum support ;-) please, feel free to close that gap! I'm too close to the code to have the slightest idea of how the wiki could be more helpful. And as sebastian bailard (our magnificent library gnome) keeps saying, as soon as you enter thisby Triffid_Hunter - Firmware - experimental, borrowed, and future
stefanst Wrote: ------------------------------------------------------- > A clear case of "DOH!" > Somewhere in the wiki I read that M103 and M101 > have been deprecated, so I spent some time in > figuring out how to remove them from my gcode > generated by SF. Turning them back on should be > very easy. Heh yep they are deprecated in favour of E words for actually running thby Triffid_Hunter - Firmware - experimental, borrowed, and future