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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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.