SoliForum - 3D Printing Community — Week 1 Solidoodle II Print Challenge (double helix)

Re: Week 1 Solidoodle II Print Challenge (double helix)

null@example.com (solijohn) — Thu, 25 Oct 2012 13:43:20 +0000

bahstrike wrote:

I don't like where this is going- these days there are more soap-boxes than software developers.
Given that this is a community and not a contest, I don't want to unleash a fight- zimmer is right and made good points.
Frankly I'm more offended that solidoodlesupport said "There's the software developer" only after someone provides a glimpse into the world of Architectural Astronaut-ism. It's as if I wrote my job title on a "Hi My Name Is" nametag with a crayon (which is still OK- neither of you are paying my salary). So I will help clear up the Software Industry for you from a grittier, but equally realistic, perspective.
The software industry was born into this world pretty naively and pretty rapidly; a lot of mistakes have been made and as a result a lot of careers have been built solely around trying to coax people into doing things the best way. The fact of the matter is, anyone intelligent enough to solve a complex software problem is almost certainly not going to be a complete dolt- the project IS extensible otherwise the original author couldn't have finished it. Further nitpickings are just about as pompous as a vegetarian declaring that all meat-eaters are murderers (which is questionably true, but unquestionably ridiculous).
If the code was hard to write, it should be hard to understand.

Quake II
extern unsigned blocklights[1024];    // allow some very large lightmaps
This is absolutely horrific..
- Arbitrary array size without a constant?
- Arbitrary array size on an extern??
- "Incomplete" type specifier?
- Global variable alert!
- No naming convention?
Yet.. I'm willing to bet better things have been derived from Carmack's work than Uncle Bob's.

JoelOnSoftware wrote:
It’s at this point you typically say, “Blistering Barnacles, we’ve got to get some consistent coding conventions around here!” and you spend the next day writing up coding conventions for your team and the next six days arguing about the One True Brace Style and the next three weeks rewriting old code to conform to the One True Brace Style until a manager catches you and screams at you for wasting time on something that can never make money, and you decide that it’s not really a bad thing to only reformat code when you revisit it, so you have about half of a True Brace Style and pretty soon you forget all about that and then you can start obsessing about something else irrelevant to making money like replacing one kind of string class with another kind of string class.

No offense intended! John Carmack references appreciated. Also, great thanks for pointing me in the direction of that configuration bit. Should have found it ages ago.

Re: Week 1 Solidoodle II Print Challenge (double helix)

null@example.com (bahstrike) — Thu, 25 Oct 2012 02:01:52 +0000

Anyway John the droids you are looking for are here:
Slic3r / lib / Slic3r / Config.pm

'filament_diameter' => {
     label   => 'Diameter',
     tooltip => 'Enter your filament diameter here. Good precision is required, so use a caliper and do multiple measurements along the filament, then compute the average.',
     sidetext => 'mm',
     cli     => 'filament-diameter=f@',
     type    => 'f',
     serialize   => $serialize_comma,
     deserialize => $deserialize_comma,
     default     => [3],
},

Re: Week 1 Solidoodle II Print Challenge (double helix)

null@example.com (bahstrike) — Wed, 24 Oct 2012 23:41:52 +0000

I don't like where this is going- these days there are more soap-boxes than software developers.
Given that this is a community and not a contest, I don't want to unleash a fight- zimmer is right and made good points.

Frankly I'm more offended that solidoodlesupport said "There's the software developer" only after someone provides a glimpse into the world of Architectural Astronaut-ism. It's as if I wrote my job title on a "Hi My Name Is" nametag with a crayon (which is still OK- neither of you are paying my salary). So I will help clear up the Software Industry for you from a grittier, but equally realistic, perspective.

The software industry was born into this world pretty naively and pretty rapidly; a lot of mistakes have been made and as a result a lot of careers have been built solely around trying to coax people into doing things the best way. The fact of the matter is, anyone intelligent enough to solve a complex software problem is almost certainly not going to be a complete dolt- the project IS extensible otherwise the original author couldn't have finished it. Further nitpickings are just about as pompous as a vegetarian declaring that all meat-eaters are murderers (which is questionably true, but unquestionably ridiculous).

If the code was hard to write, it should be hard to understand.

Quake II

extern unsigned blocklights[1024];    // allow some very large lightmaps

This is absolutely horrific..
- Arbitrary array size without a constant?
- Arbitrary array size on an extern??
- "Incomplete" type specifier?
- Global variable alert!
- No naming convention?

Yet.. I'm willing to bet better things have been derived from Carmack's work than Uncle Bob's.

JoelOnSoftware wrote:

It’s at this point you typically say, “Blistering Barnacles, we’ve got to get some consistent coding conventions around here!” and you spend the next day writing up coding conventions for your team and the next six days arguing about the One True Brace Style and the next three weeks rewriting old code to conform to the One True Brace Style until a manager catches you and screams at you for wasting time on something that can never make money, and you decide that it’s not really a bad thing to only reformat code when you revisit it, so you have about half of a True Brace Style and pretty soon you forget all about that and then you can start obsessing about something else irrelevant to making money like replacing one kind of string class with another kind of string class.

Re: Week 1 Solidoodle II Print Challenge (double helix)

null@example.com (solijohn) — Wed, 24 Oct 2012 21:37:47 +0000

zimmer62 wrote:

solidoodlesupport wrote:
I've never understood why novice coders refuse to comment code. It seems quite natural to do in all situations.
My experience with the code was trying to find where the defaults were stored. In Pronterface these defaults are quite easy to find (and modify for the Solidoodle's unique temperature requirements.) I've asked the dev a few times to help me find them, but he seemed more concerned with trying to sell us consulting. I'm sure I've passed them by a hundred times - just didn't know where to look.
Not that I've been able to devote hours to decoding things.
As a programmer for a living, really good clean code needs no comments at all. It literally tells you exactly what it's doing. (This is always a hot topic for programmers)
Read the book by Bob Martin called "Clean Code" and you'll see there is a lot a programmer can do to write good SOLID (yes that is a programming acronym) code that is easy to read, and easy to maintain with very few if any at all comments.
When I see a section of code that has more comments than code it smells funny. Comments can lie about what that block of code is doing anyways.
If you keep the cyclomatic complexity down and follow the single responsibility principle, using well named methods and variables you just don't need comments since they are usually redundant.
Being novice has nothing to do with why a coder does or doesn't comment their code. And uncommented code has very little proof that coder is a novice or not. A novice usually writes a lot more code than is needed, it smells funny, has high cyclomatic complexity, lacks the use of design patterns, and is usually a nightmare to maintain.
I didn't look at slic3r's code so I can't tell you if it's sloppy code or not, you're right that perl is a little vague in general which is why I'd never use it for a larger project that will grow and grow over time.

Ah! There's the software developer. I knew there was one on the forum. Good points! I think I may pick up the book you're suggesting - I don't have many on wider issues - most of my collection is on individual languages / philosophies. I wouldn't even say that Slic3r is sloppy - compared to some other slicing programs it looks organized from the outside.

Re: Week 1 Solidoodle II Print Challenge (double helix)

null@example.com (zimmer62) — Wed, 24 Oct 2012 21:18:21 +0000

solidoodlesupport wrote:

I've never understood why novice coders refuse to comment code. It seems quite natural to do in all situations.
My experience with the code was trying to find where the defaults were stored. In Pronterface these defaults are quite easy to find (and modify for the Solidoodle's unique temperature requirements.) I've asked the dev a few times to help me find them, but he seemed more concerned with trying to sell us consulting. I'm sure I've passed them by a hundred times - just didn't know where to look.
Not that I've been able to devote hours to decoding things.

As a programmer for a living, really good clean code needs no comments at all. It literally tells you exactly what it's doing. (This is always a hot topic for programmers)

Read the book by Bob Martin called "Clean Code" and you'll see there is a lot a programmer can do to write good SOLID (yes that is a programming acronym) code that is easy to read, and easy to maintain with very few if any at all comments.

When I see a section of code that has more comments than code it smells funny. Comments can lie about what that block of code is doing anyways.

If you keep the cyclomatic complexity down and follow the single responsibility principle, using well named methods and variables you just don't need comments since they are usually redundant.

Being novice has nothing to do with why a coder does or doesn't comment their code. And uncommented code has very little proof that coder is a novice or not. A novice usually writes a lot more code than is needed, it smells funny, has high cyclomatic complexity, lacks the use of design patterns, and is usually a nightmare to maintain.

I didn't look at slic3r's code so I can't tell you if it's sloppy code or not, you're right that perl is a little vague in general which is why I'd never use it for a larger project that will grow and grow over time.

Re: Week 1 Solidoodle II Print Challenge (double helix)

null@example.com (solijohn) — Wed, 24 Oct 2012 20:52:50 +0000

bahstrike wrote:

I'm poking around slic3r source and I can tell you it's a lot better than some $1M priced code I've had the 'pleasure' of working with.
He's doing a good job splitting a subroutine's internals with whitespace and usually putting a little comment for each one that briefly states the operation about to be done. It's a bit like reading a little story You'd be surprised how rare this can be in novice OR production code. It would be pretty easy to jump in and start making modifications because it's organized fairly nicely.
Never used perl (nor had reason to.... until now?) but I must say I'm getting a kick out of the 'my' and 'our' keywords.
I'll be hacking around this stuff when I get my printer

I've never understood why novice coders refuse to comment code. It seems quite natural to do in all situations.
My experience with the code was trying to find where the defaults were stored. In Pronterface these defaults are quite easy to find (and modify for the Solidoodle's unique temperature requirements.) I've asked the dev a few times to help me find them, but he seemed more concerned with trying to sell us consulting. I'm sure I've passed them by a hundred times - just didn't know where to look.

Not that I've been able to devote hours to decoding things.

Re: Week 1 Solidoodle II Print Challenge (double helix)

null@example.com (bahstrike) — Wed, 24 Oct 2012 19:58:28 +0000

I'm poking around slic3r source and I can tell you it's a lot better than some $1M priced code I've had the 'pleasure' of working with.

He's doing a good job splitting a subroutine's internals with whitespace and usually putting a little comment for each one that briefly states the operation about to be done. It's a bit like reading a little story You'd be surprised how rare this can be in novice OR production code. It would be pretty easy to jump in and start making modifications because it's organized fairly nicely.

Never used perl (nor had reason to.... until now?) but I must say I'm getting a kick out of the 'my' and 'our' keywords.
I'll be hacking around this stuff when I get my printer

Re: Week 1 Solidoodle II Print Challenge (double helix)

null@example.com (solijohn) — Wed, 24 Oct 2012 16:16:29 +0000

lawsy wrote:

If you want to see how the Slic3r does its job, poke through the source code on its Github (not that it will be very easy to understand).

Well, it's not necessarily the most legible thing. I think we would all love to see a code review.

Edit: I just find perl coding to be vague in general, I'm not implying he did a bad job.

Re: Week 1 Solidoodle II Print Challenge (double helix)

null@example.com (lawsy) — Fri, 19 Oct 2012 22:37:26 +0000

If you want to see how the Slic3r does its job, poke through the source code on its Github (not that it will be very easy to understand).

Re: Week 1 Solidoodle II Print Challenge (double helix)

null@example.com (IanJohnson) — Fri, 19 Oct 2012 20:03:29 +0000

You can kind of do that in Slic3r. When printing .1mm, tell it to fill every three layers so the fill goes in at .3mm.

Skeinforge 50 has "skin" which can divide the perimeters of at .3mm layer into 3 .1mm perimeters, but the steps between layers still happen at .3mm.

Re: Week 1 Solidoodle II Print Challenge (double helix)

null@example.com (goofygrin) — Fri, 19 Oct 2012 19:45:12 +0000

You can always go edit the gcode... but that's like going from a 3d model down to the assembler used to blit the data to the video card...

I'd like to be able to change the way the slicer slices based upon where in the model it is... like .3mm on the gross sections, but .1mm in the fine sections. But that's wishful thinking

Re: Week 1 Solidoodle II Print Challenge (double helix)

null@example.com (jooshs) — Fri, 19 Oct 2012 16:56:00 +0000

I would like to know if there is a way to go in and edit the path of the layers manually if you're not pleased with them. I am not afraid of the math to create the slices, but don't know where you could access it to change it. The print I made quite a while ago of the bahtinov mask still never came out quite right because neither gcode gave paths that created consistent bar thicknesses and still occasionally started in the middle of a bar. Both of those those things drastically affect the effectiveness of the mask.

Here is the print I am talking about.

http://www.soliforum.com/topic/76/bahti … -settings/

Re: Week 1 Solidoodle II Print Challenge (double helix)

null@example.com (solijohn) — Fri, 19 Oct 2012 16:28:21 +0000

IanJohnson wrote:

It's hard to say, and I've had it go both ways with problematic STLs. I've had models that Skeinforge couldn't handle and only Slic3r can slice, and vice versa. You can generally get anything fixed for free as far as manifold edges, holes, etc except for self intersections. You can't really predict what a slicer will do with those.

I'm surprised we haven't seen a computer scientist give a nice break down of how this works. Kliment has implied to me that the math is intense, and perhaps this why things aren't 100% clear.

Re: Week 1 Solidoodle II Print Challenge (double helix)

null@example.com (IanJohnson) — Fri, 19 Oct 2012 15:55:45 +0000

It's hard to say, and I've had it go both ways with problematic STLs. I've had models that Skeinforge couldn't handle and only Slic3r can slice, and vice versa. You can generally get anything fixed for free as far as manifold edges, holes, etc except for self intersections. You can't really predict what a slicer will do with those.

Re: Week 1 Solidoodle II Print Challenge (double helix)

null@example.com (solijohn) — Fri, 19 Oct 2012 14:57:57 +0000

IanJohnson wrote:

You will get the best results with Skeinforge, if that isn't what you are already using. There are some self intersections, and Skeinforge handles them better than Slic3r for this model. Slic3r tries to start some of the crossbar layers in midair.

I wonder what the actual difference algorithm wise is? This is something that is a little too mysterious at the moment.