Welcome to the SeeMeCNC Community

In regards to the Smoothieware and S3D post in the other thread, here is the link.

https://groups.google.com/forum/#!topic ... r0JLV3G5i8

I think others on the forum have encountered the same issue. It boils down to the current Smoothie code choking on S3D generated gcode that has extremely high move and extrude resolution. A work around exists, but the main smoothie firmware dev refuses to accept it, AND has acknowledged that there is a bug somewhere. For now, there are a couple of post processors that can filter out gcode that do not result in any physical movement.

I suspect the bug is tied to the smoothie motion planner and an effort to port the duet motion planner would fix the bug.

It's possible that that's so. However, I read that thread, and it seems to me that Simplify3D needs to do something about their crappy program emitting g-codes for moves that are one micron long. That's straight up dumb on a program designed for fused deposition printers like ours.

In theory, a realtime position generator (which is what you're asking for) might handle this better, but the flood of microscopic g-codes will force Smoothie (or any other firmware) to slow down because they will completely fill the planning queue with moves that are only microscopically different from one another. This disrupts the firmware's ability to calculate useful accelerations. Nevertheless, slowdowns every now and then are acceptable. The printer freezing is not acceptable.

I did see this:

There is no fix, there was a workaround which will not be merged into smoothie as there are now several post processors which "fix" the crappy gcode that s3d produces which stimulates some edge case in smoothie. So you will need to use one of the postprocessors to clean up its output before feeding it to smoothie.

Not the best way to say that, as it sounds flippant. (Really.) Later, they say the step generation code needs a refactor. That does make sense. They say the workaround is kind of ugly and hackish, and if they're going to refactor step generation anyway, there's not much impetus to put "dirty code" in.

There is a place in Robot.cpp where it converts lines into delta segments, using either segments/sec or segments/mm. You can set that to 0, but it won't work on our printers. It would just try to move the steppers straight from the start to the end position at a constant rate. That would work on a Cartesian, but it would generate weird arcing movements on a delta because the carriages need to accelerate and decelerate relative to one another on very precise curves. The segmentation gives it the ability to reasonably approximate those curves.

Robot.cpp does have a lambda function capability that I use for the Z-only correction. Perhaps a similar lambda callback could be added that would, optionally, call a lambda function set by the arm solution (Robot/arm_solutions/LinearDeltaSolution.cpp). PyjamaSam, if this problem interests you and you want to help, you can look into that. I have asked for their opinion in that support thread.

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? What if I wanted to make a microscale fdm printer? Why should I not be allowed to? Because some firmware devs think so? Sorry, but the insane detail from s3d gcode does amazing things with the duet. I can throw millions of polygons at the slicer, and yes while some of the moves MAY be a little small for any legitimate purpose today, it is precise. It is accurate and it produces amazingly smooth prints with a duet.

I agree that there should be a setting for "minimum step size" on an individual axis basis -- but don't call this stupid. It's perfectly accurate.

I agree if the step code dies because of a legitimate GCode, the code is bad.
They probably have a divide by 0 in the code when the line segment gets too short.

Yup, the argument is completely invalid. I'm planning on pulling my smoothie out of my printer as soon as I get a new controller. I'm done with it and Arthurs attitude.

Opinion of mine. I work with mills and lathes routinely. CNC ones. If I give it a legal G code, even an insane one, it will do what it's told. They have the same look ahead function as smoothies do (actually, a better one, as it will swallow entire part geometries in a subroutine and pre-check them, since you can use sub-routines on them) If I tell it I want a move of one ten thousandth, be it inch or MM, it will do it, at speed. Considering that I have hand coded most of my parts, sometimes I do cheat something a ten thousandth sideways, to make an engraving look right. Some of my features are MMs tall in entireity. Smoothie claims to be able to run mills, lathes, and lasers, not just printers. If they want to run mills or lathes, it is my opinion as someone who works with those tools, that a single micron step is NOT an undesired feature. For our printers, you won't hardly see it. But if I need a part to spec, and it needs a slight shoulder, then I should be able to get it if I ask for it. I can turn out parts to a thousandth by hand with an old sloppy bridgeport. I expect to be able to get ten-thousandths with CNC's, if I ask for it. Arthur would be right, if you know, he was making just a printer controller. He's not. You claim it's for mills and lathes too, you got to deal with the fact that I will write, by hand, code that calls for single micron moves, because it makes the features I need on a part.

J, I wouldn't throw the baby out with the bathwater yet. If it's reliable, use it. You don't need to support Arthur just because you have it. Wait till we see some of the new things like the supposed Rambo successor, the new Duet revisions, and things like the Replicape Reach Rev. 2 (I'm waiting for that one personally)

S3D is being somewhat silly as well though. There should be a way to set the minimum commanded move, and from the examples I saw, it should not emit duplicate co-ordinates (that sir is an S3D bug, IMAO, there is no legit reason for it, and it is wasteful of machine resources and space) For a program that costs that much to do what open source programs do almost as well, adding those pre-processors that the Smoothie folks came up with should have been a basic step.

What if I wanted to make a microscale fdm printer? Why should I not be allowed to? Because some firmware devs think so? Sorry, but the insane detail from s3d gcode does amazing things with the duet. I can throw millions of polygons at the slicer, and yes while some of the moves MAY be a little small for any legitimate purpose today, it is precise. It is accurate and it produces amazingly smooth prints with a duet.

I agree that there should be a setting for "minimum step size" on an individual axis basis -- but don't call this stupid. It's perfectly accurate.

I'm of two minds on this. I don't think they're wrong to say, "This hack is low-quality and we don't want to pollute our main codebase with it." After all, keeping that clean is their headache, and the consequences of allowing bad code in there mean a lot more cussing for them than for any of us. However, I think it would be better for them to prioritize a refactor that would fix this bug. Leaving this unfixed means that thousands of their customers who use S3D are going to have to deal with an unnecessary pain in the ass. Beyond that, and maybe this is a little idealistic of me, I just don't like the idea of leaving a bug alone. Even if you don't care about the problem that exposes it, some other problem might come along in six months, and you have to waste days/weeks of your time because you didn't fix it when you had the opportunity.

I maintain that it is counterproductive for S3D, an application targeted squarely at FDM printer owners with nozzles on the order of 400 microns, to generate line segments with a resolution fit for a scanning electron microscope. It's foolish of them to do this when most 3D printing firmwares have a queue size of 20 G-code instructions, because that wrecks the look-ahead necessary for consistent acceleration control. Nevertheless, if it is outputting valid G-code, Smoothie should not fail to process that G-code. It is supposed to be a general-purpose CNC controller. They reject pulls that contain technically invalid G-code, so obviously they care somewhat about respecting that standard. If it slows down and you get a bunch of oozing on a corner, well, at least you have a complete print. You can sand down minor problems like that. At least you're not walking up to the printer two hours before a major presentation to find that it's taking a permanent smoke break, drooling plastic all over a now-useless model you needed to have. Your CNC controller should not do this to you, even if the code you feed it is generated dumbly. Dumb and valid is still valid, isn't it? At the end of the day, the "dumb" is my opinion, but "valid" isn't my opinion or anyone else's. It's a fact that the code is either valid, or it isn't. If it adheres to the spec, it should be executed without complaint. Not necessarily without undesired behavior, like slowing down to a crawl, but at least it should do what it's told if the instructions are formatted correctly. This should be a minimum standard of behavior for something claiming to accurately interpret G-code.

I will go further and say that the way they responded in that thread was flippant. "Oh, you use a slicer I don't like? Go F yourself." That may not have been what they meant to convey, but it came off as abrasive. Capricious, even. When you give someone who gave you $150+ for a controller some bad news, you should couch it better and explain why you're saying no, in full detail, right away. They did eventually explain that it's about code quality, but they should've said that up front instead of waiting until after people complained. That caused a PR problem they didn't need, in exchange for nothing useful.

JFettig wrote:Yup, the argument is completely invalid. I'm planning on pulling my smoothie out of my printer as soon as I get a new controller. I'm done with it and Arthurs attitude.

Psst... Arthur is the polite one. The other guy, well, totally fair to say he can be gruff.

I will consider doing features like this that the main devs don't care about. I'm inclined to pay more attention to what the end users want than to say "it's open source, get bent." (However, I will say no to things if I don't have time to work on them.) I also pay more attention to features that make it easier to read the output, for example. I definitely want to bring in the code for the PanelDue. The code is really simple - all it does is send some JSON over serial to tell the PanelDue what the temps are, etc. This is a LOT more lightweight than the full-on menu support you need to run a GLCD, for example. That means lower RAM requirements, which in turn means it will play nicer with my calibration system. I might not have to free any RAM to make it work. Also, the PanelDue looks and works far better than any other GLCD or character display solution out there.

626Pilot wrote:...I do know someone "took" G29, which I was already using for probe calibration, so that's a bother...

Just noticed that a commit on the 1st of Jan added support for using a Pn parameter to select the strategies that responds to a G29... That could be a nice easy way to reuse G29 and not trample on any other strategies that use it.

Also related but unrelated I stumbled across this in the comments of one of the commits, and it looks interesting.
http://escher3d.com/pages/wizards/wizarddelta.php
Not sure if it has come up around here before, but I figured I'd link it for fun. (Ahh... after doing some reading and digging its dc42's commercial site)

chris.

Hi guys!
really appreciate the work of Pilot626, that's impressive, thank you !!

I have a 400mm bed on 3 leveling points which are put on the same distance relevant to the aluminium plate under the bed, my z probe has a 0 steps error, sometimes 1 (Im on 1/16 steppers)
Im following the procedure on github issueing commands as follow:
G29
G32
G31 H O P Q R
then i heat the bed to 60°C (this glass gets concave in the center by 1mm over the 400mm diameter)
G31 A

trying to print one layer @0.18mm of a circle of 300mm dia I get a pattern of high/low spots which are in line to XYZ tower with the center, is that normal?
from where can I start to correct this first layer issue and smooth the high/low difference?
thanks!!

[img]http://www.bnzconsulting.com.cy/Ftp/BNZDelta/300mm.jpg[/img]

How tight are your belts? I've seen patterns like that on deltas, and it always leads me to belt tension. This is where deltas will experience backlash as the tower changes direction at that point.

bot wrote:How tight are your belts? I've seen patterns like that on deltas, and it always leads me to belt tension. This is where deltas will experience backlash as the tower changes direction at that point.

thank you for the advice, in fact it sound just right, where the carriage invert its direction.
i'm using a tensioner on the carriage plus the spring one, i can't measure how tight they are but the feeling is that they are well tensioned.
[img]http://ecx.images-amazon.com/images/I/4 ... SX342_.jpg[/img]

I will try to print again with the belts more tight.
have I to run the calibration routine again after re-tensioning the belts?

paboman wrote:

bot wrote:How tight are your belts? I've seen patterns like that on deltas, and it always leads me to belt tension. This is where deltas will experience backlash as the tower changes direction at that point.

thank you for the advice, in fact it sound just right, where the carriage invert its direction.
i'm using a tensioner on the carriage plus the spring one, i can't measure how tight they are but the feeling is that they are well tensioned.
[img]http://ecx.images-amazon.com/images/I/4 ... SX342_.jpg[/img]

I will try to print again with the belts more tight.
have I to run the calibration routine again after re-tensioning the belts?

You should not have to do a calibration routine after tightening the belts.

Try heating up the bed to 60C again and running G31 Z. Paste the output and we'll see what's up.

626Pilot wrote:I was talking to dc42, author of the Duet fork with delta calibration, a few months back. He noted that my firmware uses the mean (average) of all deviations as the evaluation metric, whereas his uses RMS (root mean squared) as the eval metric. I decided to give Smoothie the ability to switch between using mean and RMS using an option with G31. The improvement with RMS has been marginal (like, 5-10 microns) so far. I'll include this feature in the next release, along with the improvement that makes probing more repeatable. Maybe the gain will be bigger for someone else than it is for me.

Code: Select all

3x with RMS
------------------------------------------
[PD]                                    0.112
[PD]
[PD] [  --  ]     0.044      0.025      0.013      0.013      0.050    [  --  ]
[PD]
[PD] [  --  ]     0.025      0.006     -0.013     -0.019      0.025    [  --  ]
[PD]
[PD]  -0.050      0.000      0.019      0.000      0.006      0.019      0.075
[PD]
[PD] [  --  ]     0.050      0.044      0.038      0.025      0.038    [  --  ]
[PD]
[PD] [  --  ]     0.038      0.056      0.056      0.044      0.025    [  --  ]
[PD]
[PD]                                   -0.019
[PD]
[PD] Best=0.000, worst=0.112, min=-0.050, max=0.112, mu=0.015, RMS=0.031, sigma=0.027, energy=0.041


3x with Mean (same starting point)
------------------------------------------
[PD]                                    0.100
[PD]
[PD] [  --  ]     0.075      0.038      0.025      0.013      0.031    [  --  ]
[PD]
[PD] [  --  ]     0.038      0.013      0.006      0.006      0.038    [  --  ]
[PD]
[PD]   0.000      0.006      0.025      0.000      0.031      0.044      0.075
[PD]
[PD] [  --  ]     0.056      0.044      0.038      0.044      0.056    [  --  ]
[PD]
[PD] [  --  ]     0.044      0.050      0.044      0.044      0.038    [  --  ]
[PD]
[PD]                                    0.006
[PD]
[PD] Best=0.000, worst=0.100, min=0.000, max=0.100, mu=0.021, RMS=0.033, sigma=0.025, energy=0.043

has this update been pushed out in a different location from git?

Not yet. I've been working on mag arm stuff. I will push my changes to GitHub this month.

626Pilot wrote:Not yet. I've been working on mag arm stuff. I will push my changes to GitHub this month.

I did the carbon fiber arrows with traxxas rod arms, you can see it in my "man sized" thread. I haven't had any issues.

bubbasnow wrote:I did the carbon fiber arrows with traxxas rod arms, you can see it in my "man sized" thread. I haven't had any issues.

I have strong opinions about this based on going through several expensive sets since 2013. Suffice it to say, there is no future for Traxxas rod ends on any printer I build. I'm going to start with magnetic arms, and eventually move to tensioned ball arms if they aren't good enough. To me, the perfect solution would be CNC machined acetal with ball-end milled cups, and carbon fiber rods with matching chromed steel balls on either end, with tension provided by paracord or some similar tough elastic.

I already got started on the effector.

Done with the first iteration of my effector & carriages for magnetic arms. This is the best calibration I've ever had, by a significant margin. I told it to anneal everything except the arm length. After I get this perfected, I'm going to upload a new release of my firmware. After that, I'm looking at developing an expansion system that will let Smoothie drive more steppers.

Pushed an updated version: Right-click, save as.

Changes:

• Made Z-probe repeatability slightly better through a slight tweak in ZProbe.cpp. This may help avoid a minor race condition.
• Added support for using RMS evaluation metric, as opposed to the default, which is the mean. Specify X1 (mean) or X2 (RMS) when you run simulated annealing.
• Fixed G31 help. Some lines were getting eaten by Repetier.
• Changed some G-codes to make G31 more compliant with the G-code standard. Iterations are now specified with E rather than T.
• Adjusted the test ranges a little.
• Let the kernel run its idle loop once per annealing iteration. Checks for halted status during that time.

Nice. Thanks for those updates and getting that all checked in.

I have been merging up from upstream edge and so far I have made it up to commit 43b718c https://github.com/626Pilot/Smoothiewar ... ddf06c7dc1 without relative trouble.

The next commit is where a bunch of structures changed.

I'll keep working on trying to merge the next commit from edge. After that one the following commits are fairly limited in scope and won't pose much of an issue.

I'll keep you updated on my progress.

chris.

NEW fw is looking sweet so far

Recv: [PR] Repeatability test: 10 samples (S)
Recv: [PR] Acceleration (A): 90.0
Recv: [PR] Debounce count (B): 1
Recv: [PR] Smooth decel (D0|D1): False
Recv: [PR] Eccentricity test (E): Off
Recv: [PR] Probe smoothing (P): 10
Recv: [PR] Probe priming (Q): 5
Recv: [PR] Feedrates: Fast (U) = 35.000, Slow (V) = 15.000
Recv: [PR] 1 step = 0.01250 mm.
Recv: [PR] Test 1 of 10: Measured 400 steps (5.000 mm)
Recv: [PR] Test 2 of 10: Measured 400 steps (5.000 mm)
Recv: [PR] Test 3 of 10: Measured 400 steps (5.000 mm)
Recv: [PR] Test 4 of 10: Measured 400 steps (5.000 mm)
Recv: [PR] Test 5 of 10: Measured 400 steps (5.000 mm)
Recv: [PR] Test 6 of 10: Measured 400 steps (5.000 mm)
Recv: [PR] Test 7 of 10: Measured 400 steps (5.000 mm)
Recv: [PR] Test 8 of 10: Measured 400 steps (5.000 mm)
Recv: [PR] Test 9 of 10: Measured 400 steps (5.000 mm)
Recv: [PR] Test 10 of 10: Measured 400 steps (5.000 mm)
Recv: [PR] Stats:
Recv: [PR] range: 0 steps (0.0000 mm)
Recv: [PR] mu: 400.000 steps (5.000 mm)
Recv: [PR] sigma: 0.000 steps (0.000 mm)
Recv: [PR] Repeatability: 0.0000 (add a little to be sure)
Recv: [PR] This is your best score so far!
Recv: [PR] This score is very good!
Recv:

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

It's not.

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.

Cheers.

Arthur, what makes the bug so difficult to quash?
(Go full nerd - I've been a software developer for 30 years, I'll understand the write-up. )

g.

geneb wrote:Arthur, what makes the bug so difficult to quash?
(Go full nerd - I've been a software developer for 30 years, I'll understand the write-up. )

g.

First thing is : it's insanely difficult to reproduce. Same G-code file, same smoothie config, same way to interface it, same firmware, and sometimes even with all that you won't be able to reliably reproduce it ( ie everything works fine ).
We have a lot of Smoothie/S3D users, and many of them don't even seem to notice that the problem exists. But for *some* users ( typically users with organic high-detail models, often ones that use supports ), it can happen frequently on some of their prints ( which obviously is a problem ).

One user was able to enter a debugging ( gdb with mri ) session with the bug occuring on his machine ( I never succeeded here, and I tried *hard* ), and we had a remote debugging discution over gmail chat, which is far from efficient, but still allowed me to learn *a lot* about the bug.
I now know it's completely related to step generation ( not planning or anything else ), and it can only happen with the buffer full of very short moves, and that it *likely* has something to do with re-entrance and subtle timing. But I wasn't able to fully determine exactly *how* it occurs.
When it occurs, Smoothie essentially thinks it isn't done moving when it is, and I was never able to see that happen step by step, only to dissect Smoothie's entrails after it had just happened.

It's definitely something that could be fixed in the actual code, but that'd be insanely difficult with no way to reproduce the problem here locally. And it could also be fixed by doing some of our planned step generation refactors, which would do things in a more sturdy way, and would *very likely* fix the issue.