Hey. Just a few notes.
ccavanaugh wrote: A work around exists, but the main smoothie firmware dev refuses to accept it,
Actually, the main smoothie dev came up with the hacky work around, after a lot of work by a lot of people to try to figure it out.
And nobody is "refusing to accept it", it's available in a separate branch for those that need it, which is a common practice ( this *very* thread is about a separate Smoothie branch ), and just means that anybody that runs into the S3D problem must get their firmware.bin file from a different place than everybody else when updating their firmware.
ccavanaugh wrote: AND has acknowledged that there is a bug somewhere.
Sure, we even know what the bug is now.
ccavanaugh wrote: I suspect the bug is tied to the smoothie motion planner
bot wrote:I really don't like this attitude that s3d is dumb to do this. Who are you to tell us what is and isn't dumb?
If you saw somebody taking the metro, getting into the car, getting off at the next station, waiting for the next car, getting in, going to the next station, getting off, waiting for the next car, getting in ...and doing this for 30 metro stations ... I'm pretty sure you'd call this either dumb, or an art performance. I don't think S3D is going for "art performance" here.
And sure, taking the metro this way is a legitimate way of taking the metro. It's *also* dumb.
bot wrote:What if I wanted to make a microscale fdm printer?
The point is exactly that these are not microscale fdm printers but S3D is treating them as such. If you wanted to use a microscale fdm printers you actually could, if you generated Gcode for it ... It doesn't matter the size of the moves by themselves, or the size of what you are printing, what matters is that S3D is generating *insane* densities of G-code per-unit-of-time.
PolygonHell wrote:I agree if the step code dies because of a legitimate GCode, the code is bad.
Well, it's *grammatically* legitimate Gcode ( we checked ), which is not exactly the same.
We really didn't plan for slicers to do something that is both useless and wasteful when we wrote the code. Especially since all slicers that are not S3D actually actively take care not to do this wasteful and useless thing.
I'm sure there are many other ways slicers could make weird gcode ... should we work hard to be ready for all of them just in case in the future a new slicers comes up that's stupider than what exists ? Or should we concentrate on doing things that are actually useful .... ?
You can't have both ...
I'm pretty sure if I said " free smoothieboard for anybody that finds legitimate gcode that breaks firmware X ", people would find plenty of way to break any firmware. But does it mean those firmwares are bad ? I think what really matters to people is : does it work with all slicers ... which Smoothie did for a long time before S3D started doing something no other slicer does ...
I agree that the code is not as good as it could be. But is "didn't plan for stupid" really "bad" ? If so I'm pretty sure most code in this community is bad.
PolygonHell wrote:They probably have a divide by 0 in the code when the line segment gets too short.
Turns out : no. It's actually extremely more complex and subtle than this. If it was that simple, it probably wouldn't have existed in the first place, and if it had, we would have fixed it in a matter of minutes.
We now know what the bug is, and it's so sneaky we essentially can't fix it in any clean manner.
I'm surprised people would think it's possible we would have a bug this basic, for a full year, that bugs so many people, and we wouldn't simply fix it ... did we do anything to make people think we are horrible people ?
Xenocrates wrote:it is my opinion as someone who works with those tools, that a single micron step is NOT an undesired feature.
We are absolutely not saying it is. And *many* folks use Smoothieboard on CNC routers and lathes, with no problem whatsoever, including for jobs with micron-step moves.
The problem here is with the *density* of the Gcode S3D is producing, which is outside of any reasonable range we could have predicted to be generated by CAM tools. It is not useful, we didn't plan for it, and so it doesn't work.
Let me repeat : this kind of Gcode has only ever been seen coming from S3D, or from scripts generated specifically to break Smoothie during testing. It is *absurdly* dense. Go look up the example files in the mailing lists.
You would never get this problem with a normal CAM package or by writing by hand.
Xenocrates wrote:S3D is being somewhat silly as well though.
Glad somebody notices. I'd like to point out it's been a full year since they know their software has this problem, and not only have they shown no interest in fixing it ( or even recognizing it exists ), they have also actively censored users that publicly complained about it.
We get *infinitely* more cooperation from the devs of Slic3r or Cura ... this kind of problem would have been fixed in a matter of a day if it had ever happened with those slicers. Instead it's been a problem for over a year ...
I just wanted to provide a bit of information as there are a lot of misconceptions/assumptions about this issue.
I'm around if anybody has any question.