Quotentwrkguru I need some help getting my K8200 working properly. It's assembled and tested, but can't figure out why the X and Y axes skip. Posted at the Velleman forums, but not so much feedback yet. I'm close to Downingtown @aBrainDump...just up 202. Axis skipping can have several reasons: - overheated stepper drivers (are they hot to the touch when they're skipping?) - Stepper drivers notby stefanst - Pennsylvania RepRap User Group
Turn the endstops off in the firmware - you should be able to zero manuall (try the G92 command). If you still get the same problem, you know it's not endstops! BTW: it may be easier to help you diagnose, if we knew, what it is supposed to look like! For all I know this is perfectly OK... STby stefanst - Firmware - experimental, borrowed, and future
Hi Sublime, I just uploaded the latest version. I had to modify the config some, because my pin-outs are different from RAMPS and I'm using gears with unusual numbers of teeth, but other than that it worked out of the box. The only odd thing was that the speed for the Z-Axis changed. The approximate velocity I used to get when setting it to 300mm/min I now get at 100mm/min or so. This does seemby stefanst - Firmware - experimental, borrowed, and future
Total noob mistake. Traumflug & Triff please forgive me! From another project I still had the UNO selected under boards. Changed to MEGA and everything's working. Doh!by stefanst - Firmware - experimental, borrowed, and future
I just downloaded the latest version: commit a6e2a10f10 I'm trying to upload/ compile using the Arduino IDE. Tried versions are 0.23 and 1.0 No such luck - it always throws the same error at me: config.h:33:3: error: #error RAMPS has 1280/2560! set your cpu type in Makefile! I get that multiple times - looks like any time it parses the config.h file. I uncommented the following line in the makby stefanst - Firmware - experimental, borrowed, and future
Hi Tech Geek, I'm currently not using my Mendel, so you can borrow it to print your parts if you'd like. STby stefanst - Pennsylvania RepRap User Group
I have a functioning Mendel in Levittown, PA. Approx. 20 minutes northeast from Philly. STby stefanst - Pennsylvania RepRap User Group
If you still need those parts, let me know. Otherwise please close the thread! STby stefanst - New Jersey RepRap User Group
Hi LDlsection08! and welcome tot he NJ user group. I'll happily print the needed parts for you - but you would either have to pay for the material, or provide me with some. There are also plenty of questions as to what parts you need - Prusa does not equal Prusa. As I'm running an original Mendel myself, I can't make educated suggestions as to what versions to use... And then there's the questiby stefanst - New Jersey RepRap User Group
I had a very similar problem with circles coming out 0.5mm off in one direction. In my case the X-Axis was shorter than it was supposed to be. It turned out that I was using XL belts on both axes, but my pulley for the x-axis was for a 5mm belt and not an US-style XL belt. So on each reversal my X-Axis lost roughly 0.5mm Replaced the pulley with a new XL pulley and no more problems. STby stefanst - General Mendel Topics
Quotenophead Not a good assumption. When the last filament of an infill is being injected into the remaining trench it does require more pressure than the first outline. Also unless the bed is absolutely level the pressure during the first layer will vary. When spanning a bridge it will be less also. I would agree with the infill injected into the last trench requiring more pressure. Ignoring thby stefanst - Firmware - experimental, borrowed, and future
I gave this some thought too. I fully agree with Triffid_Hunter. The speed of the extrudate (volume flow) coming out of the nozzle must be the same as the as the speed at which the nozzle moves over the bed. For infinitely long lines at constant speed we don't have a problem, but unfortunately our print-heads do start and stop! The volume flow of extrudate should be influenced by two main factoby stefanst - Firmware - experimental, borrowed, and future
jim_blag Wrote: ------------------------------------------------------- >.... > I then decided to look at the retractions. There > are a lot of retractions that are unnecessary, > they cause more of a blob due to the pause then > they would if the head just moved straight away. > So I wrote a script that removed any retractions > where the next move was less than 1mm away.by stefanst - General Mendel Topics
What Firmware are you using? I'm using Teacup and have a similar issue using the standard host SW. Try using something REAL simple like send.py This may also be a topic more for the Host Software or the Firmware sub-forums.... STby stefanst - General Mendel Topics
awmt102 Wrote: ------------------------------------------------------- > Hi, > > No I am not using a DC motor. I have since > realised that E_STARTSTOP_STEPS is there to > provide stepper motor reversal. I have been paying > with the value but still get very stringy prints. Skeinforge (at least version 41) has settings under the dimension setting that automatically enter retraby stefanst - Firmware - experimental, borrowed, and future
I had the same issue, but using Teacup. Single commands worked fine, but I couldn't get it to print. Sometimes the firmware and the host software don't like each other. I assume the FW is sending something the host SW doesn't know what to do with, or it isn't sending something that's expected. Switch to send.py and see if that works for you. Don't know how it works on Windows, but I have printedby stefanst - Reprappers
Whoohooh! Congrats Architect: Printed objects - that's in the end what it's all about. Or was that the hokey-pokey? STby stefanst - Firmware - experimental, borrowed, and future
jim_blag Wrote: ------------------------------------------------------- > I just pulled version e05e12c and tested it. > Unfortunately, it still hangs with M101 commands > on my Gen6. > > JB I have the same issue. It was actually reported earlier. I never figured out what causes it - I just replaced the M101s with "G1 E1.7 F1500" and the M103s with "G1 E-2.0 F1500". That worked wby stefanst - Firmware - experimental, borrowed, and future
Alright - I tried out running Repsnapper on Linux (Ubuntu 11.04) running on VM on my Win7 laptop. And we get perfect temperature readings. This confirms that the M105 problem is caused by software. So either Win7 64bit or the Repsnapper for Windows are somewhat problematic with handling this specific piece of information from the firmware. Conclusion: Use command line tools when working with Teaby stefanst - Firmware - experimental, borrowed, and future
Triffid_Hunter Wrote: ------------------------------------------------------- ... > 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 math works is it figures out > how far along the movement vector we are when eby stefanst - Firmware - experimental, borrowed, and future
Thanks! with more acceleration (850mm/s^2) I do get better results. Now I'm getting to the unfortunate point where my x and y could probably take some more acceleration but my Z-Axis really can't. Since the limiting of the Z-movement in the Teacup firmware still doesn't seem to work, no matter how I set things up, this is what's limiting my quality at this point. I'll try and crank up the currenby stefanst - Firmware - experimental, borrowed, and future
Sublime: this looks extremely nice. I would certainly be happy with results of this quality. I'll return to f555887eb58ca1adcd1b and use your settings and see if it helps improve matters. I may not be able to accelerate at the same levels you are using since my X-Axis is likely much heavier than yours. What are you using for slicing?by stefanst - Firmware - experimental, borrowed, and future
Vato Wrote: ------------------------------------------------------- > The printer prints multiple layers. Then there is > a shift along the axis of y and z. Naturally, > further printing is meaningless. What could it be? A shift along the Y-and X-Axis is usually caused by missed steps. Meaning that your firmware is issuing step commands that your hardware can't execute. This happens wheby stefanst - Firmware - experimental, borrowed, and future
sliptonic Wrote: > I'm seeing the same thing. I think your > workaround is analogous to using the retraction > settings on the SF40 Dimension plugin. I get > exactly the same kind of start/stop behavior that > I show here: > > > I have E_STARTSTOP_STEPS set at 2000 with 16x > microstepping and get lots of blobs/strings. I think you're correct - using the SF settinby stefanst - Firmware - experimental, borrowed, and future
Downloading the latest version of Teacup (b39a7b8) seems to have fixed the problem with the Z-Axis exceeding the max. allowed. So one down! In the meantime I've been busy printing some upgrades. On the M101 and M103 issue: M101 seems to do what is asked of it - forwarding the filament a certain number of steps, however, M103 seems to do nothing. This is only confirmed with the version that was Mby stefanst - Firmware - experimental, borrowed, and future
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. The only way I was able to print was using send.py. That however seems to be running very stable. I printed an X-Axis motor bracket whicby stefanst - Firmware - experimental, borrowed, and future
Believe it or not, I was indeed planning on helping with the wiki. But at first I actually have to know what I'm doing. The only thing worse than no advise is bad advise!by stefanst - Firmware - experimental, borrowed, and future
It is a laptop indeed. In order to quickly verify if ground problems play a role I unplugged it and let it run off the battery. No change, so I think the issue must be sthg. else. And the fact that I get "good" data using the Linux PC and that the PID is working properly, even when M105 reports false data, indicates that it is indeed a communication issue and not an electronic issue. I'll see whaby stefanst - Firmware - experimental, borrowed, and future
Triffid_Hunter Wrote: > Good to hear that we're chewing through your > issues I'm very glad myself. No pain - no gain! This has been the steepest learning curve in quite a while for me. But the support in the forums is absolutely outstanding. Now if just the documentation in the wiki were 10% as good as the forum support ;-)by stefanst - Firmware - experimental, borrowed, and future
Triffid_Hunter Wrote: ------------------------------------------------------- > stefanst Wrote: > -------------------------------------------------- > ----- > > Any idea on why my extruder isn't retracting? > > Does your gcode contain M101 and M103 words? we > use those to trigger retraction and preload. > > We don't yet the differences between moves at the > moby stefanst - Firmware - experimental, borrowed, and future