Sailfish causes "shuddering and jerking" even with small "max speed change" value

[caall99]

http://3dprintboard.com/showthread.php?15326-Qidi-Tech-1-Replicator-2-clone&p=94492&viewfull=1#post94492

Please refer to the link above, and read through a few pages of posts. I have been suffering from jerking and shuddering problems with my printer regardless of the slicer I am using. Others with the Qidi Tech 7.8 Sailfish firmware have experienced the same problems. There seems to be an issue with Qidi Tech 7.8 Sailfish firmware, or perhaps all Sailfish versions, that limits the firmware's ability to apply acceleration to small moves, such as small features and loops. It seems that acceleration is ignored and that the tool head jerks through all the movements resulting in skipped steps and ruined prints.

I have my "max speed change" setting at 7, vs. the default 15, and am still suffering from this problem. I would really enjoy the opportunity to discuss this problem in more detail... and if it is in fact a limitation of Sailfish, then perhaps I can share enough information for you to remedy it.

It is possible that the Qidi Tech 7.8 firmware is complete trash and based on an old version of Sailfish, but I am unsure of how to update my Qidi Tech MightyBoard controller (with Atmega2560) to an official Sailfish release. Qidi Tech says it cannot be done, under any circumstance.

Thanks! Chris

[dnewman-polar3d]

On 30/08/2016 6:56 PM, caall99 wrote:

Finally! Success! I reverted back to my first snapshot, before the updates, and for some reason its working now. I can't determine which update fixed it, or whether several reboots were necessary before it worked... anyway, I was able to build my firmware, load it into my bot, and am waiting for my torture test to start printing as I type this. Maybe the SD card pipeline commit by dbavatar helped. Even if it didn't solve my problem, I still got bed and extruder heating at the same time, such a relief!

Congrats. And you can be the first tester other than dbavatar for this. Me, I've been busy getting some L6470 drivers working. (They are incredibly quiet. Loudest thing is the extruder cooling fan.)

[caall99]

Holy cr*p... this feels like a completely different machine! Almost as if it can finally breathe, after suffocating before! It races between segments now in an unhindered fashion, and navigates small circles much more smoothly! So far print quality is looking very good as well.

The printer sounds smoother, and is less noisy...

Settings: Acceleration = 750 mm/s^2 Max speed change = 4mm/s Max speed = 60 mm/s

Print is still underway, and the print head hasn't yet reached the cylinders. The cylinders will ultimately show me whether or not my issue was lack of moves in the pipeline due to single move SD card reads...

[caall99]

Another obvious effect is the gradual slowing of the print when (I assume) the processor is falling behind in motion planning due to too many incoming segments. This was not noticeable before. Instead before I noticed hammering and what I assume was choking - none of the gradual slowing I am seeing now. Stepper motors sing a pleasant hum now, vs. the "whacking" and "rumble" noises from before. Seems dbavatar's optimizations in that regard were very effective!

I am noticing the slowing effect in both in small perimeters and infill filling. A single surface of infill will have some faster and some slower regions, as will the perimeter of a small hole (especially the hex head hole on the torture test - very noticeable slowing).

[dcnewman]

Print is still underway, and the print head hasn't yet reached the cylinders. The cylinders will ultimately show me whether or not my issue was lack of moves in the pipeline due to single move SD card reads...

SD card is read 512 bytes at a time at 1 MHz. USB to the typical AVR-based printer is one quarter the speed at best (250000 baud). The SD card is typically not a bottleneck. (If you're worried about it being one, then go to RepRapFirmware on Duet: DMA over the high speed parallel SD card interface. Easily in the 40 Mbs range. RepRapFirmware on RADDS uses DMA over serial SPI so nowhere near as fast but still much faster than on an AVR.)

[dnewman-polar3d]

On 30/08/2016 7:10 PM, caall99 wrote:

Holy cr*p... this feels like a completely different machine! Almost as if it can finally breathe, after suffocating before! It races between segments now in an unhindered fashion, and navigates small circles much more smoothly! So far print quality is looking very good as well.

Thanks for the report. Hopefully I can look at this next week myself.

Dan

[caall99]

I meant what he (dbavatar) said:

Pipeline sdcard reads

Sdcard reads are very inefficient, although we fill the command buffer, we only read a single move command at a time. When printing with high detail this is often not fast enough to keep the move command ring full, which results in planner badness in addition to slowing down the print. So, if we encounter a stream of move commands, pipeline those reads into the planner. Additionally, if we still haven't filled the buffer blocks, read more from the sdcard, and continue doing so until we do. This effectively prioritizes reading of sdcard data during prints over everything else, except interrupts of course. If a very long area of high detail is encountered, we can be in that loop for a long time, since st_interrupt basically 100% cpu and is draining the block buffer continuously. Therefore we break out after we've done a bunch of work so that the menu and other slices are still responsive.

:)

Also, it seems like at the same acceleration setting of 750 mm/s^2 (as I had with v7.7 r1432), this new commit from dbavatar appears quicker, as if it exhibited higher acceleration than I requested. But only marginally so. Maybe a symptom of the firmware finally being able to "breathe"?

[dnewman-polar3d]

On 30/08/2016 7:33 PM, caall99 wrote:

I meant what he (dbavatar) said:

Pipeline sdcard reads

Sdcard reads are very inefficient, although we fill the command buffer, we only read a single move command at a time. When printing with high detail this is often not fast enough to keep the move command ring full, which results in planner badness in addition to slowing down the print. So, if we encounter a stream of move commands, pipeline those reads into the planner. Additionally, if we still haven't filled the buffer blocks, read more from the sdcard, and continue doing so until we do. This effectively prioritizes reading of sdcard data during prints over everything else, except interrupts of course. If a very long area of high detail is encountered, we can be in that loop for a long time, since st_interrupt basically 100% cpu and is draining the block buffer continuously. Therefore we break out after we've done a bunch of work so that the menu and other slices are still responsive.

:)

Nothing wrong with what he wrote. But what's your alternative to SD? USB is even less efficient and still commands are processed in the same fashion. And USB has to use an interrupt so it competes with the stepper interrupt for processor cycles making matters worse.

And an underlying issue is the lack of available RAM for I/O and command buffers. If you start running all the different menus and do a small print, you'll find that at some points the printer had only about 150 bytes free of RAM. (Utilties > Version Info will show the high water mark for available RAM. The system literally soils itself and goes crazy if it ever runs out of RAM while running. It starts scribbling on its stack and corrupting data in RAM.) Net, net, lots of things which could improve I/O a tad, we just cannot do. From time to time Jake Bordens and I would go through doing things to free up 10 bytes here and 20 bytes there of RAM. But then it would get used up for something new.

Dan

[caall99]

Perhaps last update for tonight:

I raised the acceleration from 750 mm/s^2 to 1000 mm/s^2 for another torture test print, which is considered default value for my replicator 1 dual setup. I also reduced the max_speed_change value from 4 mm/s to 3mm/s. These were only changes I made.

I changed the acceleration to the higher default value because I started seeing improper nozzle pressure effects at the beginning and end of segments, as if the JKN values were out of tune. I assume that JKN values need to be tuned for every acceleration value you set. At least this is what I have been experiencing... At a low acceleration like 300 to 500 mm/s^2 I would see much more plastic extruded at the beginning and end of every segment. At 1000 mm/s^2 it almost looks perfectly even with the default JKN values (k = 0.005 and k2 = 0.055).

Results:

The printer is slowing down less, and this is most pronounced when printing the perimeters of the hexagonal hole. Before there would be a dramatic slow on the first perimeter printed, but now there isn't any noticeable slowing.

[caall99]

Correction, slowing is still apparent... its just random when a slowing effect is triggered on the hexagonal hole.

50 mm/s print speed still seems fast. Reducing to 46.66 mm/s, and may try the slow for small loops *.exe for S3D.

Strangely enough cancelling a print doesn't bring the platform back to the bottom. Is there a specific advanced option I have to include in the build?

Dan, regarding your memory comment, I do have an Atmega2560. I guess the Atmega1280 and 2560 only differentiate in Flash size (128kb vs. 256kb), not EEPROM or SRAM, so perhaps that's a moot point. Would it benefit to install less features (advanced options) when building the firmware to maximize available ram? Or is "saving valuable RAM" much deeper rooted in core functionality?

[dbavatar]

On Tue, Aug 30, 2016 at 11:29 PM, caall99 notifications@github.com wrote:

Dan, regarding your memory comment, I do have an Atmega2560. I guess the Atmega1280 and 2560 only differentiate in Flash size (128kb vs. 256kb), not EEPROM or SRAM, so perhaps that's a moot point. Would it benefit to install less features (advanced options) when building the firmware to maximize available ram? Or is "saving valuable RAM" much deeper rooted in core functionality?

The design of the block ring means that it can only be doubled at the moment, and the machine is a long way off from that. I have some changes stowed away to shrink each block element, but not nearly enough to make a difference (yet). Also, at the moment you would also get O(n^2) behavior from the planner, and I'm not sure the CPU can keep up with that. Basically if there is a new super efficient planning strategy, maybe the size can be increased. Regardless, I don't think it's actually necessary. I believe the right thing to do is for the planner to drop into unaccelerated as soon as it gets a ton of tiny segments, that in itself saves a huge amount of cpu and everything will go faster, plus the print quality should be better than a set of tiny trapezoids.

[dbavatar]

On Tue, Aug 30, 2016 at 10:10 PM, caall99 notifications@github.com wrote:

Holy cr*p... this feels like a completely different machine! Almost as if it can finally breathe, after suffocating before! It races between segments now in an unhindered fashion, and navigates small circles much more smoothly! So far print quality is looking very good as well.

The printer sounds smoother, and is less noisy...

Good to hear. I know a bunch of scenarios where things will still go wrong, hope to address them someday. I've been printing off this branch at a target speed of 150mm/s since shortly before I pushed it.

[caall99]

Turning acceleration off when many small segments are upcoming sounds efficient. The firmware could revert to some low print speed value corresponding to what one would input into the "slow down for small loops" post processing executable recommended on the S3D forums.

I would love to hear what printer setup, acceleration and max speed change you are printing with. Mine is setup as a dual bowden, and above 46.6 mm/s or so print speed it makes small details suffer tremendously. I cannot imagine 150 mm/s at my acceleration of 1000 mm/s^2...

[dnewman-polar3d]

On 30/08/2016 8:29 PM, caall99 wrote:

Correction, slowing is still apparent... its just random when a slowing effect is triggered on the hexagonal hole.

3000 mm/s print speed still seems fast. Reducing to 2800 mm/s, and may try the slow for small loops *.exe for S3D.

Strangely enough cancelling a print doesn't bring the platform back to the bottom. Is there a specific advanced option I have to include in the build?

If you cancel before the present position is well defined, then no platform clearing can occur since the position isn't yet defined. And in 7.8 the platform only moves down at most 5 mm. Everyone was getting tired of waiting for it to move further.

Would it benefit to install less features (advanced options) when building the firmware to maximize available ram? Or is "saving valuable RAM" much deeper rooted in core functionality?

Depends upon what feature you drop. Some don't use any RAM worth mentioning. Some may use a bit.

Dan

[dnewman-polar3d]

On 30/08/2016 8:50 PM, dbavatar wrote:

On Tue, Aug 30, 2016 at 11:29 PM, caall99 notifications@github.com wrote:

Dan, regarding your memory comment, I do have an Atmega2560. I guess the Atmega1280 and 2560 only differentiate in Flash size (128kb vs. 256kb), not EEPROM or SRAM, so perhaps that's a moot point. Would it benefit to install less features (advanced options) when building the firmware to maximize available ram? Or is "saving valuable RAM" much deeper rooted in core functionality?

The design of the block ring means that it can only be doubled at the moment, and the machine is a long way off from that. I have some changes stowed away to shrink each block element,

Doubling the block ring doesn't help much. Back a couple of years ago, Jake Bordens added external RAM to the AVR and played around with doubling and quadrupling and then monitoring for different prints how often the buffer got to only 2 queued segments. Didn't make much difference -- the problem wasn't the depth available.

Basically if there is a new super efficient planning strategy, I actually have one. Just haven't had time to update the firmware. Namely do all the planning in GPX (implemented). There you can express the problem as a linear programming problem and solve it. Handles a critical issue whereby the initial planner (plan_buffer_line) cannot properly fix junction speeds. At present, it knows the exit speed of the prior segment and can use that to adjust the entrance speed of the new segment. But it cannot adjust the exit speed of the prior segment -- it's already queued and may be printing. Obviously, adjusting both is desireable. It works pretty well, at least in the simulator. And you do not need to solve over the entire print (although I have done it for a 1GB in size gcode file). Solving piecewise in small chunks works as well. But, I just haven't had time to add it to the firmware: to increase the X3G packet size and then process the packet, throwing it directly into the queue of planned blocks.

Dan

[dbavatar]

On Wed, Aug 31, 2016 at 12:09 AM, caall99 notifications@github.com wrote:

Turning acceleration off when many small segments are upcoming sounds efficient. The firmware could revert to some low print speed value corresponding to what one would input into the "slow down for small loops" post processing executable recommended on the S3D forums.

It should be automatic and derived from the user settable settings. Also the right algorithm will not slow down for features, it will calculate the max speed allowed by physics, while obeying user settings. The slow down on remaining ring size is a dirty hack, and doesn't always work. Some of the ringing you see in prints should also go away when the right decel is done at every segment.

I would love to hear what printer setup, acceleration and max speed change you are printing with. Mine is setup as a dual bowden, and above 2800 mm/s or so print speed it makes small details suffer tremendously. I cannot imagine 9000 mm/s at my acceleration...

Flashforge creator pro 2016, microswiss all metal hotends, ball bearing spool holders, dual fan ducts, modified drive assembly/gears to support flex filaments. XY Accel is 1300/900 and XY max speed is 20/15. I ran accel at 2500 for a while, it didn't do too much for speed but it did create a lot of vibration. Of course, I'm only printing parts that came out of solid modeling, no yoda heads. 1000 is actually already quite fast.

[dcnewman]

I actually have one. Just haven't had time to update the firmware. Namely do all the planning in GPX (implemented). There you can express the problem as a linear programming problem and solve it. Handles a critical issue

Also, makes it easier to experiment with other planning algorithms. Also, what I have in GPX was generating slightly faster prints on top of avoiding all the kinematic constraint violations you often get. Initial planner mostly honors them with the exception of cases where you need to backfix the prior segment and cannot. But the iterative planners turn around and violate the constraints pretty regularly. Part of the issue being insufficient memory to properly store all the information about the motion. You end up with the iterative planner not even knowing the direction. (At least in Grbl and Marlin it doesn't so it happily does bad things at junctions where there's a direction reversal. In Sailfish we tried to address that a little but still if you run the simulator you'll see bad things happening.)

Dan

[dbavatar]

On Wed, Aug 31, 2016 at 1:23 AM, dnewman-polar3d notifications@github.com wrote:

Doubling the block ring doesn't help much. Back a couple of years ago, Jake Bordens added external RAM to the AVR and played around with doubling and quadrupling and then monitoring for different prints how often the buffer got to only 2 queued segments. Didn't make much difference -- the problem wasn't the depth available.

If you can double the size, then you could have a read and write pointers so that you pre-plan in the ring without st_interrupt() executing blocks, which clearly gets in the way of modifying multiple blocks. Actually maybe that can still be done, but 16 is very small.

I actually have one. Just haven't had time to update the firmware. Namely do all the planning in GPX (implemented). There you can express the problem as a linear programming problem and solve it. Handles a critical issue whereby the initial planner (plan_buffer_line) cannot properly fix junction speeds.

Pre-planning everything would be optimal. There is no reason the AVR needs to do anything more than read the SD and drive the steppers.

[caall99]

Both,

I have edited several prior comments. I made the mistake of listing my speeds in mm/s when the units were really mm/min. I have changed everything to mm/s for consistency. If you feel so inclined, perhaps you could change your quoting of my text to reflect the actual mm/s. This should help mitigate any confusion in the future when people read this thread.

Back to speeds and acceleration: I am printing at 46.6 mm/s, max_speed_change of 3 mm/s, and acceleration of 1000 mm/s^2. With these settings I feel the print head is still moving too quickly - and I am using a Bowden setup!!! I cannot even fathom how a dual direct drive extruder carriage can handle 150 mm/s with any accuracy, especially with the max speed change at 15 or 20 mm/s, and acceleration around 1000 mm/s^2. Small circles/holes turn into ovals with blobbing all over the place... I just don't understand how I am suffering print quality and motion planning at such low speeds (and reasonable acceleration), when you two experts are printing above 100 mm/s with the same acceleration - and I AM the one with the Bowden setup... lol.

Back to my other questions:

1. Are JKN values specific to an acceleration value? I.e. is the default k = 0.005 and k2 = 0.055 specific to the default 1000 mm/s^2 acceleration value for a replicator 1? It seems my k and k2 values need to changed to result in clean prints at higher and lower acceleration settings.
2. Is there any benefit in using both firmware deprime and slicer retraction? Does it become redundant to use both, or are they additive? I.e. do you end up retracting more with both than just with one?
3. dbavatar, if you would be so kind... could you try the aforementioned torture test with your settings and report on the quality of the print, specifically around small diameter holes and cylinders?
4. I understand why you would have different acceleration for the x and y axis, since we have to move 100% the weight on the y axis and 66% the weight on the x (roughly). I read somewhere that having different accelerations on the two axis can result in other issues. Is this not the case?
5. Looky here: https://github.com/garychen99/Duplicator-6-firmware-version-3.1 Apparently the Duplicator 6 firmware supports G2 and G3 (for arc movements), on the Atmega2560. Is this something Sailfish can support?

Thanks for being so responsive to my inquiries thus far. I hope my babbling is to some benefit to the both of you, and the community.

[dbavatar]

On Wed, Aug 31, 2016 at 9:27 AM, caall99 notifications@github.com wrote:

Back to speeds and acceleration: I am printing at 46.6 mm/s, max_speed_change of 3 mm/s, and acceleration of 1000 mm/s^2. With these settings I feel the print head is still moving too quickly - and I am using a Bowden setup!!! I cannot even fathom how harsh a dual direct drive extruder carriage can handle 150 mm/s with any accuracy, especially with the max speed change at 15 or 20 mm/s. Small circles/holes turn into ovals with blobbing all over the place... I just don't understand how I am suffering at such low speeds (and reasonable acceleration), when you two experts are printing above 100 mm/s with the same acceleration - and I AM the one with the Bowden setup... lol.

I would bet it's the model you are trying to print. This should have no problem with my settings: http://www.thingiverse.com/thing:1731049 However I guarantee that this will fail: http://www.thingiverse.com/thing:537918 Maybe for you it will have terrible quality, for me I will get steppers skipping, and that's the end of that print. The movement of the head does not correspond to any of these settings, there's a couple spots where it seem to try and wormhole jump between two points. I have not gotten to the bottom of this behavior.

dbavatar, if you would be so kind... could you try the aforementioned torture test with your settings and report on the quality of the print, specifically around small diameter holes and cylinders?

Not spotting the link to the torture test above, please pm me the link and I will try it.

I understand why you would have different acceleration for the x and y axis, since we have to move 2/3 the weight on the y axis and 1/3 the weight on the x (roughly). I read somewhere that having different accelerations on the two axis can result in other issues. Is this not the case?

Because of mass, yes. Although the printer only chooses the major axis acceleration for any move, it does not currently interpolate. I don't see how it would cause problems, other than neither value does what you expected intuitively.

[caall99]

Aww, that fan duct model was going to be my next print! The stock part fan on my printer is trash and it needs replacing... Do you suggest another fan duct, or simply printing that one at very low speeds?

It's really too bad we can't dial in speed, max speed change, and acceleration to work with all prints. This iterative printing, changing settings and printing again is hugely wasteful. I have spent 2 kgs of filament doing only that...

This is the torture test I was referencing: http://www.thingiverse.com/thing:33902

Any comments on my other questions, or should those be reserved for Dan?

[dnewman-polar3d]

It's really too bad we can't dial in speed, max speed change, and acceleration to work with all prints. This iterative printing, changing settings and printing again is hugely wasteful. I have spent 2 kgs of filament doing only that...

I never change any of the firmware parameters unless I'm testing the firmware itself. On my day to day printers I print all sorts of things and I never, ever change firmware parameters. I use S3D for my normal slicer. Print to print variations, I address in the slicer. I mean, after all, the max accelerations and acceptable speed changes are really mechanical properties of the printer and not things which change from model to model. So once you have things dialed in for the printer mechanics, there should be no need to change those firmware settings.

The only exception is lousy mechanics for which there's too much vibration. E.g., the Replicator 1 with 8mm Z rods and that bouncy cantilevered build platform. There people do sometimes want to trade off speed for quality and will change their max speed changes from high values (fast, draft) to low values (fine, quality). RepG even had a button for doing that change for you to the firmware settings. However, a better long term solution is to have a more rigid, less vibration prone printer. The RepG was most definitely not that.

Dan

[caall99]

Dan,

Not quite what I what was getting at. Are you saying that Sailifish cannot print the fan duct you linked, regardless of parameter changes? Or can you successfully print it at lower speeds and/or acceleration, by changing your parameters?

[dnewman-polar3d]

On 31/08/2016 10:27 AM, caall99 wrote:

Dan,

Not quite what I what was getting at. Are you saying that Sailifish cannot print the fan duct you linked, regardless of parameter changes? Or can you successfully print it at lower speeds and/or acceleration, by changing your parameters?

Fan duct I linked? I don't recall pointing anyone at a fan duct recently? I know I've pointed people at a Bukito fan duct, but it's trivial to print.

Dan

[caall99]

http://www.thingiverse.com/thing:537918, sorry, you didn't link it. dbavatar linked it.

[dbavatar]

On Wed, Aug 31, 2016 at 12:46 PM, caall99 notifications@github.com wrote:

Do you suggest another fan duct, or simply printing that one at very low speeds?

http://www.thingiverse.com/thing:1597507

This is the torture test I was referencing: http://www.thingiverse.com/thing:33902

Yeah, that's not going to work well. 1.5MB stl for a 2" model. It's full of segments. The printer is choking on segments. I'm far enough into the print that I think it will finish, but it will be ugly. That's the kind of thing I have in mind to work after a bunch of planner changes. BTW, those circles almost work for me at ~70mm/s, not at ~130mm/s. I'm also compiled with -O2 instead of -Os, so my printer is probably slightly faster.

[caall99]

Thanks for linking that! I was looking for something i could use with my stock blower fan setup on my qidi tech. This might just bolt into place without any rework!

What is O2 vs Os?

[dbavatar]

On Wed, Aug 31, 2016 at 7:49 PM, caall99 notifications@github.com wrote:

Thanks for linking that! I was looking for something i could use with my stock blower fan setup on my qidi tech. This might just bolt into place without any rework!

What is O2 vs Os?

Sailfish is compiled as optimized for size instead of pure speed. This may be a problem on the smaller cpu's but I have a 2560, works just fine.

[caall99]

In what part of the building process would i add that command? I too have an atmega 2560. Thanks

[caall99]

By using -O2 (please let me know how!) would an Atmega2560 printer be able to process and plan motion quicker than a Atmega1280 printer, even though the only difference between the processors is flash size? Shouldn't that optimization for speed on a larger flash size processor be built into the respective firmware build? For example mighty_one vs. mighty_one-2560?

[dcnewman]

On 01/09/2016 7:09 AM, caall99 wrote:

By using -O2 (please let me know how!) would an Atmega2560 printer be able to process and plan motion quicker than a Atmega1280 printer,

There's a gotcha to changing the optimization level. Jetty and I carefully went through the interrupt and timed everything and arranged the code to get the fastest times with the optimization level which we then used. If you change the optimization level, things can change adversely.

Similar example is when the Marlin folks two summers back went from Arduino 1.0.x to 1.5.8beta. That got them new version of the gcc toolchain. They then had some odd issues in the stepper interrupt which took them a fair amount of time to diagnose and address. The cause was the compiler optimizing the stepper interrupt code differently, using different register assignments, etc. I believe the initial symptom they were seeing was intermittent bad timing of interrupt delivery. Was a late or early issue caused by the interrupt code occassionally taking too long to run.

Moral of the story is that if you do change the optimization level, you do need to carefully watch for unwanted side effects.

Dan

[dnewman-polar3d]

On 01/09/2016 7:54 AM, Dan Newman wrote:

On 01/09/2016 7:09 AM, caall99 wrote:

By using -O2 (please let me know how!) would an Atmega2560 printer be able to process and plan motion quicker than a Atmega1280 printer,

So the answer to your question is that there's little chance that for 2560s we're changing the optimization level. Last thing we want is to lose two months to figuring out why some new squirrely behavior arises on printers with 2560s.

Dan

[caall99]

Thank you for the clarification. I am in this to experiment and learn, and hopefully contribute in the long run. With that said, I am agreeable to "being careful and watching for side effects"! I'll even post here and let you know what happens! :)

May I now know how to do it? lol

[dcnewman]

May I now know how to do it? lol

Sorry, I'm not where I can look at sources. But it'll be in the file firmware/src/SConscript.mightyboard

[caall99]

I found -Os but no mention of -O2.

[caall99]

Wow... this took a while to find...

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Do I append the scons argument with -O2 or do I actually change the -Os in firmware/src/SConscript.mightyboard to -O2 before building?

Thanks

[dcnewman]

On 01/09/2016 9:05 AM, caall99 wrote:

I found -Os but no mention of -O2.

Change -Os to -O2

[caall99]

Thanks for confirming my suspicion. Please remember all of this is VERY new to me. I didn't even know what Google search terms to include when I was looking for -Os vs. O2. Didn't even realize it was related to the tool chain! I am sure you can see how this could trip me up.

I plan to add it under "flags" in that file, and to these lines:

320 env.Append(BUILDERS={'Elf':Builder(action=avr_tools_path+"/avr-gcc -mmcu="+mcu+" -Os -Wl,--gc-sections -Wl,-Map,"+map_name+" -o $TARGET $SOURCES -lm")}) 321 env.Append(BUILDERS={'Hex':Builder(action=avr_tools_path+"/avr-objcopy -O ihex -R .eeprom $SOURCES $TARGET")})

I assume add to both lines since I am compiling a .hex and not .elf (or w/e that is?)

[dnewman-polar3d]

On 01/09/2016 9:51 AM, caall99 wrote:

Thanks for confirming my suspicion. Please remember all of this is VERY new to me. I didn't even know what Google search terms to include when I was looking for -Os vs. O2. Didn't even realize it was related to the tool chain! I am sure you can see how this could trip me up.

I plan to add it under "flags" in that file, and to these lines:

320 env.Append(BUILDERS={'Elf':Builder(action=avr_tools_path+"/avr-gcc -mmcu="+mcu+" -Os -Wl,--gc-sections -Wl,-Map,"+map_name+" -o $TARGET $SOURCES -lm")}) 321 env.Append(BUILDERS={'Hex':Builder(action=avr_tools_path+"/avr-objcopy -O ihex -R .eeprom $SOURCES $TARGET")})

I assume add to both lines since I am compiling a .hex and not .elf (or w/e that is?)

Just the first line. You're compiling an .elf file than converting that file to an ASCII .hex file.

Dan

[caall99]

I tried -o2 and it resulted in a blank screen on printer power cycle

[caall99]

May have been due to the fact that i flashed/built as binary vs ASCII. For some reason i recall being prompted to make a choice.

[caall99]

Hey guys! Hope you all had a great weekend, and if you are in the USA: A great Holiday weekend! I had some time last night to play with my 3D printer and the Sailfish firmware. I went ahead and reset my VM to rebuild the firmware. (Note: I have the Qidi Tech variant of the Mightyboard Rev E, which is missing some features relative to the Flashforge and Makerbot version. See here: http://3dprintboard.com/showthread.php?15326-Qidi-Tech-1-Replicator-2-clone&p=94573&viewfull=1#post94573

dbavatar, I used your "pipeline SD card reads" commit to build my version of the firmware (found here: https://github.com/dbavatar/Sailfish-MightyBoardFirmware/commit/9b746bac6b2a85f2f9f5b4cef2a26a6c09b70dbb)

I setup the mighty_one-2560 firmware with the following features: BUILD_STATS HEATERS_ON_STEROIDS PSTOP_ZMIN_LEVEL PLATFORM_SPLASH1_MSG=\"Sailfish Replicator1\" PLATFORM_THE_REPLICATOR_STR=\"Replicator 1\" EEPROM_MENU_ENABLE

Note: I removed anything to do with auto-level, RGB LEDs, and alternate UART.

I also built with –O2 optimization vs. the default –Os optimization. I have to say, everything is operating a lot smoother. Menu is more responsive, steppers are quieter, and the “choking on segments” happens less frequently now. I also decimate all my prints with 0.5mm segment length (in S3D) prior to slicing.

Small perimeters are still being printed a bit too quickly for my taste (at 3 mm/s max_speed_change). I think i need to use the "slow down for small loops" application.

I still get some blobbing issues that may be related to insufficient retraction or lack of coasting. I have also changed my Bowden PTFE tube to a larger ID, as the snug ID of my last one was causing too much friction (overheating and skipping extruder stepper motor). My print speed is 40 mm/s, which equals a theoretical plastic flow rate of 4.11 mm/s^3. I plan to upgrade the extruder stepper as I believe the stock Qidi extruder steppers are insufficient for a Bowden setup. My VREF is at 100 for the extruders, and they are getting very uncomfortably hot. I cannot provide more current to these little steppers without causing thermal shutdown or skipping. FYI, my filament is definitely not grinding or slipping.

[caall99]

Hey again,

I know its not a support forum, but I am wondering if I am totally exceeding the mechanical limits of my printer and the computing limits of the Atmega when running Sailfish. I understand Marlin had a bug where retraction speeds in excess of 48mm/s were being ignored. I believe this has been fixed. Did the issue exist in Sailfish, if so has it also been remedied?

I am currently retracting at 100 mm/s and 7000mm/s^2. Is this too fast and quick? I am getting very inconsistent extrusion amounts in the hollow pyramid calibration test: http://www.thingiverse.com/thing:11846.

Some layers are being over extruded while others appear fine. Seems very random... I am printing islands sequentially (in S3D), very slowly, and have plenty part cooling. I cannot figure out what may be amiss here...

I am thinking maybe I am asking too much of the extruder stepper during retraction with my aforementioned settings? Skipping steps perhaps? Any thoughts?

Thanks!

[markwal]

There is a Google Group here: https://groups.google.com/forum/#!forum/jetty-firmware

But this question would also work on this group: https://groups.google.com/forum/#!forum/3dprintertipstricksreviews

[dnewman-polar3d]

On 08/09/2016 8:19 AM, caall99 wrote:

Hey again,

I know its not a support forum, but I am wondering if I am totally exceeding the mechanical limits of my printer and the computing limits of the Atmega when running Sailfish. I understand Marlin had a bug where retraction speeds in excess of 48mm/s were being ignored.

We fixed that back in 2011. I alerted Erik van der Zalm to it and other bugs. He fixed most of them, but missed that nuance of that bug and so it remained in Marlin until .... I forget his handle ... found it several years later.

I am currently retracting at 100 mm/s and 7000mm/s^2. Is this too fast and quick?

It's your hardware. Only you can tell.

I am thinking maybe I am asking too much of the extruder stepper during retraction with my aforementioned settings? Skipping steps perhaps? Any thoughts?

Anything is possible. And yes, people would be amazed if they knew just how often their extruders skip steps. That's been a big lesson from the Mosaic Palette: for it to work well, your extruder must not skip steps, even occasionally. And the early testers & adopters are discovering, to their surprise, that what they thought was a rock solid extruder actually skips steps. And with a Bowden tube, there can be significant tuning issues in the area of recovery from retraction.

Dan

[dnewman-polar3d]

On 08/09/2016 9:04 AM, dnewman-polar3d wrote:

On 08/09/2016 8:19 AM, caall99 wrote:

Hey again,

I know its not a support forum, but I am wondering if I am totally exceeding the mechanical limits of my printer and the computing limits of the Atmega when running Sailfish. I understand Marlin had a bug where retraction speeds in excess of 48mm/s were being ignored.

We fixed that back in 2011. I alerted Erik van der Zalm to it and other bugs. He fixed most of them, but missed that nuance of that bug and so it remained in Marlin until .... I forget his handle ... found it several years later. Illuminarti I believe was who rediscovered and fixed it in Marlin.

Dan

[caall99]

Thanks! Wish it was easy to judge whether or not I am skipping steps... What are your max_speed_change, acceleration, and speed for retractions? I just want to know if I am in the right ballpark.

Also, what is PSTOP_ZMIN_LEVEL?

[dnewman-polar3d]

On 08/09/2016 9:27 AM, caall99 wrote:

Thanks! Wish it was easy to judge whether or not I am skipping steps... What are your max_speed_change, acceleration, and speed for retractions? I just want to know if I am in the right ballpark.

I don't use a Bowden. And I use the Sailfish defaults. Also, what is PSTOP_ZMIN_LEVEL?

For ZYYX printers and other printers with auto-leveling. How many false triggers of the Z probe to allow before triggering a Pause Stop. Theory being that if your print breaks loose or goes wonky certain ways, the probe switch will start getting trigggered often and maybe you want to pase the print at that point and ask for operator intervention.

Dan

[dbavatar]

On Thu, Sep 8, 2016 at 11:19 AM, caall99 notifications@github.com wrote:

Hey again,

I know its not a support forum, but I am wondering if I am totally exceeding the mechanical limits of my printer and the computing limits of the Atmega when running Sailfish. I understand Marlin had a bug where retraction speeds in excess of 48mm/s were being ignored. I believe this has been fixed. Did the issue exist in Sailfish, if so has it also been remedied?

I am currently retracting at 100 mm/s and 7000mm/s^2. Is this too fast and quick? I am getting very inconsistent extrusion amounts in the hollow pyramid calibration test: http://www.thingiverse.com/thing:11846.

Each segment is a 5 dimensional vector that is executed simultaneously, XYZ and extruder AB. So having such a large value will do nothing except when your dominant axis becomes the extruder axis, then they will take on a crazy value. If your XY axis is dominant for a segment, then it's acceleration will be used for all axes, etc.

IMHO the mechanics of bowden are undesirable especially when not using 3mm filament. You're cranking those values to try and take up compression and stretch in the filament, which may not even be possible depending on what the slicer has done. There's much progress to be made managing the existing kinetic energy in software before moving to bowdens.

[caall99]

Thanks for the explanation Dan. I will omit that feature in my rebuild of the firmware.

dbavatar, wouldn't the extruder axis be the dominant one in any retraction? If so, would the elevated 7000 mm/s^2 vs. the default 2000 mm/s^2 value for extruder acceleration effect how quickly plastic is pushed and pulled in all retractions? I am still using the stock extruder block and stepper motor, but have relocated them outside the printer.

I am not sure if S3D is doing anything that could upset maximum speed of a retraction. Should I disable S3D retraction and use the Sailfish firmware deprime function instead? I currently have all deprime functionality disabled and am only using retraction in S3D.

[dbavatar]

On Thu, Sep 8, 2016 at 1:10 PM, caall99 notifications@github.com wrote:

Thanks for the explanation Dan. I will omit that feature in my rebuild of the firmware.

dbavatar, wouldn't the extruder axis be the dominant one in any retraction? If so, would the elevated 7000 mm/s^2 vs. the default 2000 mm/s^2 value for extruder acceleration effect how quickly plastic is pushed and pulled in all retractions? I am still using the stock extruder block and stepper motor, but have relocated them outside the printer.

I am not sure if S3D is doing anything that could upset maximum speed of a retraction. Should I disable S3D retraction and use the Sailfish firmware deprime function instead? I currently have all deprime functionality disabled and am only using retraction in S3D.

The answer is "it depends". You can look at the gcode file S3D output with the x3g and then calculate how long the vectors are between 2 points by hand, the retractions shouldn't be hard to find in there. Gut feelimg is 100mm/s is too high for the extruder to handle. You'll get skipped steps maybe only in one direction, producing a blob when it's unretracted.