Simplify3D problem and possible solution

[Arthur Wolf]

Hello everybody.

This message is for anyone using S3D ( https://www.simplify3d.com/ ) in conjunction with a Smoothieware-based controller.

Several months back, a few users of Simplify3D have started reporting their Smoothieboard occasionally "froze" ( movement stops, heaters keep regulating temperature, panel stays responsible to input ).

After some investigation and ruling out other possible problems ( as we always do before to jumping to "it's a bug" ), it was determined that the problem only occurs with S3D ( no other slicer ) and Smoothieware ( no other firmware ), which is why we started referring to it as "the S3D bug" in the Smoothie community.

Debugging the problem was rendered extremely difficult by the fact that the bug is very complex to reproduce reliably ( some bugs are like that ). But with the help of the community, we were relatively quickly able to find out why the bug only occurred with S3D : simplify3D does not simplify high resolution models, resulting in uselessly high levels of detail in the G-code files ( long strings of moves up to 0.0002mm long are commonly found, which is 100 times smaller than some 3D printer resolutions ).
Other more mature slicers on the other hand do simplify the models, and so they are not concerned by this ( Slic3r lets you set the simplification resolution yourself but has a sane default, one user who changed the default reported this problem also ).

While rarely used to our knowledge, Kisslicer also does not simplify models and therefore is probably also subject to this problem.

With a lot of help from Leon Grossman, who had been able to reliably reproduce the problem, and was able to open a debugging session while the bug was occurring, we figured out why the bug only occurs with Smoothieware ( several edge cases related to floating point math and single-step movements, which do not happen unless insanely small movements are sent ).

Jim Morris devised some fixes for this bug in a separate branch ( https://github.com/wolfmanjm/Smoothie/tree/hack/s3d-fix-hack ). Leon has been testing it for many print-hours successfully, so we think it is time to ask the wider Smoothieware community to test these fixes, and tell us if for them also, they resolve the freezing problems.

I would like to emphasize that we have already proposed a possible fix for the community to test before, and while it did improve ( reduced the frequency of the problem ), it did not fix it completely. This was interpreted by some as claiming the bug was fixed but failing to actually fixing it, which is not what happened, we simply asked for the community's help in finding out if the fix was good or not, we did not claim it was a definitive fix.

This time again, we are not claiming this is 100% certain to fix the problem for everybody, but both our new understanding of the problem, and the testing that has been done so far, gives us very good confidence this could be definitively resolved. And so we ask for your help testing it.

If you want to help us test this fix, and in particular if you have ever experienced the freezing problem, here is the procedure :

1. Download the "firmware.bin" file attached to this message, or here : https://www.dropbox.com/s/yufuad7qj4e6ig4/firmware.bin?dl=0
2. Drop it onto your SD card
3. Reset the Smoothieboard. The file should be renamed to "FIRMWARE.CUR" automatically.
4. Use everything as normal
5. If the printer freezes, report here

Thanks a lot to all of you for all the help and support so far, thanks to all those who will test this.

We sincerely hope this is the end of the problems some of you have been experiencing. Hopefully S3D also fixes the problem on their end at some point, which would make things doubly nice.

A few more comments :

While this ( probably ) fixes the Smoothie "freezes" with S3D on high-resolution models, please note S3D still generates way too many tiny movements ( up to 100 times too many ), meaning Smoothie will have to slow down as it can't look ahead far enough to compute acceleration correctly. This is also a problem you should experience with other firmwares in this case, and is simply an effect of the uselessly high level of detail.
Please don't hesitate to ask S3D to fix this, a few of you have already but with little effect so far.

Also, we really would like to insist on something : it has been mistakenly claimed by some, presumably due to making assumptions about Smoothie rather than relying on actual experience/understanding, that this bug causes Smoothie to keep heaters fully powered, which would likely result in burning the hotend. We want to re-assure everybody that this is absolutely not the case. Not only was this never reported by users, but it also is completely inconsistent with the other symptoms that were observed. Our current better understanding of the problem also confirms this.
It was also mistakenly claimed by some that the bug was in some way USB-related : this too was completely inconsistent with the user reports, and it is now very clear it is not the case.

Happy printing everybody ! Any feedback, questions or criticism is very welcome.

Cheers.

[Leon Grossman]

For anyone testing this bin file, I haven't had a problem in a few dozen hours of machine time. I'm hoping we can get more people to confirmthis fix than me so that I can rejoin the current edge branch soon. :)

[Walter Hsiao]

I tried the new firmware on the only file that would consistently freeze my printer. The print completed without any problems using the new firmware. The only way I could complete the print before without having it lock up was by removing all the duplicate and aliased gcode (20-30% of the file). My case may be a bit different from others, it was the S3D generated support material not the actual part that was causing problems and I'm running on a cartesian printer. Here's an excerpt of the S3D support material gcode:

G1 X104.209 Y209.772 E1.5296

G1 X104.210 Y209.773 E1.5296

G1 X104.211 Y209.773 E1.5297

G1 X104.211 Y209.773 E1.5297

G1 X104.212 Y209.773 E1.5297

G1 X104.213 Y209.773 E1.5297

G1 X104.214 Y209.774 E1.5297

G1 X104.214 Y209.774 E1.5297

G1 X104.214 Y209.774 E1.5297

G1 X104.215 Y209.774 E1.5298

G1 X104.215 Y209.774 E1.5298

G1 X104.216 Y209.774 E1.5298

G1 X104.217 Y209.775 E1.5298

G1 X104.218 Y209.775 E1.5298

G1 X104.218 Y209.775 E1.5298

G1 X104.220 Y209.775 E1.5299

G1 X104.221 Y209.776 E1.5299

G1 X104.221 Y209.776 E1.5299

G1 X104.222 Y209.776 E1.5299

G1 X104.223 Y209.776 E1.5300

G1 X104.223 Y209.776 E1.5300

G1 X104.224 Y209.776 E1.5300

G1 X104.224 Y209.776 E1.5300

[wolfmanjm]

If that isn't a bug in S3D gcode generation I don't know what is :)

[Leon Grossman]

Not a bug, just S3D making sure that the controller board knows that it really, really needs to go to X104.224, Y209.776, E1.5300. The controller might not think it was serious, otherwise. :)

[Leon Grossman]

I've already notified Arthur of this but I just ran into another (related?) extruder bug. Now, instead of stopping and hanging on a specific line, the extruder will go wonky somewhere in the print and not recover until reboot:

https://www.youtube.com/watch?v=9Qc0s1tDIdI

On Friday, October 2, 2015 at 5:13:15 PM UTC-5, Arthur Wolf wrote:

[Arthur Wolf]

Well that's sad.

We know we haven't fixed the bug, but there was a good chance the implemented changes would prevent it from happening.

Sounds like it's happening much less often, but it's still happening.

Properly fixing the bug is something we haven't figured out how to do yet, unfortunately.

I really wish S3D would fix things on their end so at least this wouldn't bother people anymore.

Thanks a lot for the report, we don't need to do the debugging thing again I think, we know what's going on now.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

[Leon Grossman]

Is there anything I can change in the config file to minimize likelihood of this problem? I've resliced this file and it's still causing problems. It's one I've printed before with different settings and it didn't fail.

I'd use Cura but the surface finish comes out textured and is perfectly smooth with S3D.

Back to some more testing prints...

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Arthur Wolf]

Ideally you'd want to code some sort of script that detects movements that are way too small, and merges them together ...

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--

You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Leon Grossman]

What would be way too small? I can write a parser to do that to test out. 

Sent from my phone

You received this message because you are subscribed to a topic in the Google Groups "Smoothieware Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/smoothieware-support/2r0JLV3G5i8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to smoothieware-sup...@googlegroups.com.

[Arthur Wolf]

I'd make this a variable you can set, and start testing with 0.01mm

[Walter Hsiao]

Here's some C++ code I hacked together a while ago to do filter out moves below the set movement and extrusion thresholds.  I'm not sure it will work with different S3D settings and startup / ending gcode (it definitely won't work if S3D is set to generate relative gcode).

#include <iostream>

#include <fstream>

#include <math.h>

using namespace std;

#define RESOLUTION_THRESHOLD .01f

#define EXTRUSION_THRESHOLD .0005f

string removeWhitespace(string s) {

    string::iterator end_pos = remove(s.begin(), s.end(), ' ');

    s.erase(end_pos, s.end());

    return s;

}

bool startsWith(const string &s, const string &prefix) {

    return (s.length() >= s.length() && s.find(prefix) == 0);

}

float getParameter(const string &s, char c, bool * found = NULL) {

    size_t i = s.find(c);

    if (i != string::npos) {

        if (found) *found = true;

        size_t n = s.find_first_not_of("-0123456789.", i+1);

        string valstring = s.substr(i+1, n-i-1);

        return atof(valstring.c_str());

    } else {

        if (found) *found = false;

        return 0;

    }

}

float xyDistance(const string &a, const string &b) {

    bool found = true;

    

    float aX = getParameter(a, 'X', &found);

    if (!found) return -1;

    

    float aY = getParameter(a, 'Y', &found);

    if (!found) return -1;

    

    float bX = getParameter(b, 'X', &found);

    if (!found) return -1;

    

    float bY = getParameter(b, 'Y', &found);

    if (!found) return -1;

    

    float dX = bX - aX;

    float dY = bY - aY;

    return sqrtf(dX*dX + dY*dY);

}

bool isRedundant(const string &a, const string &b) {

    if (!startsWith(a, "G1") || !startsWith(b, "G1")) {

        return false;

    }

    

    bool found = true;

    

    float aE = getParameter(a, 'E', &found);

    if (!found) return 0;

    

    float bE = getParameter(b, 'E', &found);

    if (!found) return 0;

    

    if (fabsf(aE - bE) < EXTRUSION_THRESHOLD) {

        // this distance check is probably unnecessary as travel moves are automatically filtered out (they don't have an E parameter)

        float dist = xyDistance(a,b);

        if (dist < 0) return false; // no distance data

        return dist < RESOLUTION_THRESHOLD;

    }

    return false;

}

int main(int argc, const char * argv[]) {

    if (argc < 2 || argc > 3) {

        cout << "usage: gcodefix [input filename] [output filename]\n";

        return 0;

    }

    string filename = argv[1];

    

    cout << "Parsing " << filename.c_str() << ":" << endl;

    

    // output file

    bool output = false;

    ofstream outstream;

    if (argc == 3) {

        output = true;

        string outfile = argv[2];

        outstream.open(outfile);

        if (!outstream.is_open()) {

            cout << "unable to open output file " << outfile.c_str() << "\n";

            return 0;

        }

    }

    

    

    // read file

    int totalCount = 0;

    int duplicateCount = 0;

    

    bool relativeMotion = false;

    string line;

    string previousLine = "";

    ifstream infile(filename);

    if (infile.is_open()) {

        while (getline (infile,line)) {

            totalCount++;

            

            // don't filter relative motion gcode

            if (startsWith(line,"G91")) {

                relativeMotion = true;

            } else if (startsWith(line,"G90")) {

                relativeMotion = false;

            }

            

            // ignore redundant gcode

            if (!relativeMotion && startsWith(line, "G1") && isRedundant(previousLine, line)) {

                duplicateCount++;

//                cout << totalCount << ": " << line << endl;

                continue;

            }

            

            if (output) {

                outstream << line << endl;

            }

            

            previousLine = line;

        }

        

        infile.close();

        if (output) {

            outstream.close();

        }

        

        printf("Finished: %d / %d Lines Removed [%f%%]\n", duplicateCount, totalCount, (duplicateCount * 100.0f)/totalCount);

    } else {

        cout << "Unable to open input file " << filename.c_str() << endl;

    }

    

    return 0;

}

[Leon Grossman]

I'm definitely not using relative moves so I'll see if I can do something with this. I had planned to create a LabVIEW app for testing but I can't do anything with that on a Mac so I'd have to make it on my work machine and run it in a VM at home.

This may bet he kickstart to get me to make some form of console app for mac.

[robin bussell]

There's a handy unix command "uniq" which can strip out all consecutive
duplicate lines for you too. It won't do anything about close moves but
might be worth it as a preprocess before your code gets to munch on it.


Cheers,
Robin.

On 13/10/2015 00:37, Leon Grossman wrote:
> I'm definitely not using relative moves so I'll see if I can do
> something with this. I had planned to create a LabVIEW app for testing
> but I can't do anything with that on a Mac so I'd have to make it on my
> work machine and run it in a VM at home.
>
> This may bet he kickstart to get me to make some form of console app for
> mac.
>
> On Monday, October 12, 2015 at 6:27:48 PM UTC-5, Walter Hsiao wrote:
>
> Here's some C++ code I hacked together a while ago to do filter out
> moves below the set movement and extrusion thresholds. I'm not sure
> it will work with different S3D settings and startup / ending gcode
> (it definitely won't work if S3D is set to generate relative gcode).
>
>
>
> #include <iostream>
>
> #include <fstream>
>
> #include <math.h>
>
>
> usingnamespacestd;
>
>
> #define RESOLUTION_THRESHOLD .01f
>
> #define EXTRUSION_THRESHOLD .0005f
>
>
> stringremoveWhitespace(strings) {
>

> string::iteratorend_pos = remove(s.begin(), s.end(), ' ');

>
> s.erase(end_pos, s.end());
>
> returns;
>
> }
>
>
> boolstartsWith(conststring&s, conststring&prefix) {
>

> return(s.length() >= s.length() && s.find(prefix) == 0);

>
> }
>
>
>
> floatgetParameter(conststring&s, charc, bool* found = NULL) {
>
> size_ti = s.find(c);
>
> if(i != string::npos) {
>
> if(found) *found = true;
>

> size_tn = s.find_first_not_of("-0123456789.", i+1);

>
> stringvalstring = s.substr(i+1, n-i-1);
>
> returnatof(valstring.c_str());
>
> } else{
>
> if(found) *found = false;
>
> return0;
>
> }
>
> }
>
>
>
> floatxyDistance(conststring&a, conststring&b) {
>
> boolfound = true;
>

> floataX = getParameter(a, 'X', &found);
>
> if(!found) return-1;
>
> floataY = getParameter(a, 'Y', &found);
>
> if(!found) return-1;
>
> floatbX = getParameter(b, 'X', &found);
>
> if(!found) return-1;
>
> floatbY = getParameter(b, 'Y', &found);

>
> if(!found) return-1;
>
> floatdX = bX - aX;
>
> floatdY = bY - aY;
>
> returnsqrtf(dX*dX + dY*dY);
>
> }
>
>
>
> boolisRedundant(conststring&a, conststring&b) {
>

> if(!startsWith(a, "G1") || !startsWith(b, "G1")) {
>
> returnfalse;
>
> }
>
> boolfound = true;
>
> floataE = getParameter(a, 'E', &found);
>
> if(!found) return0;
>
> floatbE = getParameter(b, 'E', &found);
>
> if(!found) return0;
>
> if(fabsf(aE - bE) < EXTRUSION_THRESHOLD) {

>
> // this distance check is probably unnecessary as travel moves are
> automatically filtered out (they don't have an E parameter)
>
> floatdist = xyDistance(a,b);
>
> if(dist < 0) returnfalse; // no distance data
>
> returndist < RESOLUTION_THRESHOLD;
>
> }
>
> returnfalse;
>
> }
>
>
>
> intmain(intargc, constchar* argv[]) {
>

> if(argc < 2 || argc > 3) {

>
> cout<< "usage: gcodefix [input filename] [output filename]\n";
>
> return0;
>
> }
>
>

> stringfilename = argv[1];

>
> cout<< "Parsing "<< filename.c_str() << ":"<< endl;
>
> // output file
>
> booloutput = false;
>
> ofstreamoutstream;
>
>

> if(argc == 3) {

>
> output = true;
>
> stringoutfile = argv[2];
>
> outstream.open(outfile);
>
> if(!outstream.is_open()) {
>
> cout<< "unable to open output file "<< outfile.c_str() << "\n";
>
> return0;
>
> }
>
> }
>
> // read file
>
> inttotalCount = 0;
>
> intduplicateCount = 0;
>
> boolrelativeMotion = false;
>
> stringline;
>
> stringpreviousLine = "";
>
> ifstreaminfile(filename);
>
> if(infile.is_open()) {
>
> while(getline(infile,line)) {
>
> totalCount++;
>
> // don't filter relative motion gcode
>

> if(startsWith(line,"G91")) {
>
> relativeMotion = true;
>
> } elseif(startsWith(line,"G90")) {

>
> relativeMotion = false;
>
> }
>
> // ignore redundant gcode
>

> if(!relativeMotion && startsWith(line, "G1") &&

> isRedundant(previousLine, line)) {
>
> duplicateCount++;
>
> // cout << totalCount << ": " << line << endl;
>
> continue;
>
> }
>
> if(output) {
>
> outstream << line << endl;
>
> }
>
> previousLine = line;
>
> }
>
> infile.close();
>
> if(output) {
>
> outstream.close();
>
> }
>
> printf("Finished: %d / %d Lines Removed [%f%%]\n", duplicateCount,
> totalCount, (duplicateCount * 100.0f)/totalCount);
>
>
> } else{
>
> cout<< "Unable to open input file "<< filename.c_str() << endl;
>
> }
>
> return0;
>
> }
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "Smoothieware Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to smoothieware-sup...@googlegroups.com

> <mailto:smoothieware-sup...@googlegroups.com>.

[Mikk Kiilaspää]

S3D won't do duplicate lines, only really tiny ones.

> an email to smoothieware-support+unsub...@googlegroups.com
> <mailto:smoothieware-support+unsub...@googlegroups.com>.

[robin bussell]

On 13/10/2015 19:22, Mikk Kiilaspää wrote:
> S3D won't do duplicate lines, only really tiny ones.
>

I was just going by the sample posted in this thread on 8/10/15, there
are definately lots of duplicates, and even one triplicate :

G1 X104.209 Y209.772 E1.5296
G1 X104.210 Y209.773 E1.5296
G1 X104.211 Y209.773 E1.5297
G1 X104.211 Y209.773 E1.5297
G1 X104.212 Y209.773 E1.5297
G1 X104.213 Y209.773 E1.5297
G1 X104.214 Y209.774 E1.5297
G1 X104.214 Y209.774 E1.5297
G1 X104.214 Y209.774 E1.5297
G1 X104.215 Y209.774 E1.5298
G1 X104.215 Y209.774 E1.5298
G1 X104.216 Y209.774 E1.5298
G1 X104.217 Y209.775 E1.5298
G1 X104.218 Y209.775 E1.5298
G1 X104.218 Y209.775 E1.5298
G1 X104.220 Y209.775 E1.5299
G1 X104.221 Y209.776 E1.5299
G1 X104.221 Y209.776 E1.5299
G1 X104.222 Y209.776 E1.5299
G1 X104.223 Y209.776 E1.5300
G1 X104.223 Y209.776 E1.5300
G1 X104.224 Y209.776 E1.5300

Cheers,
Robin.

[Mikk Kiilaspää]

Wow, aint that cute.
I guess I saw another sample somewhere where exactly 1 number was changed per line (one axis at a time).

[Leon Grossman]

Walter,

Thanks for uploading this. I compiled it for my Mac and am testing a failed gcode file now.

On Monday, October 12, 2015 at 6:27:48 PM UTC-5, Walter Hsiao wrote:

[Leon Grossman]

Hold the phone! I made a mistake.

So, I have been getting prints that stop extruding half way up but continue to completion. When I did the extrude at the end, the weird jittering noise happened.

I don't know why the extrusion keeps stopping other than PCTPE being a harder material to work with and maybe it's jamming but the key element is that I was testing the motor AFTER the test completed and my GCODE end script leaves T1 active. One of the wires had pulled out of the T1 motor so I was experiencing a hardware problem with motor 1 and I think the hack fix is OK.

[Arthur Wolf]

Wow that's super good news !

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Leon Grossman]

I've compiled Walter's C code and made an OSX console app to fix the gcode and I ran on a self-compiled edge with the resume fix and the air print ran to completion.

So,now I'm in the position of choosing between the code that has working suspend/resume for me or working S3D compatibility but, at least I can work around the S3D problem until things are merged.

Let me know if there's anything I can do.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[JFettig]

I have printed a few parts with S3D and smoothie but I'm wondering if I just ran into this issue, I'm printing the skirt to prime my extruder and it only gets about half way through and then it sounds like the stepper motors are singing - missing steps at a super high rate. Extrusion stops, motion stops, its not hitting anything. I just installed that firmware and so far its working. 

It did this in the first perimeter of the skirt, glad it didn't wait longer to do it.

[Leon Grossman]

Yes, that sounds like it is the problem this firmware solves. I'm glad to hear it is working for you.

[Craig Cavanaugh]

I did some poking and it looks like this fix has yet to make it main release.  Did I fall out of the boat?

I'm considering purchasing a license of S3D and want to make sure I have a grasp of all options including holding out on S3D for awhile.

Thanks!

[wolfmanjm]

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.

[JFettig]

I'm not sure how this is a bug of any sort on S3D side as even the crappiest, slowest printer boards will work just fine with their code. Seems kind of arrogant to fix some bugs and act like other bugs aren't your problem because you don't use, or like their software. Same goes for ignoring the line endings generated by a windows machine like Mac and Linux are the best thing ever and to use smoothie I have to switch over to mac or linux. F that.

Everyone told me how awesome smoothieboard was and how it was the best and most complete firmware ever so I bought one, but in reality it isn't even close to other firmware out there. End stop calibration doesn't even work most of the time - it diverges from a solution rather than converging.

/rant

[Arthur Wolf]

Hey :)

On Sat, Nov 28, 2015 at 5:58 PM, JFettig <jfe...@gmail.com> wrote:

I'm not sure how this is a bug of any sort on S3D side as even the crappiest, slowest printer boards will work just fine with their code.

It actually doesn't "work fine".

Simplify3D generates Gcode with insanely/uselessly fine resolution ( you'll see as much as 100 lines of g-code to move distances lower than most printer's resolution ). Other slicers do not do this, and work fine.

The slower firmwares essentially just slow down because they aren't able to handle that density. Smoothie is better able to cope with the density, *but* in some extreme situations, this will cause problems in Smoothie as it was not designed with stupid ( some ) G-code problems in mind.

We really wish S3D would just fix what is extremely obviously a bug on their end. Some users have created scripts and tools that allow you to fix their Gcode yourself, the code for these tools is insanely simple, and it's just impossible to understand why S3D wouldn't do the effort of integrating that fix into their products. Instead they have been denying the problem exists, and censoring users that complain about it.

 

Seems kind of arrogant to fix some bugs and act like other bugs aren't your problem because you don't use, or like their software.

Smoothie is open-source work, none of the developpers ( who do this work for free ) have an obligation to fix anything more than what they want to fix.

The developers DO produce a lot of code, and fix a lot of things, and want to make the software as good as it can be. But they do not OWE you anything.

This is not the developers being arrogant, this is you unduly feeling you are owed something you are not.

If you want to be owed something, buy a $2500 industrial 3D printer control system.
Smoothie is open-hardware and open-source, created by the community for the community, and even if nobody was listening to what you want fixed ( which is not the case ), you'd still be getting a pretty great deal using it.

However, even though there is no obligation for the devs to fix anything, there *was* a fix developed for the S3D bug, both inside Smoothie ( in a separate branch ) and as separate gcode-cleaning tools. I'm not sure what more you want.

A LOT of work went into figuring out and fixing that issue, when S3D could have resolved it much more easily on their end, so you can understand how

 

Same goes for ignoring the line endings generated by a windows machine like Mac and Linux are the best thing ever and to use smoothie I have to switch over to mac or linux. F that.

Plenty of Windows-based text editors respect the file's line ending format when saving it, which is the smart thing to do. Just use any of those.  No need to use mac or linux. There are literally thousands of Smoothie+windows users ...

Everyone told me how awesome smoothieboard was and how it was the best and most complete firmware ever so I bought one, but in reality it isn't even close to other firmware out there.

 I'm sad that's what you thing.

End stop calibration doesn't even work most of the time - it diverges from a solution rather than converging.

It is known to work perfectly fine, what is the problem you are encountering ?

Cheers.
 

/rant

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--

You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[JFettig]

Its actually your attitude towards everybody and everything not smoothie that turns me off. Not so much others.

Like I said before - regardless how fine the g-code is, it still works on other controllers, I have never had any weird slowdowns on my rambo driven delta and the models I generate frequently have .0001" tolerance(frequently 50-100mb stl files) Its not a S3D problem, the G-code works fine, its how its handled in smoothie firmware.

The end stop calibration diverges rather than converges. if its .05mm off, the next step will be .1mm off, it bounces around repeatedly until it gets lucky, if it gets lucky. The delta printer I designed and built has been built to a degree of accuracy that very few have been built to so it shouldn't have any issues converging.

Hey :)

/rant

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Arthur Wolf]

On Sat, Nov 28, 2015 at 6:27 PM, JFettig <jfe...@gmail.com> wrote:

Its actually your attitude towards everybody and everything not smoothie that turns me off. Not so much others.

I'm not sure what you are talking about ... Care to elaborate ?

Like I said before - regardless how fine the g-code is, it still works on other controllers, I have never had any weird slowdowns on my rambo driven delta and the models I generate frequently have .0001" tolerance(frequently 50-100mb stl files)

Maybe you have been lucky. Many have had extreme slowdowns due to S3D's gcode. Many of the files we've seen generated by S3D are essentially *impossible* to execute at the requested speeds, even on Smoothie, and even more on 8-bit hardware.
 

Its not a S3D problem, the G-code works fine, its how its handled in smoothie firmware.

The fact that it works fine for you doesn't mean it's sane, or that it isn't stupid, or that it works for others.

As a matter of fact, it *is* stupid ( and other more matures slicers are more clever ), it is not sane ( no controller should have to be designed for all possible stupid gcode errors ), and it doesn't work for other rambo and rambo-like users.

S3D's Gcode has an *extremely* higher density than what is required.
That is a bug is S3D ( a bug other slicers have had in the exact same way, have recognized as a bug, and have fixed ).

Smoothie wasn't designed to handle Gcode that has this specific problem, and that hasn't been a problem for years, until S3D started being used, and the problem became apparent.

And the fact that other firmwares do not have as much of a problem with it is just down to luck, they just happen to have a different way of generating steps, they might just as well have had this problem.

This is a S3D bug. Smoothie wasn't designed to handle slicers that have that specific bug. In the next version we'll probably take better care that this can't be a problem, but that doesn't change the fact that the source of the problem IS S3D.

The end stop calibration diverges rather than converges. if its .05mm off, the next step will be .1mm off, it bounces around repeatedly until it gets lucky, if it gets lucky. The delta printer I designed and built has been built to a degree of accuracy that very few have been built to so it shouldn't have any issues converging.

You probably want to start a forum or mailing list thread or github issue for that specific problem, that is not normal, and it's unlikely it is a smoothie bug ( though if it is, we want to know ).

Are you certain about your probe's accuracy ?

Cheers.

Hey :)

/rant

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[JFettig]

You're always coming in swinging, read your own posts in regards to alligator board, all the S3d related posts on the S3d boards(if they weren't deleted), etc.

Extra moves in a g-code file isn't a bug, it is still functional code. It suddenly became a "bug" because it doesn't work with your firmware. 

I tested my probes accuracy(its actually the same as my end stop switch) and it repeats to .0005"

Hey :)

/rant

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Arthur Wolf]

On Sat, Nov 28, 2015 at 7:16 PM, JFettig <jfe...@gmail.com> wrote:

You're always coming in swinging, read your own posts in regards to alligator board,

Could you point me to what you are talking about ?
 

all the S3d related posts on the S3d boards(if they weren't deleted), etc.

This is the only thing I posted to the S3D forums : https://forum.simplify3d.com/viewtopic.php?f=23&t=3058 I'm not sure where I'm swinging ...

Extra moves in a g-code file isn't a bug,

They are.

Other slicers have had them, users have complained, it has been treated as a bug, and has been fixed.
 

it is still functional code.

Obviously not, if it slows down some boards, and makes another crash when they crash fine with all other slicers ...

It's possibly "legal" code, but it's definitely not functional.

Gcode is not just about being made of ascii characters, it's also about representing something that actually makes sense.

S3D used to generate gcode with F0 ( speed of 0 ) parameters. While that is "legal" gcode, it doesn't actually make sense, and it shouldn't be generated.

 

It suddenly became a "bug" because it doesn't work with your firmware. 

It was a bug before that, and it caused problems to users before that.

I tested my probes accuracy(its actually the same as my end stop switch) and it repeats to .0005"

Then please instead of saying there is a problem with Smoothie without knowing if that's true or not, open a new thread in one of the community channels ( forum, mailing list, github ).

Cheers.

Hey :)

/rant

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[John Gelnaw]

On Saturday, November 28, 2015 at 12:38:53 PM UTC-5, Arthur Wolf wrote:

On Sat, Nov 28, 2015 at 6:27 PM, JFettig <jfe...@gmail.com> wrote:

Its actually your attitude towards everybody and everything not smoothie that turns me off. Not so much others.

I'm not sure what you are talking about ... Care to elaborate ? 

I know the question wasn't aimed at me, but I feel this is an appropriate location to throw my negligibly small change in.  You said in an earlier post that:

Smoothie is open-source work, none of the developpers ( who do this work for free ) have an obligation to fix anything more than what they want to fix.

The developers DO produce a lot of code, and fix a lot of things, and want to make the software as good as it can be. But they do not OWE you anything.

This is not the developers being arrogant, this is you unduly feeling you are owed something you are not.

First, I would say that instead of "as good as it can be", the attitude is "as good as the developers want it to be".  Secondly, you probably consider this a positive statement-- I consider it a negative one.  Am I *owed* for purchasing a Genuine Smoothieboard, and spending time trying to get it to work, and spending time helping other people getting it to work?  Probably not, although most people who sell a product understand that supporting that product (and if you don't think the firmware is part of the smoothie purchase, well.... you should put that disclaimer on the box), will lead to future sales and growth.

If you want to benefit from a larger community, you have to drive the growth of that community, and I'm not seeing any interest from the smoothie developers.  You seem more interested in a gated community-- do it our way, or get out.

Certainly, you're hostile to anyone who buys an AZSMZ or an MKS SBase... and that's not entirely unreasonable.

But you're not much less hostile towards people who actually bought a Smoothieboard.

Smoothie is not customer driven, it is driven solely by the interests of the hardware and software developers-- That's not necessarily a bad thing, but as soon as you hit an area that the devs aren't interested in fixing, the response is "Fix/Write/Do it yourself"-- a standard Open Source Community response.

The problem is, I have a job.  I have a personal life.  I occasionally have free time.  But I'm not going to take the time to refresh my memory on C++, learn your codebase, and write a module to make (as an example) an LCD panel work, which may break the next time you put out an update.  Instead, I'll put the smoothieboard in a box, and ignore it until such a time as I have a project that works for it, or the devs actually decide to have similar interests to mine.  

Similarly, I won't fork an OSS software package to fix a problem I consider irritating-- because the amount of effort (for me) is completely out of proportion to the amount of benefit (to me).

Certainly, I'm sure you, and the other smoothie developers have a similar attitude-- but in theory, you're providing for the community, and maybe, selling hardware.  You're the experts on this hardware, and software-- what might take me several weeks to put together the resources to change, you should be able to do in half an hour-- if you cared.  

And there's the problem-- the belief in the 3D printing community, from the people I've spoken to, is that the smoothie devs don't really care about user complaints.  As soon as the complaint moves out of the developers' comfort zone, the problem is the user's problem, not smoothie's, and as an end user, the only option is to fix it yourself, or find a product that works better for you.

[Arthur Wolf]

On Sat, Nov 28, 2015 at 7:54 PM, John Gelnaw <jge...@gmail.com> wrote:

On Saturday, November 28, 2015 at 12:38:53 PM UTC-5, Arthur Wolf wrote:

On Sat, Nov 28, 2015 at 6:27 PM, JFettig <jfe...@gmail.com> wrote:

Its actually your attitude towards everybody and everything not smoothie that turns me off. Not so much others.

I'm not sure what you are talking about ... Care to elaborate ? 

I know the question wasn't aimed at me, but I feel this is an appropriate location to throw my negligibly small change in.  You said in an earlier post that:

Smoothie is open-source work, none of the developpers ( who do this work for free ) have an obligation to fix anything more than what they want to fix.

The developers DO produce a lot of code, and fix a lot of things, and want to make the software as good as it can be. But they do not OWE you anything.

This is not the developers being arrogant, this is you unduly feeling you are owed something you are not.

First, I would say that instead of "as good as it can be", the attitude is "as good as the developers want it to be".  Secondly, you probably consider this a positive statement-- I consider it a negative one.  Am I *owed* for purchasing a Genuine Smoothieboard, and spending time trying to get it to work, and spending time helping other people getting it to work?  Probably not, although most people who sell a product understand that supporting that product (and if you don't think the firmware is part of the smoothie purchase, well.... you should put that disclaimer on the box), will lead to future sales and growth.

The fact that doing work on the firmware leads to future sales and growth doesn't mean it's something that's owed.

It's a good thing, *and it's one we do and many others don't*, but it's not something that we *have* to do.

There are dozens of reprap and/or open-source-fabrication related controller boards. Only a few of those have people who both sell them, and have anything to do with the coding of the firmware that the board runs.

Most sellers have not designed their own board and do not have anything to do with the firmware. Do they put a disclaimer on their box ??

Most board designers ( seller or not ) have nothing to do with the firmware.

I personally happen to be involved in both the firmware's development, and the board's development and sales. This is an anomaly, not the rule. This is something most people I interact with are thankful for, not something they feel they are owed.

I started the work on the firmware for myself, shared it with others so we could make it better together, and started working on a board when people started saying it'd be nice if we had something to run the firmware on ( before smoothieboard we had http://smoothieware.org/smoothie-on-a-breadboard ).

I sell Smoothieboards, I DO NOT sell smoothie firmware. If you buy a Smoothieboard, you can run the firmware the community wrote for it, or write your own if you'd like.

If your board is broken, I'll replace it, if it has a design flaw, I'll work on fixing it. But if you don't like something in the firmware, then you are not talking to a seller, you are talking to somebody who is doing this firmware for free, and you should take that into consideration.

You do not pay for the firmware.

 

If you want to benefit from a larger community, you have to drive the growth of that community, and I'm not seeing any interest from the smoothie developers.  You seem more interested in a gated community-- do it our way, or get out.

This statement is insane ( though probably on accident ).

Try to get something into Marlin and try saying that again.

The Smoothie project was *designed from the start* to be inclusive. It is *one of the project's major goals* to reduce the necessity for forking. The code itself is designed to make this goal easier, and we put A LOT of effort into it.

We also support 3D printers, laser cutters, and CNC mills specifically so that more people get together to work on this.

The vast majority of code contributions people have proposed to Smoothie have been merged in. We *are* more demanding in terms of code quality and overall sanity than others, but that's a good thing ! And if you get your code clean enough, it'll get in !

And putting contributors aside, we are most definitely not a gated community either. We have a forum, two mailing lists, a G+ community, the biggest IRC channel of any firmware, all extremely active.

People are actually impressed by how much help they can get.

And we are very welcoming.

Certainly, you're hostile to anyone who buys an AZSMZ or an MKS SBase... and that's not entirely unreasonable.

Please give me a single link where I was hostile to a user for having an azsmz or a sbase. 

Most of them, when you talk through it, actually don't even realize they bought a closed-source board, and are surprised or even upset when they realize it. Why would I be hostile towards them ??

I *do* tell them what they board is, and that due to what it is, they should contact the seller rather than expect help from a community the seller is not helping. But I most of the time *also* end up helping them anyway ...

But you're not much less hostile towards people who actually bought a Smoothieboard.

Please give me a link.
 

Smoothie is not customer driven, it is driven solely by the interests of the hardware and software developers--

It is most definitely not. I have no idea where you get that from.

That may be the case for some Smoothie's devs, but it doesn't mean it is for all of them.
 

That's not necessarily a bad thing, but as soon as you hit an area that the devs aren't interested in fixing, the response is "Fix/Write/Do it yourself"-- a standard Open Source Community response.

That is not the truth at all.

The collosal majority of problems users have pointed out have gotten fixed since they have been.

People that *are in a hurry* to have their specific problem fixed, can indeed hear said that they are welcome to fix it themselves. And you know what ? Often they do !

But the Smoothie devs have TIME AND TIME AGAIN worked on features and fixed problems, that they personally had no interrest in working on !

You just can't tell them you are OWED this or that.
 

The problem is, I have a job.  I have a personal life.  I occasionally have free time.  But I'm not going to take the time to refresh my memory on C++, learn your codebase, and write a module to make (as an example) an LCD panel work, which may break the next time you put out an update.  Instead, I'll put the smoothieboard in a box, and ignore it until such a time as I have a project that works for it, or the devs actually decide to have similar interests to mine.  

Similarly, I won't fork an OSS software package to fix a problem I consider irritating-- because the amount of effort (for me) is completely out of proportion to the amount of benefit (to me).

Certainly, I'm sure you, and the other smoothie developers have a similar attitude-- but in theory, you're providing for the community, and maybe, selling hardware.  You're the experts on this hardware, and software-- what might take me several weeks to put together the resources to change, you should be able to do in half an hour-- if you cared.  

I care about everything every single Smoothie user wants. Other devs do not, but they shouldn't be blamed for not caring. And the fact they don't shouldn't hide the fact I do.

And the fact I care about everything every single Smoothie user wants, doesn't mean I CAN satisfy all of those desires. I try as hard as I can. I barely do anything else, ever. And I don't even *have* to. Others sure don't.

The more you do, the more people think you should do it seems. And the less you do, the less people seem to notice you are not doing anything.

That's insanely annoying.

And there's the problem-- the belief in the 3D printing community, from the people I've spoken to, is that the smoothie devs don't really care about user complaints.  

That's an extremely unfair misunderstanding.

It's really a fallacy, that a few people have been repeating around, because they are upset for reasons completely independent of this problem.

I really wish this'd stop and I could go back to doing things for Smoothie users ...
 

As soon as the complaint moves out of the developers' comfort zone, the problem is the user's problem, not smoothie's, and as an end user, the only option is to fix it yourself, or find a product that works better for you.

That's just not true. You misunderstand, or have been lied to.

Cheers :(

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ryan Turner]

Its pretty clear that the Simplify output is awful and should be fixed on their end, but isn't it also an issue if malformed g-code can cause the board to freeze?  Why not include the solution if it already exists?

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Arthur Wolf]

On Sat, Nov 28, 2015 at 9:35 PM, Ryan Turner <r6911...@gmail.com> wrote:

Its pretty clear that the Simplify output is awful and should be fixed on their end, but isn't it also an issue if malformed g-code can cause the board to freeze?  

It definitely is a problem on Smoothie's side too.

Nobody has ever denied that.
 

Why not include the solution if it already exists?

The problem here is : to truly and properly fix this, we'd essentially need to completely rewrite the way Smoothie generates steps, so it is much more robust.

What we have now was good enough for everybody, until S3D came in and produced awful output ... so you can see how we could be reluctant to start a massive refactor, when this bug does not occur in "normal" use of the firmware, and it can be fixed by S3D doing a tiny bit of work, or by cleaning the gcode before passing it to Smoothie.

We *will* change the way steps are generated, and make it much more sturdy, in v2, that is one of the design goals.

About the "solution" ( which is different from the refactor I mentionned ), the problem is it is quite dirty, and Smoothie has a rule about not including dirty code. However, that solution is available to anyone who wants to use it, they just have to use a separate branch, which is not much trouble ... It just won't get included into the "main" smoothie branch, that's all, it can still be used.

Cheers.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--

You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[wolfmanjm]

There is a bug in smoothie that these extremely small segments can trigger. The reason it has not been fixed is the bug has not been found. I personally cannot recreate the bug so i cannot debug it further.
the attempts to debug it have failed so far. It is an extremely hard bug to find.

I was pretty clear in my answer above that the "fix" we had in the code was a workaround NOT a fix, and it did exactly what the current crop of postprocessors do and as it is a hack it does not belong in the mainline code. It was added to try to isolate what in the S3D gcode was causing the issue, once we isolated that the postprocessors were written to do the same thing. It basically avoids triggering the smoothie bug.

If the bug is ever tracked down of course it will be fixed and released.

[Mark Rehorst]

Are the people who write the interpreter supposed to build tests/fixes into their code for every possible anomalous pattern in the gcode?  How would you anticipate every possible weird problem that could crop up?  If the gcode chopped every 1mm of movement into 10, or 100, or 1000, or 10,000, or 1M segments, at what level would you say that the gcode generator had a problem?  Would you say that the fix should be applied at the gcode interpreter or at the source?  Maybe I'm weird but to me it seems that problems should be fixed at the source.  I'd say that if you use S3D and want to use a SmoothieBoard, first complain to S3D about their gcode and then get one of the available fixes that run on SmoothieBoard when S3D ignores your complaint, or quit using S3D, or quit trying to use a SmoothieBoard.  Instead of giving the SmoothieWare developers a hard time, direct your vitriol at the source of the problem, S3D who charges you for their defective product.

I am pleased with the quality and performance of both the SmoothieBoard and SmoothieWare and have been very satisfied with the support I have received.  If you guys have functional SmoothieBoards you'd like to get rid of, I would consider making an offer.  I could use 2 more of them.  I'm not interested in Chinese clones.

If you don't have SmoothieBoards, what are you complaining about?

[Ryan Turner]

Thanks, I must have missed an earlier explanation.  To be honest I had started to skim since we probably have 100+ posts on this topic.  

I agree that dedicating dozens or hundreds of hours to tracking down a bug that cannot occur in regular use would be a poor use of time.

[Halsen]

I slice with MatterControl and use the X5 mini board and have the same Freezing issues. I often have prints quit at different spots while using the same gcode file. Is it possible that prints will freeze at different points throughout while using the same gcode or would this be another issue?

[Mikk Kiilaspää]

This issue is exactly about freezing atbtandom points.

--
You received this message because you are subscribed to a topic in the Google Groups "Smoothieware Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/smoothieware-support/2r0JLV3G5i8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to smoothieware-sup...@googlegroups.com.

[Leon Grossman]

Not quite. The Simplify3D freeze will always freeze at the same spot for a given file. I'm not saying there's not a bug at play here but it is not likely to be *the Simplify3D bug".

To unsubscribe from this group and all its topics, send an email to smoothieware-support+unsub...@googlegroups.com.

[626p...@gmail.com]

I had an S3D user approach me about my delta calibration fork, asking if I could implement realtime position generation similar to how dc42's RepRapFirmware fork does it on the Duet. (It doesn't generate segments at all - delta positions are generated in realtime.) I agree that S3D generating one-micron-long moves is REALLY dumb. However, I think it's better for a printer to slow down every now and then and get through a print, than to have it just freeze for no apparent reason. I won't ask you to include it upstream, but I wonder if you could give me a little advice for implementing it for my users.

Robot.cpp already has support for one lambda function, CompensationTransform if I'm not mistaken, which I use to do a couple types of positioning correction (bilinear interpolation for Z-only bed correction, and surface normal). In another location, Robot does a check to see whether it needs to generate delta segments, and if not, it calculates the whole line as a single segment (as would make sense on a Cartesian printer). I had thought to add another option that would allow an arm solution (like LinearDeltaSolution) to specify a lambda function for real-time step generation. Would that be a reasonable way to do it? I think if a Duet running at 84MHz can handle it, so can a Smoothieboard running at 120MHz. If you find the code useful generally, I can make it into a feature and send a pull request.

I also figured out a simple fix to ZProbe.cpp that makes it significantly more repeatable, and it's REALLY easy to implement.

[Arthur Wolf]

Before we start working on eliminating segments, we'd need some good reason to do so. At this point I'm not sure there is any reason to believe that segment-less is any better ( for sufficient rates of segmentation ), and it would significantly increase code complexity, and cost quite a bit of processing time. I'm not saying it's impossible there is an improvement, I'm just saying i'd like to see some evidence that there is an improvement.

One thing to watch out for is : RRF can do it at 84Mhz, but for what kind of step generation rate ?

What's your probling improvement about ?

--

You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[626p...@gmail.com]

I thought there was some talk above about refactoring step generation for Smoothie 2. I'm not sure how fast they generate steps, and I'm also not sure segmentless is that big a deal. I can't tell the difference between a RRF-dc42 print and a Smoothie print, holding them side by side, although others claim they can see a difference. I was just wondering whether you thought a lambda function would be an OK way to go, so I could help out my users a little. My user is telling me he ran the post-processor and its output produces no motion.

Re: probing, I was wondering why my endstop probe was never very repeatable. I have a probe calibration routine that runs the probe a bunch of times, and it would always come back with a range of 3-5 steps - sometimes worse. I theorized that there could be some bad timing between that code and the axis motion interrupt. I figured that if I stored the stepper positions earlier in that method, and then averaged steps for all three axes (for deltas), it would be more accurate. Therefore, the positions are stored as soon as we get into the relevant code block, and then averaged later. Now my probe's range is 0-1 steps EVERY TIME I run the probe calibration, and I'm getting better auto-calibrations as well. I don't have this checked in anywhere yet, but you can see the code here: https://gist.github.com/626Pilot/ca6b2756db8fdb3df78c - you can ignore the stuff about decelerating on trigger, as it has nothing to do with this fix.

[Arthur Wolf]

About Smoothie2 yes there are very serious refactors planned both for the motion planner and the step generation. Not planning to do segment-less though.

If you want to do segment-less, I think a function in the arm solution would be the right place to put the math in, yes. It's going to require quite the massive refactor however ...

About the probing stuff, i'd ask jim morris for his opinion, he knows a lot about it.

On Thu, Dec 31, 2015 at 5:26 PM, <626p...@gmail.com> wrote:

I thought there was some talk above about refactoring step generation for Smoothie 2. I'm not sure how fast they generate steps, and I'm also not sure segmentless is that big a deal. I can't tell the difference between a RRF-dc42 print and a Smoothie print, holding them side by side, although others claim they can see a difference. I was just wondering whether you thought a lambda function would be an OK way to go, so I could help out my users a little. My user is telling me he ran the post-processor and its output produces no motion.

Re: probing, I was wondering why my endstop probe was never very repeatable. I have a probe calibration routine that runs the probe a bunch of times, and it would always come back with a range of 3-5 steps - sometimes worse. I theorized that there could be some bad timing between that code and the axis motion interrupt. I figured that if I stored the stepper positions earlier in that method, and then averaged steps for all three axes (for deltas), it would be more accurate. Therefore, the positions are stored as soon as we get into the relevant code block, and then averaged later. Now my probe's range is 0-1 steps EVERY TIME I run the probe calibration, and I'm getting better auto-calibrations as well. I don't have this checked in anywhere yet, but you can see the code here: https://gist.github.com/626Pilot/ca6b2756db8fdb3df78c - you can ignore the stuff about decelerating on trigger, as it has nothing to do with this fix.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[wolfmanjm]

I use a microswitch as a probe, and I get 1 step repeatability all the time (and I have 1/64 microsteps!). So basically I do not believe what you propose is necessary for everyone, maybe it helps you  but maybe you should get better probes?

One area that maybe a problem is that there is a call to on_idle between checking the probe status. If your branch has significantly increased the on_idle latency then that could account for your issues, I would suggest you reduce the on_idle latency in your branch. Also it is a known fact that if the sdcard is mounted to the host this will increase the on_idle latency significantly, so that is why there is a rule to not probe while the sdcard is mounted.

[wolfmanjm]

this really has nothing to do with the S3D bug... However I spent quite a bit of time looking at IK per step for deltas, including writing a brand new firmware (wolf3dware) on a CPU with an FPU which is what I think it requires to do properly.

However whilst working on this I upgraded my wolfstock large delta printer with new drivers that run at 1/128 and 1/64. Funnily enough I discovered that printing with regular smoothieware at 1/64 removed all traces of anomalies (moire patterns and other things that deltas like to show on prints). To be honest I really doubt that doing IK per step can print any better than what I have now and I use segmentation of 100segs/sec. Yes the current delta stuff is an approximation of real delta IK, but it works perfectly well and at the resolutions current deltas are capable of I don; tthink segmentation can affect the quality at all, and in fact have proven that with my delta simulator. segmentation introduces micron resolution errors which is an order of magnitude less than what deltas can actually print at.

So basically I think IK per step is a waste of time ;) at the moment.

On Thursday, December 31, 2015 at 8:26:11 AM UTC-8, 626p...@gmail.com wrote:

[626p...@gmail.com]

This is really good information. Thank you. The only CPU-significant thing my branch does outside its own code is to register a CompensationTransform callback, and I don't think that would increase the idle time. The callback is disabled during some probing operations, but not all, because it's required for plane normal compensation and bilinear-interpolated Z correction. It seems probable that the time it takes to run (which is as CPU-efficient as I know how to make it without using assembly) could be making the interrupt take longer to run.

I did get ~1-step repeatability when I was using a Hall-O probe, but those are $20 vs. about $2 for an endstop probe. I had to implement deceleration after probe hit to get those numbers. However, with the minor change I made to wait_for_probe(), I can get the same results with a much cheaper device - no probe decel required. I'm not sure what 1/64th microstepping might be doing for your repeatability, but Smoothieboards today don't have that. I guess I could try to find a fancier endstop switch, use RF-shielded cable, etc., and tell my users to as well, but this simple change takes a few minutes and produces better results on the hardware people already have.

I don't think I will write in support for segmentless step generation. Setting segment generation to 100 steps/mm would already approach the max resolution of the steppers. Anything finer than that will be quantized out of existence, so it isn't worth the effort. Additionally, I don't believe it would solve the issue with S3D's g-code. There isn't a 1:1 mapping between their tiny cold virus-sized moves, and the steps that have to be sent to the motors.

Instead, I will probably either integrate the above patch into my fork, or write my own code that uses an accumulator (holds XYZ coords) to coalesce any moves that are shorter than the printer's stepper resolution. (This would be approximated using the axis steps/mm. Should be close enough.) All the tiny little cold-virus-sized commands would move the accumulator, but their lines would otherwise be thrown away and no moves would be appended to the queue. Once a command was received that actually did have an endpoint far enough from the last valid one that we could do something with it, we'd append a line going from the accumulator position to the current line's endpoint. The firmware might still slow down a lot in a few places, but it would never halt. There could be oozing, rough corners, etc., but it would at least finish the print.

Maybe in a few years, when we have crazy space alien technology on 3D printers, it will make sense to have segmentless step generation. For now, it seems to me like slapping a sticker on your car to make it go faster.

[wolfmanjm]

I already implemented a work around for S3D which does something similar to what you suggest but not as complicated. However I will not merge it into edge as the numerous gcode post processors do a better job of working around the bad gcode generation. It is also more efficient to post process the gcode as it results in less traffic.

[David Crocker]

626p, you said "Setting segment generation to 100 steps/mm would already approach the max resolution of the steppers", however what you actually set is segments/second. At 100 segments/second and 50mm/sec print speed, the segments will be 0.5mm long.

The main reason I implemented segmentation-free IK in RRF was that segmentation seemed to me like a nasty hack. I see these potential disadvantages of using segmentation:

- The segmentation causes straight lines to be not truly straight. This might or might not lead to patterns. I haven't worked out what the worst-case mid-point error of a 0.5mm segment is, but it will be small.

- At the segment boundaries, the head position has to be quantised to the nearest microstep for each of the motors. So the steps are no longer generated in smooth trains. This is probably not significant.

- I would have needed to explain to non-technical users what the segments-per-second parameter was for, and how to set it. I don't regard "experiment to see what works best" as satisfactory.

- Segmentation places a greater load on the planner, although I guess this is no worse than curves do anyway.

I was implementing delta kinematics starting from a blank sheet, so with these potential issues it made sense for me to to go the segmentation-free route. Until someone does a comparison of the same printer, using 0.9deg/step motors, printing the same parts with and without segmentation, I guess we won't know whether it makes any difference in practice.

It isn't necessary to have an FPU for segmentation-free IK, because all the time critical calculations can be done in integer maths - mostly 32-bit but with some 64-bit. I'm not sure that a single-precision FPU as on the ARM Cortex M4 would be much help, because it provides only 24 significant bits. As to speed, with 160 steps/mm the speed of RRF on a Duet tops out at 300mm/second. At high speeds I calculate the IK every 2, 4 or 8 steps, so effectively I am doing micro segmentation with 14000 segments/second. At these speeds the step pulse rate approaches or exceeds the chopper frequency, so the loss in smoothness of the pulse train is not significant. In fact the top speed limit is largely due to the need to meet the minimum step pulse time for the driver chips.

There are several optimisations I can do if/when higher speeds are needed, such as generating the step pulses for different motors in parallel instead of sequentially, and reducing the number of operand bits that the integer square root handles (currently 62, but I think I could reduce it to around 40). You have a faster processor on the Smoothie, so the speed you could achieve would be higher anyway.

[626p...@gmail.com]

You are correct. I should have said segments/mm, which Smoothie lets you do. I did print a piece with RRF-dc42, and a very similar piece with my Smoothie fork - same spool, even. You can see them here: http://forum.seemecnc.com/viewtopic.php?f=61&t=9511&p=82102#p82102

Granted, these photos were taken with a cell phone camera, but other than some stringing on one of them (from overzealous retract settings) they both look pretty nice to me. They were both printed on a Rostock MAX METAL with 0.9-degree steppers on the axes, and 5.18:1 geared steppers pushing the filament through an E3D Cyclops.

If you're implementing delta kinematics from scratch, and the controller is fast enough, you may as well do instantaneous step generation rather than using segments. It makes sense to me that you would use that solution, and I see the elegance in it - everything as accurate as possible, no tuning, more future-proof. What's the step generation rate/sec in RRF-dc42?

[David Crocker]

RRF doesn't have a fixed step generation rate, because each step interrupt is scheduled for the earliest time that a motor needs its next step. The interrupt time is calculated to the nearest 0.4us, which is overkill so I will probably increase it to 1.6us when I next work in this area if the firmware. The current minimum interval between steps on my delta running at 300mm/sec is about 7.5us, so equivalent to 133kHz. To improve on it, I will need to generate the steps to multiple motors in parallel so as to maintain the 1us minimum step pulse width needed by the drivers.

On Tuesday, January 12, 2016 at 2:24:27 AM UTC, 626p...@gmail.com wrote:

...

[Arthur Wolf]

Hello.

A small update of the S3D issue :

* Simplify3D finally acknowledged the issue, and claims to have fixed it in their latest release ( https://www.simplify3d.com/software/release-notes/ )
* The latest major update to the Smoothie firmware ( http://smoothieware.org/blog:14 ), which is a complete rewrite of step generation, is expected to make Smoothie resistant, if you are using an older version of S3D, or some other new slicing program which would make the same mistake.

We'd really appreciate it if users of S3D and Smoothie would test the latest versions of both together.
And if you run into any problem, report it to both.

Cheers.

[Leon Grossman]

I just ran two large 6+ hour prints with large arcs using both the new firmware and the current S3D. I did not crash during either print!

[Marius Ioana]

I run 3 prints today and all failed one at 75%, one at 20% and the other one at 25%.

The problem seams not to be solved

[Arthur Wolf]

Hey.

Really sorry to hear that, the complaints had pretty much completely disappeared as far as I can tell.

Can you confirm you are using the very latest versions of both S3D and Smoothieware ?

Cheers.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Michael Thompson]

Not finding much data online in reference to my issue so I figured I'd give it a go and post it here and hope for the best:

So I picked up a PowerSpec Ultra that the electronics have also been replaced with a MKS SBase V1.3 32 Bit board compatible of 1/32 micro stepping and a touch screen LCD, Titan, and E3D V6 hotEnd. Trying to load up a profile and cant apparently a Printer...so I did other. Select Reprap for firmware and heated bed. Brought in a small test square 2" x 2" x .2". Load up the SD card with sliced file...and does nothing at all....looks like its "going" thru the motions of printing.....WITHOUT the pre-heat process of extruder or hot bed...but extruder is not moving. Load back one of my other profiles used on my FlashForge/PowerSpec/MicroCenter printer and give it a go......this time the extruder starts to move into an incorrect position and lands near an offbed area and start to actually look like it printing. Baring the fact that the extruder is not heated...nothing apparently comes out. So manual preheat bed/extruder and try again...same off bed area printing but does infact start to extrude since the extruder has been preheated.

Looks like I am missing alot of configurations with using the "Other" during the Configuration Assistant...as looking at the gcode for the new "Other" printer and my other the start up script is only 1 line: G28 ; home all axes vs my other working profiles (on other printers):

; **** Replicator 1 dual start.gcode ****
M73 P0 ; enable build progress
G162 X Y F3000 ; home XY maximum
G161 Z F1200 ; home Z minimum
G92 Z-5 ; set Z to -5
G1 Z0 ; move Z to 0
G161 Z F100 ; home Z slowly
M132 X Y Z A B ; recall home offsets
M135 T0 ; load right extruder offsets
G1 X150 Y-70 Z30 F9000 ; move to wait position right hand side of the table
G130 X20 Y20 Z20 A20 B20 ; lower stepper Vrefs while heating
M126 S[fan_speed_pwm]
M140 S[bed0_temperature] T0
M134 T0 ; stabilize bed temperature
M104 S[extruder0_temperature] T0
M104 S[extruder1_temperature] T1
M133 T0 ; stabilize right extruder temperature
M133 T1 ; stabilize left extruder temperature
G130 X127 Y127 Z40 A127 B127 ; default stepper Vrefs
G92 A0 B0 ; zero extruders
G1 Z0.4 ; position nozzle
G1 X110 Y-70 E25 F300 ; purge nozzle
M135 T1; left tool
G1 X120 Y-70 E25 F300; purge nozzle
M135 T0; right tool
G1 X120 Y-70 Z0.15 F1200 ; slow wipe
G1 X110 Y-70 Z0.5 F1200 ; lift
G92 A0 B0 ; zero extruders
M73 P1 ;@body (notify GPX body has started)
; **** end of start.gcode ****

What am I missing here? Never have had an issues going from open box to printing with my FF/MicroCenter/PowerSpec printers but apparently this MKS SBASE requires a bit more configuration. Any help would be TRULY greatful!!!

[wolfmanjm]

i suggest you contact MKS for support of their product. it is not open source, and therefore unsupportable by the open source community.

[Arthur Wolf]

http://smoothieware.org/troubleshooting#somebody-refused-to-help-me-because-my-board-is-a-mks-what-s-that-all-about

--

You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.