Been doing some more 3D-printed parts.
I'd given up on Skeinforge long ago, and been using Slic3r. Unfortunately, the version of Slic3r that comes bundled with Replicator-G doesn't appear to work with Replicator-G, so I'd downloaded the stable version for Linux, and had been using that, standalone (after preprocessing the .stl files through Replicator-G to get the orientation right).
Well, there were some peculiarities in a recent (more complex than usual) build, and the as-distributed Slic3r doesn't do a 3D view, so I decided to build from source and get that OpenGL support.
This involves getting the source from the git repository, which means the very latest experimental version. Anyway: I get that, then do the build, and... it works! And the anomaly is gone!
So then I try to process another, somewhat large part. Doesn't quite work; it needs a parameter or two fiddled. I fiddle the parameters, and:
Attempt to free unreferenced scalar: SV 0x7f983c8c9fc8, Perl interpreter: 0x7f983c019080 at /opt/Slic3r/lib/Slic3r.pm line 116.
Uh... howzat again?
Try again: same thing.
Unfiddle the parameters: same.
Try a smaller, simpler part: same.
Google.
It's happened to various people over the years. Related to .stl files that need repair? Process the .stl file through FreeCAD, so no more mesh errors: same crash.
Mnfxt.
Oh, and installing the new version made the old version (kept in its own directory) cease to function; apparently it updated a bunch of Perl modules into incompatibility or something.
Someone reports that rebooting cures the problem, temporarily. Don't remember what OS he was using. Maybe I'll try it. But what kind of sense does that make, anyway?
Not rebooting for a while yet; got too many things open.
Update: Well, I hadn't figured on rebooting, but...
I re-ran the build script for the older version. That got rid of the errors at startup, but when I tried to change a parameter it got a comprehensive wedgie and took X with it, requiring the old CTRL-ALT-F1 sudo reboot.
Then I re-ran the build script for the latest. Seems it installs its own Perl modules under Perl, rather than keeping to its own install directory, so There Can Be Only One.
Back to the unreferenced scalar. I look at the offending .pm file, and the line in question, and it's clearly an automatic deallocation. Apparently this sort of thing tends to be associated with threads not playing nice with shared data.
Changing all the config profiles back to default fails to solve the problem.
Well, maybe I just have to run it in a VM with some other, more up-to-date distro, like Ubuntu or Mint. Or... perhaps I should try renaming the ~/.Slicer directory, testing the program with a clean configuration, and then copying my tweaked config files back...?
Update 2: Just launched apt-get update; apt-get upgrade on the Mint-KDE VM. Got 480 packages to upgrade. Gonna take a while.
Aaaand... meanwhile, I renamed ~/.Slicer, created a clean one, copied my last good print/filament/printer configs over... and now 'tis working. Apparently something in slicer.ini causes the problem...?
Can't actually test the output just now, because the printer is in the lab, and the lab is closed for the night (what with it being past Tinga's bedtime).
Update 3: W. T. A. F????? Copying my latest fiddled configurations into the new directory causes the crash, even if I don't actually select them. Actual crash-inducer is print/Fiddled-3.ini, which doesn't appear to be doing anything particularly unusual. Delete that file, and all's well again.
And clicking on one of those dotini files in KDE (Debian-wheezy) takes a long time... because it's launching Notepad under WINE????? Maybe I should tell KDE that they're just plain text files.
Update 4: With the earlier version of Slic3r, setting the printer's X and Y offsets to zero gave centered prints. With the latest... Y needs to be set at ½, and X needs to be set to... wait for it... ¾?????
C'mon, guys. Reasonable offset factors are 0, 0.5, and 1, according to the coordinate system in use. In what kind of coordinate system does it make sense to have one axis offset by 75% of full scale?
(Also, the extruder-priming lines it lays down at the beginning seem to start rather right of where they should, which suggests that an extraneous X-axis offset has crept in. Maybe something in the initial G-code?)
Update 5: On the other hand... when all's fiddled, I can print out a little dingus with a 0.095" (specified, not measured) hole running horizontally, and proceed to tap that hole #4-40, and it comes out feeling reasonably secure. Still have to test for actual durability, but having a tapped widget can save a bunch of assembly hassle. (No, I didn't try CADding the threads; it's a freakin' FDM printer, with nowhere near the resolution to do 40 TPI.)
Recent Comments