Smoothie M2

[jimc]

Yeah all m2s have that little bit of play. Not much you can do about it really. The whole assembly is just riding on that one slide bearing. Imo its the only weak point of the m2. The bed really nees to be running in a pair of rails

[Tim]

I am very interested what your calibration says for the extruder.

I am currently running a spool of wood filament, which is not very good for doing calibrations, so I'll run a calibration when I switch back to PETg later today. Anecdotally, I got serious under-extrusion after I changed the extruder steps-per-mm from 471.57 to 488.55, and the under-extrusion disappeared when I changed the extruder multiplier from 0.9 to 1.0. But the difference between 471.57 and 488.55 is only 3 1/2 percent, not 10 percent, so theoretically the value change should only account for about a third of that.

My only complaints are with S3d being a bit glitchy with smoothie. the glitches are when you try to control prints from s3d. so in general, I don't use it for that, only slicing.

Glitchy in what way? I've been using the smoothie with S3D all the time and have not had any issues. On the other hand, I run everything in Linux, and there do seem to be way more communications issues on the USB interface under Windows, from what I've read. In years of printing over USB, I have not experienced a single communication failure (except the one time I connected the printer to my laptop and it went into sleep mode during a print, and then I unwisely woke it back up).

[swbluto]

S3D seems a bit glitchy over USB in general, at least on my Windows machine.

[Tim]

I am very interested what your calibration says for the extruder.

Calibration says that anecdotal evidence should always be taken with a grain of salt.

Turns out that the under-extrusion on the wood filament was due to my having forgotten that the wood filament has a smaller diameter than my other filaments (averages about 1.69 instead of 1.75). Somewhere along the line I reset the filament diameter setting in S3D back to 1.75, so of course it was under-extruding.

I ran calibration on the PETg (diameter dead-on 1.75) and so ended up dialing the extruder multiplier back to 0.9 again.

One thing I discovered in the process: S3D no longer slices the "calibration40x10" thin-wall calibration piece the way it used to. Looks like some kind of round-off behavior. The (modeled) piece's walls are around 0.4mm thick. S3D used to slice this as a single filament thickness. Now the whole thing just vanishes unless I set the extrusion width to 0.39 or less. . . It won't slice it at an extrusion width of 0.4. Furthermore, it now draws the semicircular end of the piece as a series of individual line segments, possibly due to small width variations in the segment approximation of the circle. I guess I should be doing the thin wall test by using a solid object and specifying a single wall and no infill. I just wasn't expecting the slicing behavior to change on my traditional calibration object.

[innkeeper]

My only complaints are with S3d being a bit glitchy with smoothie.

Glitchy in what way?

if, for some reason, you start a print from s3d off the sd card, and you loose usb connectivity or the machine stops, the print will stop.

sometimes S3D will just stop communicating with s3d causing he same issue...

these are issues that Arthur Wolf has been in contact with the S3D folks for some time.
seems that the Simplyfy3D folks have been completely uncooperative over it.
hit up Arthur Wolf if you want to know more, I am sure he will happily bend your ear over it.

Its an issue that only exists with S3d BTW.

I am not sure why they don't work with him on it ... maybe for the same reasons after a year of there release in merlin of volumetric extrusion and firmware retract its still not implemented S3D.
Both are great advancements (and supported under smoothie as well), I'm especially fond of volumetric extrusion idea so I don't have to re slice every time you change filament. great if you print the same prints over and over.
kind of disappointed in those things for a pay package.

if you ask the smoothie team they will tell you currently S3d is NOT supported.

[Dale Reed]

Looks like some kind of round-off behavior. The (modeled) piece's walls are around 0.4mm thick. S3D used to slice this as a single filament thickness. Now the whole thing just vanishes unless I set the extrusion width to 0.39 or less. . . It won't slice it at an extrusion width of 0.4.

In binary floating point (IEEE 754 etc.), 0.4 decimal cannot be represented exactly. It is a repeating "decimal" fraction, just like 1/7 in base 10 math. The stuff you see on screen is rounded to nearest decimal representation of the formatted field, but in the underlying math, doing a comparison with "greater than or equal" will work on the internal representations, and I guess the numbers are not "greater than or equal" -- the calculated value is less than the binary expansion of 0.40, but still shows as 0.40 on screen when rounded.

My $0.02 (which cannot be represented exactly as a binary fraction).

[innkeeper]

A heads up for anyone considering the board i used, the MKS SBASE.
There is 1 issue with it, in that the temerature readings fluctuate. This seems to be an issue that the manufacturer has acknolaged and is working to correct.

note: the real smoothieboard, or other clones do not have this issue.

from a practial standpoint, this has not caused me problems... but..i can see it when watching the reported temps on the lcd.

[Tim]

the temerature readings fluctuate. . . the real smoothieboard, or other clones do not have this issue.

I'm curious about how the temperature readings fluctuate. Randomly? One of the issues I noted with the Smoothieboard is that after calibrating the PID values, the temperature settling behavior is seriously under-damped. The temperature will oscillate over 10 degrees C or more, slowly damping down, but it can take over half an hour before they go away (easier to see on a temperature plot from S3D or from pronterface). The conclusion is that the fault is in the way the Smoothieware firmware implements the PID auto-tune. I have not had time to look into it, or to see if I can tweak the PID values manually to try to fix the underdamped response.

I have seen a few other weirdnesses with temperature control, too. Occasionally, when one of the heaters turns on, the temperature readings for the other two thermistors have a sudden rise. This could be heat transfer, but since I never saw it happen before I got the Smoothieboard, I think it's more likely something like crosstalk between the thermistor channels. Another somewhat annoying behavior is that the heated bed also oscillates. If I have the bed heated before starting a print, I sometimes find that the heated bed is one degree below the setting. The print won't start until it recovers that one degree, and that can take several minutes.

I mentioned before that I had not encountered any communications errors (especially with S3D) when using the Smoothieboard, but I have had a few strange occurrances since then. In particular, I've had S3D insisting that the printer was not connected, even though the printer was still sending temperature data, and S3D was still recording it! But it would still insist that the printer was not connected, forcing me to shut down S3D and power cycle the printer to get everything to go back to normal.

[jsc]

I do see heat transfer on my dual, but it's not a sudden rise.

[innkeeper]

fluctuations are on each displayed sample, maybe 2-3 degreese +- i notice it more on the hot build plate, but hapens on the hotend too.
there is a conversation on this on the reprap forums. here...http://forums.reprap.org/read.php?13,499322,page=3
aurthur wolf has offered to assist. but if i can be of any assistance in finding this let me know I'll happy dig out the oscilliscope.