GCode vs Firmware

[Cymon]

There are still things I don't understand and can't find answers for. Maybe this isn't the right place to ask these questions. If not please let me know.

If I connect my replicator to RepG and go to the On Board Settings menu I can change the acceleration settings. So what if I lower those values so that within a single gcode command it doesn't get up to the speed specified? To me this means that the speed, particularly on highly detailed builds, has as much to do with the speed specified when building the gcode as the acceleration settings on the board. Is that right?

Which brings me to my next question. Why is speed being set in the gcode at all? Why doesn't gcode describe only the geometric movements aka "go here, start extruding, go here, go there, go there, stop extruding" and let the firmware handle how fast it gets there and how much stuff it extrudes? It is a pain having to rebuild my gcode files when the geometry of the shape hasn't changed. What if we could add a measuring device to your incoming filament to measure diameter and adjust accordingly so I didn't have to fiddle with that setting either?

[Adan Akerman]

The auto-filamentometer thing really appeals to me. On the one hand, sure: this is a cheap machine, and you have to trim some frills. On the other hand filament variability, both from manufacturing as well as environmental instability, sure seems to be one of the single biggest causes for weird variability. It also prevents us from simply reprinting a given part with different filament colors if those colors have different diameters. And, as home re-grinder / re-extruders get to be available to us this problem is likely to get worse. I find it hard to imagine we're going to be getting 0.001mm diameter tolerances from a Filabot. 

Mounting a filament measurement system on the 'bot would not be challenging mechanically but I can see how it would require a complete firm/software rethink. If the filament diameter is currently taken into account at the time of slicing, that's much too far upstream for any on-machine measurement to have an influence.

On the other hand, you could, at the time of slicing, specify a nominal (3mm vs 1.75, etc.), have it create the gcode with perfection in mind, and then the firmware could take input from the Filamentometer and just apply a correction factor to any extruder commands at the moment of extrusion. Is there a chance that might work?

I'm a mech-biased person, though... I could probably make a fun little diameter measurement system, but I'm not likely to be denting the code challenges in a hurry! I'd just have a sad output plopping values into the void... waiting for some code to come along and care what it had to say... 

Adan

--
You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
To view this discussion on the web visit https://groups.google.com/d/msg/makerbot/-/JC5r4IpAHOMJ.
To post to this group, send email to make...@googlegroups.com.
To unsubscribe from this group, send email to makerbot+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.

[Cymon]

I would generate the gcode with a filament diameter of 1 and scale it up from there in the software.

Ugh, projects. Projects I don't need.

Adan

To unsubscribe from this group, send email to makerbot+unsubscribe@googlegroups.com.

[Adan Akerman]

I know, right? :-)

To view this discussion on the web visit https://groups.google.com/d/msg/makerbot/-/fipJKgYhOJcJ.

To post to this group, send email to make...@googlegroups.com.

To unsubscribe from this group, send email to makerbot+u...@googlegroups.com.

[Joseph Chiu]

I would love to do this too. I think a viable approach is to hack up the sensor/DSP used in laser mice or a linear ccd to image the filament diameter.

I would also love to see a data standard for describing filament in xml and eeprom formats. That way temperatures, nominal diameter, and other details (starting filament length, estimated used, filament density, max temp, color and opacity) can be represented more uniformly.

[Adan Akerman]

I started thinking about an optical method too... but then I got scared of the challenge posed by different filament opacities, etc. Others with more experience than I may know of lighting tricks that render such issues moot. Regardless of the measurement method, it probably requires multiple measurements, as the filament is rarely round, bless its heart. 

[Zip Zap]

A smarter firmware definitely is the goal.  That's why Jetty firmware was developed.

---

From: Cymon <joeal...@gmail.com>
To: make...@googlegroups.com
Sent: Tuesday, July 3, 2012 10:52 AM
Subject: [MakerBot] GCode vs Firmware

There are still things I don't understand and can't find answers for. Maybe this isn't the right place to ask these questions. If not please let me know.

If I connect my replicator to RepG and go to the On Board Settings menu I can change the acceleration settings. So what if I lower those values so that within a single gcode command it doesn't get up to the speed specified? To me this means that the speed, particularly on highly detailed builds, has as much to do with the speed specified when building the gcode as the acceleration settings on the board. Is that right?

Which brings me to my next question. Why is speed being set in the gcode at all? Why doesn't gcode describe only the geometric movements aka "go here, start extruding, go here, go there, go there, stop extruding" and let the firmware handle how fast it gets there and how much stuff it extrudes? It is a pain having to rebuild my gcode files when the geometry of the shape hasn't changed. What if we could add a measuring device to your incoming filament to measure diameter and adjust accordingly so I didn't have to fiddle with that setting either?

--
You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
To view this discussion on the web visit https://groups.google.com/d/msg/makerbot/-/JC5r4IpAHOMJ.
To post to this group, send email to make...@googlegroups.com.

[Cymon]

My vision is something mechanical. A super sensitive analog switch on an arm that rests against the filament as it comes in or something like that.

[Ward Elder]

Maybe two switches at 90 degrees to better check for “round”.  Not perfect but fairly simple.

 

 

Thank you,

 

 

Ward M. Elder

Eldersoft

42 Appleton St.

Winnipeg, MB

R2G1K5

(204) 791-7754   (Cell)

wa...@eldersoft.ca

Adan

To unsubscribe from this group, send email to makerbot+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.

--
You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.

To view this discussion on the web visit https://groups.google.com/d/msg/makerbot/-/fipJKgYhOJcJ.

To post to this group, send email to make...@googlegroups.com.

To unsubscribe from this group, send email to makerbot+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.

--
You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
To post to this group, send email to make...@googlegroups.com.

To unsubscribe from this group, send email to makerbot+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.

--
You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
To post to this group, send email to make...@googlegroups.com.

To unsubscribe from this group, send email to makerbot+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.

--
You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.

To view this discussion on the web visit https://groups.google.com/d/msg/makerbot/-/-DzoIG7Wn6QJ.

To post to this group, send email to make...@googlegroups.com.

To unsubscribe from this group, send email to makerbot+u...@googlegroups.com.

[Adan Akerman]

Lvdt could do it but may start departing from cheap in a hurry.

On Wednesday, July 4, 2012, Cymon wrote:

My vision is something mechanical. A super sensitive analog switch on an arm that rests against the filament as it comes in or something like that.

On Tuesday, July 3, 2012 3:12:35 PM UTC-6, AdanA wrote:

I started thinking about an optical method too... but then I got scared of the challenge posed by different filament opacities, etc. Others with more experience than I may know of lighting tricks that render such issues moot. Regardless of the measurement method, it probably requires multiple measurements, as the filament is rarely round, bless its heart. 

On Tue, Jul 3, 2012 at 5:08 PM, Joseph Chiu <joe...@joechiu.com> wrote:

I would love to do this too. I think a viable approach is to hack up the sensor/DSP used in laser mice or a linear ccd to image the filament diameter.

I would also love to see a data standard for describing filament in xml and eeprom formats. That way temperatures, nominal diameter, and other details (starting filament length, estimated used, filament density, max temp, color and opacity) can be represented more uniformly.

On Jul 3, 2012 1:09 PM, "Adan Akerman" <ad...@akerworks.com> wrote:

I know, right? :-)

On Tue, Jul 3, 2012 at 2:57 PM, Cymon <joeal...@gmail.com> wrote:

I would generate the gcode with a filament diameter of 1 and scale it up from there in the software.

Ugh, projects. Projects I don't need.

On Tuesday, July 3, 2012 12:09:32 PM UTC-6, AdanA wrote:

The auto-filamentometer thing really appeals to me. On the one hand, sure: this is a cheap machine, and you have to trim some frills. On the other hand filament variability, both from manufacturing as well as environmental instability, sure seems to be one of the single biggest causes for weird variability. It also prevents us from simply reprinting a given part with different filament colors if those colors have different diameters. And, as home re-grinder / re-extruders get to be available to us this problem is likely to get worse. I find it hard to imagine we're going to be getting 0.001mm diameter tolerances from a Filabot. 

Mounting a filament measurement system on the 'bot would not be challenging mechanically but I can see how it would require a complete firm/software rethink. If the filament diameter is currently taken into account at the time of slicing, that's much too far upstream for any on-machine measurement to have an influence.

On the other hand, you could, at the time of slicing, specify a nominal (3mm vs 1.75, etc.), have it create the gcode with perfection in mind, and then the firmware could take input from the Filamentometer and just apply a correction factor to any extruder commands at the moment of extrusion. Is there a chance that might work?

I'm a mech-biased person, though... I could probably make a fun little diameter measurement system, but I'm not likely to be denting the code challenges in a hurry! I'd just have a sad output plopping values into the void... waiting for some code to come along and care what it had to say... 

Adan

On Tue, Jul 3, 2012 at 1:52 PM, Cymon <joeal...@gmail.com> wrote:

There are still things I don't understand and can't find answers for. Maybe this isn't the right place to ask these questions. If not please let me know.

If I connect my replicator to RepG and go to the On Board Settings menu I can change the acceleration settings. So what if I lower those values so that within a single gcode command it doesn't get up to the speed specified? To me this means that the speed, particularly on highly detailed builds, has as much to do with the speed specified when building the gcode as the acceleration settings on the board. Is that right?

Which brings me to my next question. Why is speed being set in the gcode at all? Why does

To view this discussion on the web visit https://groups.google.com/d/msg/makerbot/-/-DzoIG7Wn6QJ.

To post to this group, send email to make...@googlegroups.com.

To unsubscribe from this group, send email to makerbot+u...@googlegroups.com.

[Cymon]

I'll bite. Is Lvdt animal, vegetable, or procedural?

To unsubscribe from this group, send email to makerbot+unsubscribe@googlegroups.com.

[Clive Munday]

Linear variable differential transformer..........

--

You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.

To view this discussion on the web visit https://groups.google.com/d/msg/makerbot/-/cA1DiqgIbtAJ.

To post to this group, send email to make...@googlegroups.com.

To unsubscribe from this group, send email to makerbot+u...@googlegroups.com.

[Adan Akerman]

Yes, which I believe qualifies it as animal, vegetable, AND procedural :-) It's just another way to get a position measurement. 

I like saying LVDT fast, as it works much like ellim enno pee. 

[Chuck McManis]

Interesting discussion.

One solution for 'uniform' filament production is to not have a filament. Which is to say melt the ABS into liquid into a reservoir in the extruder then pump it out through a nozzle which both shapes and cools it down to the correct exit temperature. It 'builds filament' on the fly vs getting it pre-made. Using peizo pumps like inkjet nozzles do you can get the level of precision you want, although hard to keep the price down for custom parts like this. I don't know if doing post deposit pre-heat / cooling would help or not but that would be something to consider as well.

Of course just speculation, and fun to play with.

--Chuck

[Adan Akerman]

That's an awesome idea... I really like the idea of liquifying the feedstock. I think Objet works with a liquid feedstock, then cures it with UV laser(s) as it comes out? One advantage they have is color and material property blending, apparently. Maybe such could become possible with this type thing too. That on top of improved accuracy and it would be a major step forward.

But boy, what a challenge. It's quite a departure from all the reprap work to date, as far as I understand it. Not to say that's any reason not to do it, but it's not something to be taken likely.

--
You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.