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

[dcnewman]

I have no idea how the QiDi folks are building Sailfish. My first guess would be that they are not following the requirement to use the avr-gcc 4.6.2 or 4.6.3 toolchains. If they are using some other version of gcc, then all bets are off. In developing Sailfish we hit issues in the avr-gcc C run-time libraries with 4.5 and were told by the avr-gcc devs to use 4.6. Later, when we tried moving to 4.7 we again encountered issues -- issues which would exhibit in the motion control. However, they weren't bugs but rather differences in how the compiler optimized code in the timing-critical motion control code, the stepper interrupt code. I do not know if that is the problem you're seeing, but it's the first thing which comes to mind; that QiDi is doing builds with some joe-random version of the avr-gcc toolchain instead of 4.6.2 or 4.6.3.

FWIW, two summers ago, when the Marlin devs moved off of avr-gcc 4.3.3, and moved to the newer toolchain in Arduino 1.5 and later (4.8.8), they had nearly the same problem and they had to restructure some of their stepper interrupt code. Again, because compiler optimizations were causing changes in the stepper interrupt code timing which then impacts behavior (can cause interrupts to deliver late, etc.).

At any rate this isn't a Sailfish issue per-se: works just fine on MakerBots, FlashForge's, WanHao's, CTCs, MBot3D's, ZYYXs (and perhaps others). QiDi needs to build it with 4.6.2 or 4.6.3. I have two VMs in drop box which are all set up for building Sailfish with 4.6.2. They are linked to from here.

[caall99]

This is mostly above my head! But I do appreciate the response. Since I am not a Linux user, nor a software guy (lots of respect to people like you!), could I simply do the following:

1. Use a USBasp programmer to erase the both the Atmega2560 (and Atmega8u2?) chips - thereby resetting all the fuse and lock bits.
2. Set the fuse bits and lock bits to what's needed for replicatorG to update the firmware... no idea what they should be. Do you know?
3. Load the MightyBoard 2560 bootloader here: https://github.com/dcnewman/MightyBoardFirmware-2560-bootloader
4. Connect with ReplicatorG (sailfish variant) and update the firmware to your latest?

Could that solve my problem? Qidi will not help me with any of this... they obviously do not want us to circumvent their trashed firmware.

Thanks!

[dcnewman]

On 28/07/2016 2:24 PM, caall99 wrote:

This is mostly above my head! But I do appreciate the response. Since I am not a Linux user, nor a software guy (lots of respect to people like you!), could I simply do the following:

1. Use a USBasp programmer to erase the both the Atmega2560 (and Atmega8u2?) chips - thereby resetting all the fuse and lock bits.
2. Set the fuse bits and lock bits to what's needed for replicatorG to update the firmware... no idea what they should be. Do you know?
3. Load the MightyBoard 2560 bootloader here: https://github.com/dcnewman/MightyBoardFirmware-2560-bootloader
4. Connect with ReplicatorG (sailfish variant) and update the firmware to your latest?

Could that solve my problem? Qidi will not help me with any of this... they obviously do not want us to circumvent their trashed firmware.

I simply have no idea. I do not have access to a QiDi nor the motherboard they use. I have heard stories of people bricking their printers when putting "official" Sailfish on them which suggests that the QiDi people have either done something to defeat people updating firmware OR they simply did something wrong. I do not know which. I do know that around 1.5 years ago, Jetguy hepled Uncle Chuck (unclechucks3dprinterstuff.com) unbrick a board a user had bricked. I do not recall if Jetguy got Sailfish on the board or not. You'd have to ping jetguy. Jetguy posts frequently in the google wanhao users group as well is 3dprintertipstricksreviews. (And many other groups.)

Dan

[caall99]

Hi Dan,

Thanks for the connection! Let's keep the discussion active with JetGuy as well!

-Chris

On Thu, Jul 28, 2016 at 3:08 PM, Dan Newman notifications@github.com wrote:

On 28/07/2016 2:24 PM, caall99 wrote:

This is mostly above my head! But I do appreciate the response. Since I am not a Linux user, nor a software guy (lots of respect to people like you!), could I simply do the following:

1. Use a USBasp programmer to erase the both the Atmega2560 (and Atmega8u2?) chips - thereby resetting all the fuse and lock bits.
2. Set the fuse bits and lock bits to what's needed for replicatorG to update the firmware... no idea what they should be. Do you know?
3. Load the MightyBoard 2560 bootloader here: https://github.com/dcnewman/MightyBoardFirmware-2560-bootloader
4. Connect with ReplicatorG (sailfish variant) and update the firmware to your latest?

Could that solve my problem? Qidi will not help me with any of this... they obviously do not want us to circumvent their trashed firmware.

I simply have no idea. I do not have access to a QiDi nor the motherboard they use. I have heard stories of people bricking their printers when putting "official" Sailfish on them which suggests that the QiDi people have either done something to defeat people updating firmware OR they simply did something wrong. I do not know which. I do know that around 1.5 years ago, Jetguy hepled Uncle Chuck (unclechucks3dprinterstuff.com) unbrick a board a user had bricked. I do not recall if Jetguy got Sailfish on the board or not. You'd have to ping jetguy. Jetguy posts frequently in the google wanhao users group as well is 3dprintertipstricksreviews. (And many other groups.)

Dan

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jetty840/Sailfish-MightyBoardFirmware/issues/165#issuecomment-235994399, or mute the thread https://github.com/notifications/unsubscribe-auth/AQ4taOcUdHrtz6lMOm-bylUxS-QGqnWRks5qaP4fgaJpZM4JXbsY .

[markwal]

Speaking of Cura 2.1.x, I've noticed that the new CuraEngine does an interesting thing with narrow extrusions (gap fill & last extrusion on a sloping surface). It generates a bunch of small segments with many having really high expressed speeds. I reported a bug a while back that it was generating speeds like 400mm/s. The fix they selected was just to cap it at 150mm/s (not settable), which doesn't really change anything because the firmware was already capping the speed.

The behavior I get when executing these small linear segments at dramatically varying speeds is that the head jerks a lot. It doesn't matter whether I'm printing over USB or from SD card apparently. My guess is that the speed changes all fall within the jerk setting so they're aren't smoothed much by the planner, but to tell you the truth, I haven't experimented much with it, but it is often why I'll use Slic3r instead (though it has its own issues with gap filling).

The reason Cura is doing this is that it is trying to choose a speed such that the desired extrusion volume result in the same internal pressure in the nozzle. I'm not sure if the algorithm is correct, but that is the stated intention. Their motivation is for bowden extruders (like the Ultimaker) due to the lag in changing the extrusion volume. I was thinking a fix for my printer would be just to remove this (via a setting) and have it just set the desired extrusion volume and not try to break the segment into small explicitly set speed segments.

[dbavatar]

Yeah that's just not going to work well. I've been working on this problem, it's not an easy fix I'll tell you that. If you can reduce the speed of all small segments from your slicer, that would help. Lowering max speed change does not have the effect you would think it has when you lots of small segments. Setting it to 0 in you situation for example would get really bad results. Technically, I know how to make a build that would limit segments by minimum execution time, but this isn't great for overall print speed, and doesn't entirely solve the issue.

I don't know what a final solution will look like. I'm even looking at if pre-processing the file into a new format will solve the issues (p3g?), I got the idea from the simulator/sailtime components. The fundamental limitation is that the atmel cpu is shamefully slow, it doesn't have much power to do much else than service the stepper interrupts. For example, The final velocity computation seems to be so optimized that the results are way too inaccurate to be useful. Even if we had the cpu from the iPhone 1, things would be dramatically better.

If you build from current sailfish head, it will work slightly better, at least it will attempt to slowdown when the machine is choking on segments. You can look on my github too but it's a work in progress right now.

On Sat, Jul 30, 2016 at 6:01 PM, Mark Walker notifications@github.com wrote:

Speaking of Cura 2.1.x, I've noticed that the new CuraEngine does an interesting thing with narrow extrusions (gap fill & last extrusion on a sloping surface). It generates a bunch of small segments with many having really high expressed speeds. I reported a bug a while back that it was generating speeds like 400mm/s. The fix they selected was just to cap it at 150mm/s (not settable), which doesn't really change anything because the firmware was already capping the speed.

The behavior I get when executing these small linear segments at dramatically varying speeds is that the head jerks a lot. It doesn't matter whether I'm printing over USB or from SD card apparently. My guess is that the speed changes all fall within the jerk setting so they're aren't smoothed much by the planner, but to tell you the truth, I haven't experimented much with it, but it is often why I'll use Slic3r instead (though it has its own issues with gap filling).

The reason Cura is doing this is that it is trying to choose a speed such that the desired extrusion volume result in the same internal pressure in the nozzle. I'm not sure if the algorithm is correct, but that is the stated intention. Their motivation is for bowden extruders (like the Ultimaker) due to the lag in changing the extrusion volume. I was thinking a fix for my printer would be just to remove this (via a setting) and have it just set the desired extrusion volume and not try to break the segment into small explicitly set speed segments.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jetty840/Sailfish-MightyBoardFirmware/issues/165#issuecomment-236392236, or mute the thread https://github.com/notifications/unsubscribe-auth/ANZ_WGeVCTGAFEAgSItTigGYzMuI9EENks5qa8mfgaJpZM4JXbsY .

[caall99]

Hi Dan,

I can't figure out how to build the firmware with your VM. I loaded the VM that you prepackaged, but nothing is intuitive... i.e. I have no idea what to do now...

On Sat, Jul 30, 2016 at 6:47 PM, dbavatar notifications@github.com wrote:

Yeah that's just not going to work well. I've been working on this problem, it's not an easy fix I'll tell you that. If you can reduce the speed of all small segments from your slicer, that would help. Lowering max speed change does not have the effect you would think it has when you lots of small segments. Setting it to 0 in you situation for example would get really bad results. Technically, I know how to make a build that would limit segments by minimum execution time, but this isn't great for overall print speed, and doesn't entirely solve the issue.

I don't know what a final solution will look like. I'm even looking at if pre-processing the file into a new format will solve the issues (p3g?), I got the idea from the simulator/sailtime components. The fundamental limitation is that the atmel cpu is shamefully slow, it doesn't have much power to do much else than service the stepper interrupts. For example, The final velocity computation seems to be so optimized that the results are way too inaccurate to be useful. Even if we had the cpu from the iPhone 1, things would be dramatically better.

If you build from current sailfish head, it will work slightly better, at least it will attempt to slowdown when the machine is choking on segments. You can look on my github too but it's a work in progress right now.

On Sat, Jul 30, 2016 at 6:01 PM, Mark Walker notifications@github.com wrote:

Speaking of Cura 2.1.x, I've noticed that the new CuraEngine does an interesting thing with narrow extrusions (gap fill & last extrusion on a sloping surface). It generates a bunch of small segments with many having really high expressed speeds. I reported a bug a while back that it was generating speeds like 400mm/s. The fix they selected was just to cap it at 150mm/s (not settable), which doesn't really change anything because the firmware was already capping the speed.

The behavior I get when executing these small linear segments at dramatically varying speeds is that the head jerks a lot. It doesn't matter whether I'm printing over USB or from SD card apparently. My guess is that the speed changes all fall within the jerk setting so they're aren't smoothed much by the planner, but to tell you the truth, I haven't experimented much with it, but it is often why I'll use Slic3r instead (though it has its own issues with gap filling).

The reason Cura is doing this is that it is trying to choose a speed such that the desired extrusion volume result in the same internal pressure in the nozzle. I'm not sure if the algorithm is correct, but that is the stated intention. Their motivation is for bowden extruders (like the Ultimaker) due to the lag in changing the extrusion volume. I was thinking a fix for my printer would be just to remove this (via a setting) and have it just set the desired extrusion volume and not try to break the segment into small explicitly set speed segments.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jetty840/Sailfish-MightyBoardFirmware/ issues/165#issuecomment-236392236, or mute the thread https://github.com/notifications/unsubscribe-auth/ANZ_ WGeVCTGAFEAgSItTigGYzMuI9EENks5qa8mfgaJpZM4JXbsY

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jetty840/Sailfish-MightyBoardFirmware/issues/165#issuecomment-236394087, or mute the thread https://github.com/notifications/unsubscribe-auth/AQ4taANGzoL5hfdsvLkB8Uw9qCeTBnVHks5qa9RwgaJpZM4JXbsY .

[caall99]

Update: VM is installed, but I don't understand how to access source distribution. What do I type into terminal to start build process? Thanks.

On Sat, Aug 13, 2016 at 6:23 PM, Chris caall99@gmail.com wrote:

Hi Dan,

I can't figure out how to build the firmware with your VM. I loaded the VM that you prepackaged, but nothing is intuitive... i.e. I have no idea what to do now...

On Sat, Jul 30, 2016 at 6:47 PM, dbavatar notifications@github.com wrote:

Yeah that's just not going to work well. I've been working on this problem, it's not an easy fix I'll tell you that. If you can reduce the speed of all small segments from your slicer, that would help. Lowering max speed change does not have the effect you would think it has when you lots of small segments. Setting it to 0 in you situation for example would get really bad results. Technically, I know how to make a build that would limit segments by minimum execution time, but this isn't great for overall print speed, and doesn't entirely solve the issue.

I don't know what a final solution will look like. I'm even looking at if pre-processing the file into a new format will solve the issues (p3g?), I got the idea from the simulator/sailtime components. The fundamental limitation is that the atmel cpu is shamefully slow, it doesn't have much power to do much else than service the stepper interrupts. For example, The final velocity computation seems to be so optimized that the results are way too inaccurate to be useful. Even if we had the cpu from the iPhone 1, things would be dramatically better.

If you build from current sailfish head, it will work slightly better, at least it will attempt to slowdown when the machine is choking on segments. You can look on my github too but it's a work in progress right now.

On Sat, Jul 30, 2016 at 6:01 PM, Mark Walker notifications@github.com wrote:

Speaking of Cura 2.1.x, I've noticed that the new CuraEngine does an interesting thing with narrow extrusions (gap fill & last extrusion on a sloping surface). It generates a bunch of small segments with many having really high expressed speeds. I reported a bug a while back that it was generating speeds like 400mm/s. The fix they selected was just to cap it at 150mm/s (not settable), which doesn't really change anything because the firmware was already capping the speed.

The behavior I get when executing these small linear segments at dramatically varying speeds is that the head jerks a lot. It doesn't matter whether I'm printing over USB or from SD card apparently. My guess is that the speed changes all fall within the jerk setting so they're aren't smoothed much by the planner, but to tell you the truth, I haven't experimented much with it, but it is often why I'll use Slic3r instead (though it has its own issues with gap filling).

The reason Cura is doing this is that it is trying to choose a speed such that the desired extrusion volume result in the same internal pressure in the nozzle. I'm not sure if the algorithm is correct, but that is the stated intention. Their motivation is for bowden extruders (like the Ultimaker) due to the lag in changing the extrusion volume. I was thinking a fix for my printer would be just to remove this (via a setting) and have it just set the desired extrusion volume and not try to break the segment into small explicitly set speed segments.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jetty840/Sailfish-MightyBoardFirmware/is sues/165#issuecomment-236392236, or mute the thread https://github.com/notifications/unsubscribe-auth/ANZ_WGeVC TGAFEAgSItTigGYzMuI9EENks5qa8mfgaJpZM4JXbsY

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jetty840/Sailfish-MightyBoardFirmware/issues/165#issuecomment-236394087, or mute the thread https://github.com/notifications/unsubscribe-auth/AQ4taANGzoL5hfdsvLkB8Uw9qCeTBnVHks5qa9RwgaJpZM4JXbsY .

[markwal]

I piped in earlier on a case where Cura would generate small moves unnecessarily (which I understand doesn't cover all the cases that this issue is concerned with), but I thought I'd mention here that the Cura folks accepted my pull request to make a setting for this and they decided to default it to off. So in Cura 2.2 (not yet released) at least a straight line won't hit this.

[caall99]

Thanks for the update! I really enjoy using Cura 2.1.2, but have since moved to Simplify3D. S3D does have its quirks, and is missing some much needed "polish", so I may find myself moving to the Cura "camp" some day in the future. It looks like an inherent issue in Sailfish (as discovered by dbavatar, where the print head races to full speed at every last segment, causing a "hammering" effect) may have been exacerbating these issues for me. I hope the problem can be rectified.

Unfortunately, I still don't know how to build Sailfish in the VM. The instructions on github are insufficient for the uniformed. I have the VM loaded, but don't understand what to do from there...

[caall99]

Just attempted the popular articulated elephant print at 70 mm/s in sailfish. Same problem noticed... Excess filament dumped when the print head races to max speed at the last segment. Causing zits and blobs all over my print. Retrying now at 50 mm/s.

[caall99]

Same result at 3000 mm/min... Noticing same jerky behavior and surface blobbing in unlikely locations. This is a dual bowden converted qidi tech with acceleration for x and y at 750 mm/s^2. Max speed change of 4 mm/s. I hope we can get this resolved.

[caall99]

I have to caveat... This printer runs simple prints with less segments immaculately.

[dnewman-polar3d]

First, please keep in mind that this isn't a support forum. For support, please use the forum appropriate to your printer. With that said, what you're describing sounds like the typical blobbing at the end of each layer and for which each slicer has different strategies to combat. Second, Sailfish's advance wasn't designed with Bowden's in mind. You're breaking new ground. And, as I'm sure you know, Bowdens are notorious for excess blobbing. That's why a lot of folks choose not to use Bowdens and instead use direct drive extruders. Thirdly, I disagree with the comment on organic models and suggest rather that you have a tuning issue with many variables: Sailfish, your Bowden, and your slicer. I see far too many prints done with Sailfish and organic models that come out wonderfully. The following I just grabbed off a shelf: they were all printed at 120 mm/s on a Replicator 2 using Sailfish's default settings, https://www.flickr.com/photos/d-newman/29107386332/in/dateposted-public/ . (The elephants have broken ears which is why I still have them; they disappear quickly to kids in the neighborhood.)

[dnewman-polar3d]

BTW, I didn't mean the above as a "stop posting here". Rather, I wanted to make sure that you weren't expecting this to be a support thread.

[caall99]

Hi Dan,

Back from a very busy last few days. Let me clarify a few things: I am not looking for support pertaining to my original issue, rather, I am commenting on something I feel may be amiss with Sailfish. Isn't that the purpose of github's "issue" repository? The only support I requested was guidance on how to “build” your firmware, as your instructions on github are insufficient (for the uninformed).

Now, it seems you are insistent that there are issues with my Bowden setup or my tuning thereof. Without sounding accusatory, it also seems you are avoiding commenting on something dbavatar discovered may actually be wrong with Sailfish, and is perfectly coinciding with the issue I am experiencing.

My Bowden setup is the result of 300+ hours of tuning, with hundreds of calibration boxes and torture tests. My Bowden setup does not blob... what appears to be causing the blobbing is unnecessary pauses after the print head races to full speed and “hammers” on the last segment (in a chain of small segments). This has NOTHING to do with retraction, because I do not retract unless there is a large travel move.

I assume a way to replicate the issue is to print two cylinders, both equal diameter (preferably small, i.e. 6-8mm), one with a high and one with a low resolution mesh. The higher resolution model will print erratically, with hammering of the print head, and excess extrusion as the print head “hammers” into place and pauses… The lower resolution model will have a smooth surface and print perfectly. This is not a tuning problem…

I have the utmost respect for you and Sailfish firmware, but this hammering in detailed segments, and excess extrusion during unplanned pauses, are nothing I can “tune away” or improve. My 32-bit smoothieware based printers do not hammer the print head and abruptly pause as if the processor is “choking”… Sure, they have more processing power... but the issue I am reiterating (and that dbavatar discovered in the code) does not appear to be due to processor limitations. Even if it was due to computational performance of the Atmega processor, the firmware should smoothly slow the print, until the planner catches up.

Here is an example of a model that I attempted to execute at 40mm/s with my aforementioned 750 mm/s^2 acceleration and 4 mm/s max speed change: http://www.thingiverse.com/thing:33902 The cylinders come out looking atrocious! It appears Sailfish cannot navigate the perimeters without banging around, blobbing and making a mess of things…. Whereas the straight areas (such as the box portion) come out perfectly.

All things considered, on those models that Sailfish can print without “hammering and pausing”, I get excellent quality from my Bowden setup, rivaling that of direct extruders. My surface finish is perfect, my corners are sharp, and I have ZERO ringing or other artifacts. Unfortunately, there is clearly something wrong with Sailfish in how it handles many small segments – dbavatar found it in the code, and I am seeing it in my prints.

[dnewman-polar3d]

I'll leave it to dbavatar to comment on whether or not I've been ignoring his issue. I've had private conversations with him. At one point I was set to test his changes but he found an issue with them and withdrew them. He has a new set of changes, but I've not had time to test them. I have started a new job and right now we are in the middle of attempting to get three new software releases shipped. In short, I'm very busy at the moment. (No different than anyone else.) If he has a good solution to the hammering which all the Grbl derived firmwares are subject to, then that is welcome news and I look forward to testing it and, hopefully adopting it. However that requires time I do not have at the moment. (And one of these three software releases is firmware for a 3D printer. )

And, the excellent results you report for Bowdens is great news. Plenty of community members will be very interested in learning of your findings.

[caall99]

Thanks Dan! Glad to hear that we are on the same page, and thrilled that you and dbavatar are trying to find a solution!

This "hammering and pausing" issue is the ONLY thing that appears to be holding my machine back. Everything else about sailfish is functioning very well with my setup (and the stock direct drive setup, for that matter). All in all, the Bowden setup has been a fantastic upgrade to the machine. Theoretically I should be able to print faster, at the same quality.. but thus far have kept speeds and acceleration relatively low and aiming for quality. I am sure it's capable of a lot more acceleration and speed, but must still be cognizant of the x-axis stepper motor's weight.

Wish you best of luck with your other software/firmware releases! I'll be lingering around, keeping tabs on your collective updates to Sailfish.

[gewaechshaus]

Very nice thread here...

[dbavatar]

Hi, so the hammering issue is a very complicated thing that relies on drawing on a diverse background from physics to mechanical engineering and computer science to get right. It will not be a single simple "bug fix". For example, you can take a look in my hammerfix branch where I have a fix for an incorrectly calculated v=v_i^2+2ad calculation. The theory is right, the comments are right, but the answer is wrong. It took an extraordinary amount of debugging and time to find that issue. Gut feeling is at least 1-2 more issues like that, plus the nominal behavior of the planner. I do have a day job so I can't work on it all the time.

I believe it's possible to get it the behavior we're all looking for, namely that you can feed anything to the printer, and it WILL print at appropriate velocities, but there is a bit of work to do between here and there. If anyone is interested in discussing the highly technical details of trajectory planning and optimizing for the atmega, that would be great. My observation about the 3D printing community is that every everyone wants to be a hardware hacker when the real problem is software. I think amazing things are possible through the software upgrades (not just printing without hammering) but very few with hardware upgrades. So if like 0.5% of the community would get into software, that would be great.

[caall99]

I am a total noob, but this part in configuration.hh (from dbavatar's fork) looks interesting:

339 //Minimum time in seconds that a movement needs to take if the planning pipeline command buffer is 340 //emptied. Increase this number if you see blobs while printing high speed & high detail. It will 341 //slowdown on the detailed stuff. 342 #define ACCELERATION_MIN_SEGMENT_TIME 0.0200

Besides the hammering issue, would an increase to this value solve my blobbing issue? Thereby at least solving part of the problem? I would appreciate even slower printing on detailed parts...

I am in a jam in regards to continuing to use Sailfish, or converting the Qidi Tech to smoothieware or some other software ecosystem. I have an immediate need to print several finely detailed models, and cannot do so now even at speeds of 30 to 40 mm/s. I know the both of you would like to resolve the Sailfish issues, but do you suggest I proceed with my conversion, given that a Sailfish solution may not be implemented for some time?

[dbavatar]

That macro won't do what you want it to do.

Try printing without acceleration and a tolerable max speed change, i.e. 15. I haven't done so yet, but from code inspection it should avoid the issues I know about. No idea what it does to JKN. There's actually no point to acceleration and trajectory planning anyway when you just have a infinite stream of tiny segments.

[caall99]

If you turn off acceleration, doesn't max speed change no longer play a role? Mine is at 4mm/s

[dbavatar]

max_speed_change with no acceleration is used to calculate allowable speed difference between blocks to moderate the speed of the next block.

You will get blobbing from acceleration trapezoids for each block if you have a max_speed_change that low with acceleration on. 0 produces terrible results for example, and the printer vibrates the whole time. The implementation is really enforcing intra-block allowable speed change versus jerk, which means actually you get smoother prints at higher values. I don't think this is intentional, it's certainly not intuitive. In case that was unclear - if you have n segments and max_speed_change set to 0, the intra-block speed is always 0. If it is set to 4, then segment 2 can start 4 faster than 1, and 3 can start 4 faster than 2. So this will resulting velocities will be like: 0 4 8 12.

[dbavatar]

that cut out my tags and edit button isn't working, try again: 0 [trapezoid] 4 [trapezoid] 8 [trapezoid] 12 ... up to feed rate.

[dnewman-polar3d]

@dbavatar Reasoning goes back to the "pre-accel" firmware days. When everyone printed around 30 - 40 mm/s with "instantaneous" speed changes. Worked mostly fine. Thus the theory was that at low speeds, it's okay to take big speed changes. And hence the effect of speed change is aimed at higher speeds.

[dbavatar]

I wonder if that's because the scaling of kinetic energy as 0.5mv^2. We should be managing either total momentum or total kinetic energy versus delta-v, and off the top of my head I can't think of which is the right thing to do, I would think it would be kinetic energy.

[dcnewman]

On 29/08/2016 11:18 AM, dbavatar wrote:

I wonder if that's because the scaling of kinetic energy as 0.5mv^2. We should be managing either total momentum

And there may be patents there if I recall correctly. I know someone who applied for one for controlling the momentum and got rejected because it had already been granted as part of a patent to New Matter (the mod-t folks).

[dbavatar]

I don't see how you can patent Newtonian physics, at least not with a valid patent. I think if this was on a nice ARM32+ cpu with enough RAM and FPU, this whole think would be like a day of work with a Physics 101 textbook handy.

[dnewman-polar3d]

On 29/08/2016 11:44 AM, dbavatar wrote:

I don't see how you can patent Newtonian physics, at least not with a valid patent.

IANAL and I don't have a lot of respect for some of the patents which have been granted.

I think if this was on a nice ARM32+ cpu with enough RAM and FPU, this whole think would be like a day of work with a Physics 101 textbook handy.

Yes.

[caall99]

Currently printing without acceleration, at 20 mm/s speed, but forgot to change my max_speed_change from 4 mm/s to 15 mm/s. Printing the torture test right now - first two layers are looking better than ever, but still experiencing some banging from my 66 mm/s travel speed (too fast, I know). Will keep you all updated.

[caall99]

4 mm/s and 15 mm/s max speed change performed identically with acceleration turned off. Quality is certainly better... but prints take a long time. There is a pause when the print head transitions from inner loop to outer loop on a 2 perimeter circle. This causes blobbing. I would think that the short movement from inner to outer loop should happen nearly instantly, yet it pauses between the segments that start and end the "connector" between inner and outer loop.

[dcnewman]

On 29/08/2016 6:06 PM, caall99 wrote:

4 mm/s and 15 mm/s max speed change performed identically with acceleration turned off. Quality is certainly better... but prints take a long time. There is a pause when the print head transitions from inner loop to outer loop on a 2 perimeter circle. This causes blobbing. I would think that the short movement from inner to outer loop should happen nearly instantly, yet it pauses between the segments that start and end the "connector" between inner and outer loop.

It's possible that the stepper interrupt was waiting for more planned segments. It's possible for the planner which does not run at priority to fall behind the stepper interrupt. (All interrupts can interrupt normal processing code. So, if the interrupt is very busy, particularly with very short segments, its queue can run dry. One of the reasons to decimate your models and not have lots of fine detail.

Dan

[caall99]

Dan, thanks for the explanation. Sounds like that is whats happening. I have noticed it doesnt happen on larger diameter cylinders. The blobbing and pausing on perimeters doesnt appear then. Whats unfortunate is that the model i was printing is a very popular test model by MAKE magazine. It should be printable as is. Is it incompatible with Sailfish?

[dnewman-polar3d]

On 29/08/2016 7:15 PM, caall99 wrote:

Dan, thanks for the explanation. Sounds like that is whats happening. I have noticed it doesnt happen on larger diameter cylinders. The blobbing and pausing on perimeters doesnt appear then. Whats unfortunate is that the model i was printing is a very popular test model by MAKE magazine. It should be printable as is. Is it incompatible with Sailfish?

I've seen very excellent Sailfish prints of the torture test. Jetguy has put some wonderful ones up in the past on his flickr pages.

You have to realize that there's lots of nuances. Different slicers handle it differently and may even do things like slow way down for fine detail (e.g., slic3r). And then there's the settings in your firmware and whether they really match the mechanics of your printer. And then there's your printer itself. The best prints I've seen (with any firmware) have been on pretty rigid Core-XY printers.

Dan

[dbavatar]

On Mon, Aug 29, 2016 at 9:50 PM, Dan Newman notifications@github.com wrote:

It's possible that the stepper interrupt was waiting for more planned segments. It's possible for the planner which does not run at priority to fall behind the stepper interrupt. (All interrupts can interrupt normal processing code. So, if the interrupt is very busy, particularly with very short segments, its queue can run dry. One of the reasons to decimate your models and not have lots of fine detail.

If that theory is right then this commit will help:

https://github.com/dbavatar/Sailfish-MightyBoardFirmware/commit/9b746bac6b2a85f2f9f5b4cef2a26a6c09b70dbb

[caall99]

Thanks, but unfortunately i still dont know how to build from source. I have the VM setup, but dont know what to do from there. Would it be too much to ask for a .hex for a replicator 1 dual with atmega 2560? I have an avrisp mkii with which i flashed 7.7 r1432, from qidi techs version of sailfish.

[caall99]

I cannot move files from my host machine to virtual box (i.e. can't get the source code into the VM for building). Perhaps this version of virtual box doesn't like Windows 10? Should I go ahead and update all of Ubuntu before trying to build anything? Or are there incompatibilities with newer versions of applications/software? I have already built the avr-gcc tool chain (or at least I think I did... the terminal prompt disappeared by itself after 10 to 15 minutes.

I would also like to include the following advanced options in my build: (HEATERS_ON_STEROIDS) and (BUILD_STATS). I assume heater on steroids just allows steppers and both heaters to be powered simultaneously, but does not actually allow the heater to draw more than intended current, correct?

I know this is not a support forum, but I cannot find instruction elsewhere. Once I know how to build from source, I would like to start contributing to the coding.

[dnewman-polar3d]

Either enable file sharing via VirtualBox's settings for the system or use TCP/IP based tools such as "scp". I have no idea what will happen if you update ubuntu. It's a VM so snapshot it and try. If you have problems, roll back to the snapshot.

Nothing in the firmware limits current draw. What heater on steroids does is allow concurrent warmup of both the HBP and extruders. When cold, resistive heaters draw more power than when warm. Makerbot supplied a small power supply and thus could not allow concurrent heating of both from cold. You would follow the directions in the top of firmware/src/platforms.py for how to set up a specific set of options for a build.

[caall99]

Thank you. I will give this another try at home tonight.

I am now noticing that the Zortrax M200, Ultimaker 2, Wanhao D6 and MonoPrice Maker Ultimate also use the Atmega 2560. I have watched our Zortrax M200 print at work, and it doesn't exhibit any of the hammering/pausing issues, even on small detailed prints. Its just an observation that other printers are getting by with the same processing power, yet are not exhibiting some of the issues that Sailfish has. What are their firmwares derived from? Not Marlin/Gbrl?

[dnewman-polar3d]

On 30/08/2016 9:35 AM, caall99 wrote:

Thank you. I will give this another try at home tonight.

I am now noticing that the Zortrax M200,

News to me that the M200 uses an AVR. All the ones I've seen have a 32 bit ARM. It has the horsepower to deal better with that problem. It's why many folks have moved to fast 32 bit, preferrably with hardware floating point.

Ultimaker 2, Wanhao D6 and MonoPrice Maker Ultimate also use the Atmega 2560.

And they all suffer from the same issue. People mask it by slowing way down on perimeters. And slic3r -- maybe Cura too -- takes actions when they spot small, fine detail. S3D is, unfortunately, notorious for outputting lots of small fine detail in its gcode. (Tripped up smoothieware for close to a year.)

that other printers are getting by with the same processing power, yet are not exhibiting some of the issues that Sailfish has. What are their firmwares derived from? Not Marlin/Gbrl?

Zortrax is a rewrite from scratch. But all the Grbl derived AVR firmwares have this issue. People just mask it in their slicing and model design.

Dan

[caall99]

Sorry, I assumed too much regarding the Zortrax M200. I thought it was very similar to those others which do use an Atmega2560.

Arthur Wolf (from Smoothieware) mentions in this thread that S3D has fixed the problem: https://groups.google.com/d/msg/smoothieware-support/2r0JLV3G5i8/hVBgkhzuCwAJ

Are you saying that S3D is still generating superfluous segmentation after the 3.1 fix? I don't have S3D gcode output available to me at work to peruse, but will take a look when I am at home. Thanks

[dnewman-polar3d]

On 30/08/2016 11:40 AM, caall99 wrote:

Are you saying that S3D is still generating superfluous segmentation after the 3.1 fix? I don't have S3D gcode output available to me at work to peruse, but will take a look when I am at home. Thanks

Which issue? S3D was generating moves so small that the firmwares had to just know to toss them out as they involved partial motor steps and couldn't be executed. But beyond that, there's the issue of the slicer identifying small fine detail and slowing down the print specifically for that detail. I believe S3D addressed the former issue. I am not aware of them providing support for the later issue unlike slic3r, MakerBot Desktop, and possibly Cura as well. It's this later detail which is what aids printing on AVRs in particular: just slowing way down when the slicer identifies problematic regions.

Dan

[caall99]

This is the error presented to me when i try to build:

scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... scons: `.' is up to date. scons: done building targets. vagrant@vagrant:~/Desktop/New sailfish/firmware$ scons platform=mighty_one-2560 scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... /usr/bin/avr-g++ -o build/mighty_one-2560/MightyBoard/Motherboard/Command.o -c -DF_CPU=16000000L -DCUTOFF_PRESENT=0 -DESTIMATE_TIME -DVERSION=708 -DSTREAM_VERSION=100 -DVERSION_INTERNAL=0 -DVCS_VERSION=1234 -DVCS_VERSION_STR='"01234"' -DVERSION_STR='"7.8"' -DDATE_STR='"16/08/30"' -g -Os -Wall -Wextra -Winline -Wno-deprecated-declarations -fno-exceptions -ffunction-sections -fdata-sections -fshort-enums -mmcu=atmega2560 -DBUILD_STATS -DALTERNATE_UART -DAUTO_LEVEL -DPSTOP_ZMIN_LEVEL -DHAS_RGB_LED "-DPLATFORM_SPLASH1_MSG=\"Sailfish Replicator1\"" "-DPLATFORM_THE_REPLICATOR_STR=\"Replicator 1\"" -DEEPROM_MENU_ENABLE -DRGB_LED_MENU -Ibuild/mighty_one-2560/MightyBoard/shared -Ibuild/mighty_one-2560/MightyBoard/Motherboard -Ibuild/mighty_one-2560/MightyBoard/shared/locale -Ibuild/mighty_one-2560/MightyBoard/Motherboard/avrfix -Ibuild/mighty_one-2560/MightyBoard/Motherboard/boards/mighty_one -Ibuild/mighty_one-2560 build/mighty_one-2560/MightyBoard/Motherboard/Command.cc /usr/libexec/gcc/avr/4.6.3/cc1plus: error while loading shared libraries: libmpc.so.2: cannot open shared object file: No such file or directory scons: *\ [build/mighty_one-2560/MightyBoard/Motherboard/Command.o] Error 1 scons: building terminated because of errors.

Can you point me in the right direction? Thanks

[dnewman-polar3d]

On 30/08/2016 4:57 PM, caall99 wrote:

This is the error presented to me when i try to build:

I'll take a look but it will take me at least an hour to download the VM from dropbox.

[dnewman-polar3d]

Can you point me in the right direction? Thanks

This also suggests that that shared library is for some reason now missing on the VM. Did you update Ubuntu in the VM? If so, that may have cleared out old shared libraries which you still needed.

Dan

[caall99]

I did resort to updating Ubuntu because I was unable to share files between the VM and the host. It finally allowed me to see other computers on my network, and I could drag the files into a shared folder. I am using Windows 10 as the host, not sure if that's also causing issues. I updated virtual box as well.

[dnewman-polar3d]

On 30/08/2016 4:57 PM, caall99 wrote:

This is the error presented to me when i try to build:

scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... scons: `.' is up to date. scons: done building targets. vagrant@vagrant:~/Desktop/New sailfish/firmware$ scons platform=mighty_one-2560 scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... /usr/bin/avr-g++ -o build/mighty_one-2560/MightyBoard/Motherboard/Command.o -c -DF_CPU=16000000L -DCUTOFF_PRESENT=0 -DESTIMATE_TIME -DVERSION=708 -DSTREAM_VERSION=100 -DVERSION_INTERNAL=0 -DVCS_VERSION=1234 -DVCS_VERSION_STR='"01234"' -DVERSION_STR='"7.8"' -DDATE_STR='"16/08/30"' -g -Os -Wall -Wextra -Winline -Wno-deprecated-declarations -fno-exceptions -ffunction-sections -fdata-sections -fshort-enums -mmcu=atmega2560 -DBUILD_STATS -DALTERNATE_UART -DAUTO_LEVEL -DPSTOP_ZMIN_LEVEL -DHAS_RGB_LED "-DPLATFORM_SPLASH1_MSG=\"Sailfish Replicator1\"" "-DPLATFORM_THE_REPLICATOR_STR=\"Replicator 1\"" -DEEPROM_MENU_ENABLE -DRGB_LED_MENU -Ibuild/mighty_one-2560/MightyBoard/shared -Ibuild/mighty_one-2560/MightyBoard/Motherboard -Ibuild/mighty_one-2560/MightyBoard/shared/locale -Ibuild/mighty_one-2560/MightyBoard/Motherboard/avrfix -Ibuild/mighty_one-2560/MightyBoard/Motherboard/boards/mighty_one -Ibuild/mighty_one-2560 build/mighty_one-2560/MightyBoard/Motherboard/Command.cc /usr/libexec/gcc/avr/4.6.3/cc1plus: error while loading shared libraries: libmpc.so.2: cannot open shared object file: No such file or directory scons: *\ [build/mighty_one-2560/MightyBoard/Motherboard/Command.o] Error 1 scons: building terminated because of errors.

It builds for me. I used the 32bit VM. I moved the files I wanted to the directory from which I issued the vagrant ssh command. Then on the VM, I got those files from the /vagrant/ directory within the VM. (The directory you run vagrant in is shared with the VM as the directory /vagrant/.)

I was able to build the sources with no errors.

So, the Ubuntu uprade removed files needed. You can rebuild the avr gcc toolchain using the sources in the build-avr-gcc directory. There's a command script to do the build and install. It ran for me but I hadn't update the VM. I cannot guarantee it will run after you update the VM.

Dan

[dnewman-polar3d]

... when you login, to rebuild the avr-gcc toolchain issue the two commands

cd build-avr-gcc/ ./build-avr-gcc-ubuntu12.04.sh

And it will redownload the packages, build them in situ, and install them.

[caall99]

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!