Show all posts by user
Plastic Extruders, mostly - > http://objects.reprap.org/wiki/Extruder
Re: E-Axis Compensation MCode Proposal - 13 years ago
From a tool flow perspective I am not sure where sliced gcode compensation goes. Maybe having filament diameter in skeinforge is a bad idea and having compensation for those right at slicing time, but wrong a printing time in the firmware feels not idea either. If skeinforge output volume then we could have volume to filament feed all in one place and no compensation required, just conversion.by jv4779 - Firmware - experimental, borrowed, and future
Re: Skeinforge strips extruder code from my end.gcode - 13 years ago
I can't tell from your message if the replace has a <TAB> between the two tokens. And the "'s around the others seem strange. M101<TAB> M103<TAB> M108<TAB>;M108 M113<TAB>;M113 replace_with_g<TAB>Gby jv4779 - Skeinforge
Re: End code - 13 years ago
Skeinforge strips out E only G1 moves from the start and end .gcode files. To work around this you can follow the procedure inby jv4779 - Skeinforge
Re: Progress - 13 years ago
The firmware shouldn't drop steps since the E steps are calculated to be a precise amount of plastic for that move. A better approach, which someone did do an experimental firmware on, would be to offset the E axis into the future so that E is ramping up faster at the start and down faster before the end of a line segment. This is all under the theory that an E step has a delay, based on some cby jv4779 - Firmware - experimental, borrowed, and future
Re: Skeinforge starts slow - 13 years ago
This can happen if you have your Z axis speed limited too much in the Limit tab. The printer ends up making a long move at the slow Z axis speed and it takes forever.by jv4779 - Skeinforge
Re: Temperature Control on cnc conversion - 13 years ago
I have not run my printer off emc2 yet. Others have and most just use an arduino with standard firmware to do temp control of the extruder and possibly a heated bed. That is cheaper than a commercial temp control, unless you happen to already have one. details thevarduino route.by jv4779 - EMC2
Re: Temperature Control on cnc conversion - 13 years ago
Using the 4th axis is fine. The gcode produced by skeinforge will have this labeled a E and will need to be changed to A (or what ever rotational axis you choose). Temp control of the extruder nozzle is mostly constant temperature. There are setting in skeinforge slicer that can very the temperature for different layers of the print, but I have never used them. Stetting up a standalone temperby jv4779 - EMC2
Re: Nozzle drag - 13 years ago
ahmetcemturan Wrote: ------------------------------------------------------- > You use a workaround for something that is > implemented already? The difference is that I can adjust the first layer with one edit of the gcode without recrafting the stl. Zero height of the Z axis is a machine parameter, why would I have skeinforge compensate for it when G92 is designed for that long beforby jv4779 - Skeinforge
Re: Nozzle drag - 13 years ago
ahmetcemturan Wrote: ------------------------------------------------------- > This is only valid of course if you have set up > your Z-home to be exactly over (touching/barely > touching) your printbed. > If you have left some gap for safety (e.g 0.2mm) > You should set that in Altitude. Set it to a > negative value (-0.2 if your Z-home is 0.2mm above > the bed). G-code wiby jv4779 - Skeinforge
Re: tach_redline experimental firmware coming shortly. - 13 years ago
Any torture test needs a section of rapid short back and forth movements at different frequencies. Something like a 2 lines that are a few degrees from parallel, with solid infill between them. How a machine and firmware handles these types of very fast, short, repeated back and forth movements is important to good surface finish.by jv4779 - Firmware - experimental, borrowed, and future
Re: Sprinter (was Klimentkip/caruKlip) with acceleration - 13 years ago
Triffid_Hunter Wrote: ------------------------------------------------------- > I thought exponent was only %g and %e, but not %f? avr-libc vfscanf says they are all the same.... f Matches an optionally signed floating-point number; the next pointer must be a pointer to float. e, g, F, E, G Equivalent to f.by jv4779 - Firmware - experimental, borrowed, and future
Re: What would be the ideal (theoretical) hotend/extruder combo? - 13 years ago
Ideally the fillament drive screw would only apply downward force with no twist. Any twist can cause issues with the fillament feeding from a spool. A hobbled pully on both sides with both being driven is a good approximation to this. Jeremyby jv4779 - Plastic Extruder Working Group
Re: Sprinter (was Klimentkip/caruKlip) with acceleration - 13 years ago
The gcode "spec" does say that white space around codes and values is not signifigant and shouldn't change the meaning of a line. It also says that G90 G21 on the same line is valid. Firmwares shouldn't throw stones. The spec for float arguments is not the same as what strtod or %f mean because they both have E exponent while gcode does not. My big issue was that send.py displayed the line asby jv4779 - Firmware - experimental, borrowed, and future
Re: Sprinter (was Klimentkip/caruKlip) with acceleration - 13 years ago
Nevermind on thinking this was a Sprinter bug For future users, if you use send.py from Skeinforge with Sprinter you will have problems. send.py strips out the white space before sending the gcode to the firmware. So commands like G1 E1.12 fail to work because the firmware sees G1E1.12 and makes 1E1 into 10 when looking for the G code to do. The solution is to edit RepRapArduinoSerialSender.pby jv4779 - Firmware - experimental, borrowed, and future
Re: alternatives to current linear Bresenham algorithm - 13 years ago
I wasn't able to find any link between the non-optimal stepping of the slower axis and lower print quality. The mechanical properties of belts and motors seem to smooth it out to a non-issue as our speeds. The lag in time between when the extruder stepper turns and the actual plastic comes out and that interaction with lots of acceleration does cause quality issues. Resulting in not enough plaby jv4779 - Firmware - experimental, borrowed, and future
Re: adc conversion optimizations tonokip - 13 years ago
I don't know if Tonokip is still being activly developed. Sprinter is active and a devivitive of it. If sprinter doesn't already do out of band interrupt adc it should. Sprinter also has many other improvements too.by jv4779 - Firmware - experimental, borrowed, and future
Re: Sprinter (was Klimentkip/caruKlip) with acceleration - 13 years ago
I have printed for about 12 hours with Sprinter without any issues or missed steps.by jv4779 - Firmware - experimental, borrowed, and future
Re: Per-Axis acceleration - 13 years ago
Could this aditional level of complexity be more than AVR's can do realtime? Moving to a 2-pass strategy may be the answer. Either feed the code thru a PC side preprocesor, 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.by jv4779 - Firmware - experimental, borrowed, and future
Re: A look at firmware output quality - 13 years ago
I finished by accuracy analysis and the firmwares perform very well. post Jeremyby jv4779 - Firmware - experimental, borrowed, and future
Re: MiXley: Teacup on a ATmega32U4 - 13 years ago
Might be much easier to use Klimentkip/Sprinter as a base to port. That code doest use timers for the step timing and would remove some of the issues with interrupt race conditions.by jv4779 - Firmware - experimental, borrowed, and future
Re: A look at firmware output quality - 13 years ago
I had been using EMC2 as a constrast to how normal reprap firmwares operate. I ran with G64 of 0.05 as value that meets the repraps usual goal of 0.1mm resolution and still get some thing out of a robust path planner. The example with default tolerance should effect print quality. Step timing jitter doesn't have much effect on quality as long as the jitter isn't faster than the steppers can keby jv4779 - Firmware - experimental, borrowed, and future
Re: A look at firmware output quality - 13 years ago
I believe the next evolution is a host side talker that accept gcode, preprocesses it for path planning and step profiles, and handles all the serial protocol with the micro. Aka the nophead method without a network link. That might be the only fix for the off axis step jitter. I have not published this, but the steps of EMC2 are beautiful. They do it with a constant 25us step loop that stepsby jv4779 - Firmware - experimental, borrowed, and future
Re: A look at firmware output quality - 13 years ago
I added another "firmware" to the results. Running the same gcode via EMC2 has some rather surprising results. I know the path planner in EMC2 can be adjusted to different following thresholds. On the plus side the circles are round again. I would love to hear about any methods to get a good metric for the step timing jitter. The timing artifacts on the minor moving axis caused by Bresenham'sby jv4779 - Firmware - experimental, borrowed, and future
Re: Project: Teacup Firmware - 13 years ago
Teacup doesn't work on an UNO because the optiboot loader leaves timer 1 partially configured. This can be fixed by updating the UNO bootloader or by doing "TCCR1B = 0;" before doing any other timer initialization in Teacup code. Jeremyby jv4779 - Firmware - experimental, borrowed, and future
A look at firmware output quality - 13 years ago
I put up a quick blog post on some initial quality firmware quality findings. I have not been able to get the official firmware to run correctly so it is missing from the results. Some ideas for future studies include step pulse jitter, verify that input gcode and output path agree, verify the max movement speed matches the gcode F value, time gaps between G1 commands, max step rates, max gcby jv4779 - Firmware - experimental, borrowed, and future
Re: Project: Teacup Firmware - 14 years ago
If an endstop is triggered during normal, non homing, operations I doubt there is a sane way to handle it. Every scenario I can think of would ruin the print. You are betting off stopping the gcode processing and waiting for user intervention. Lets say you want the safest way to keep going... Record where the endstop hits, don't allow that axis to keep stepping in that direction but recordingby jv4779 - Firmware - experimental, borrowed, and future
Re: Generation 7 Electronics Development - 14 years ago
Traumflug Wrote: ------------------------------------------------------- > jv, > > that makes some sense. You want all DIR pins of > the steppers on one 8 bit port, so the firmware > can AND the bits together before setting them, > instead of setting them one by one. The STEP pins are the important ones to me. Having DIR all on one PORT would be a bonus. I think the DIR onlyby jv4779 - Next Wave Electronics Working Group
Re: Generation 7 Electronics Development - 14 years ago
Traumflug Wrote: ------------------------------------------------------- > Yes, this logic sounds good and reasonable. > However I can't see how one would "select" a > stepper driver to do a step or not, unless they're > on different ports. These drivers have only two > relevant pins: STEP: "do a step now" and DIR: "do > it normal vs. do it reversed". There's also an > ENABLEby jv4779 - Next Wave Electronics Working Group
Re: pololu stepper driver is dead - do I need to pullup ENABLE? - 14 years ago
Does this LED setup work for micro stepping? I assumed the LEDs would be driven off the STEP/DIR inputs to the driver.by jv4779 - Controllers
Re: Generation 7 Electronics Development - 14 years ago
Traumflug Wrote: ------------------------------------------------------- > * There was also a suggestion to put all pins of > the stepper motors on one port. It was discarded > because it makes no difference for the motors. But > what about the software? This could save some cpu > cycles for each interrupt. Just 7 more cycles each > interrupt can make a big difference. > >by jv4779 - Next Wave Electronics Working Group