Jump to content
Ultimaker Community of 3D Printing Experts
Sign in to follow this  
Nicolinux

Filament Width Sensor

Recommended Posts

Hi,

I came across this project on Thingiverse:

 

 

and wondered if it would be a good addition for the UM too. It measures the filament width on the fly and changes the flow to compensate for width fluctuations. Pretty nifty.

Not sure it if makes a big difference at all. I am printing with 2.85mm width for ages without a noticeable difference in quality. I'd go so far to say that the UltiGcode isn't all that useful at the moment since a) there can only be four filament presets (two of them can't be renamed) and b ) I guess most people are just too lazy to change filament width constantly. That is if you print with high quality filament which has stable properties....

 

Share this post


Link to post
Share on other sites

Hmm! curious device, it has a light shining on a 128x1 pixel array with the amount obscured by the filament indicating the width, but I'm not quite seeing how it works.

Does that work with translucent filaments?

Also, what happens if cross sectional area is consistent but it comes to an oval shaped section? Presumably it will increase or decrease the flow depending on its orientation.

Does the modified Marlin also track the distance from the sensor to the nozzle and, with the filament speed, calculate when in the future to vary the feed rate to compensate for the width change?

Personally I never change the filament width. I'd rather get good quality filament in the first place.

 

Share this post


Link to post
Share on other sites

Does this measure the width in 2 dimensions, or the actual circular area of the filament?

Because if you only measure the 2D-width, you have a pretty much worthless setup -> What about filament which is not perfectly round (which it never is)?

You can have a filament which has exactly the correct circular area of 2.85mm filament (which is Pi * r^2 =~ 3.14 * 1.425^2 =~ 6.38 mm2) but is slightly oval.

If you take a 2D measurement of that oval filament, you might measure 2.9mm (or 2.7mm if you get the flatter side) and compensate for an inexistent error...

Besides that: Getting exactly the correct amount of flow isn't critical for most prints. You usually don't even notice errors of about +-5% or even more.

/edit:

A partial solution would be to measure the 2D width from several angles and taking the average of the measured widths. But that makes the sensor very complex - it's hardly going to be worth the effort.

Imho, what makes much more sense is to have a sensor which checks whether or not the filament is actually feeding, or just grinding on the spot. This can be done very easily (most probably it has already been done...) and gives valuable information about the print's status.

 

Share this post


Link to post
Share on other sites

Imho, what makes much more sense is to have a sensor which checks whether or not the filament is actually feeding, or just grinding on the spot. This can be done very easily (most probably it has already been done...) and gives valuable information about the print's status.

 

I think this would be of more value then the width measuring device.

 

Share this post


Link to post
Share on other sites

As as someone mentioned, for bowden tubes, the measurements would need to be tracked for the length of the path between the sensor and the extruder.

I think jams have ruined many more prints that changes in filament width.

My filament width solution is to buy filament from a good supplier.

 

Share this post


Link to post
Share on other sites

Daid, if I might ask - why was UltiGcode introduced in the first place?

 

Daid is on vacation, but i think it was because the ultimaker 2 needs less material settings in the gcode and more material settings saved on the machine itself.

that is the main reason i think

 

Share this post


Link to post
Share on other sites

I believe that UltiGcode and the volumetric enhancements in Marlin were done to reduce the machine specifics in the gcode so that the gcode is "portable" to different machines and filaments. If you think about it, the volumetric versions of gcode just describe the object without respect to the machine. You can take the gcode to another machine using different size and type of filament and temperature.

The only thing it doesn't address 100% is the movement speed as that is "baked in" to the gcode. While you can change the speed on the machine that doesn't give you complete control. You can vary the speed overall but you might want to have the first layer at one speed and the others at a faster speed which you might not be able achieve with a simple multiplier unless you actively dial in the speed.

 

Share this post


Link to post
Share on other sites

I think what they really should do is sort of abstract the speed in the gcode from the actual speed. The gcode should really contain a speed "level" or "type". The slicer would generate the type (for example, first layer extrude or first layer travel") and then the operator would set the speed appropriate for the printer and material in the firmware just like temperature and filament size.

However, that would require more radical change than the filament size. For volumetric, the slicer just assumes a nominal filament size such that a feed of 1 represents 1 cubic mm. There is a magical filament width that produces this and I forget that value. (oh it's 1.1283791670955125738961589031215)

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

Terms of Use Privacy Policy