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

[caall99]

dbavatar: not sure if you see my posts/convos elsewhere on this site.. But I wanted to let you know I tried Dan's newest merged master with your additions. I tried to compile the *.hex with avr-gcc 4.9.2 as you have done. I did so by changing the requested firmware from 4.6.3 to 4.9.2 in Dan's "build-avr-gcc-ubuntu12.04.sh" build script, and then running the build script in terminal. I was able to successfully built the firmware. Unfortunately, after attempting to flash with my AVR mkII flasher I get a blank LCD screen on the printer. What else did you use to build your version of the firmware? what binutils? avr-libc?

[caall99]

So anyways... I built my new firmware from Dan's newest master with all of dbavatar's "hammerfix" commits. I can't say its any better than what I had before (which was only the pipeline SD card reads commit). Unfortunately, I still get occasional hammering... I am wondering if decimation to 0.1mm (or rather, mesh reduction in S3D) should always be used, regardless of the model. It seems as though some complicated and detailed models have higher concentration of detail in small areas, and even if decimation does not significantly reduce the total segment count, it at least spreads the segments out evenly across the entire model. This seems to avoid some of the dreaded hammering/choking on segments. Thoughts? What else are you guys working on now?

[caall99]

Another note (but also please respond to my last post!), ever since upgrading to the new "master" my hot end cannot achieve the set temperature I am requesting. When I request 222, I get 217. when I request 225 I get 220... and it says heating... I complete entire prints with this behavior. Usually 5 degs lower than the requested temp. i.e. LCD shows 217/222 for the entire print duration.

[dnewman-polar3d]

On 14/09/2016 4:32 PM, caall99 wrote:

Another note (but also please respond to my last post!), ever since upgrading to the new "master" my hot end cannot achieve the set temperature I am requesting. When I request 222, I get 217. when I request 225 I get 220... and it says heating... I complete entire prints with this behavior. Usually 5 degs lower than the requested temp. i.e. LCD shows 217/222 for the entire print duration.

This printer isn't a Rep 2X is it? MBI made an engineering change to the 2X without sufficient testing. Then when people received them they found that the change was causing air wash over the now exposed top of the right heater block. It could never reach temperature with its PID tuning. So, they changed their firmware to tweak the PID settings for a Rep 2X. (Problem was, people with older Rep 2X's also picked up that change when they upgraded the firmware.)

In Sailfish, we've never made that tweak and instead just put into the docs and troubleshooting section the change to make in EEPROM to the PID tuning.

Dan

[caall99]

The printer is a Qidi Tech. Essentially a replicator 1 dual and flashforge creator pro clone. I am using additional part cooling through a custom dual fan shroud (dbavatar recommended it in this thread) at all times for ABS, as it has been improving my print quality tremendously.

Would any air washing over the active hot end cause a similar issue? I do have insulated heater blocks.. granted they are wrapped side to side, and there is no insulation front to back where the heater cartridge and thermocouple go. My fan shroud is blowing back to front onto the right hot end... but it is directed down to the brass nozzle and below.

[dnewman-polar3d]

On 14/09/2016 4:50 PM, caall99 wrote:

The printer is a Qidi Tech. Essentially a replicator 1 dual and flashforge creator pro clone. I am using additional part cooling through a custom dual fan shroud (dbavatar recommended it in this thread) at all times for ABS, as it has been improving my print quality tremendously.

Would any air washing over the active hot end cause a similar issue?

No clue, but if this is a QiDi you need to tread carefully in changing the firmware. As I'm sure you're aware, QiDi has made undisclosed changes to the electronics which in turn, apparently, has necessitated undisclosed changes to the firmware. I've heard plenty of reports over the past 18 months or so of people installing the "official" Sailfish and then have various issues. At least one distributor -- Uncle Chuck -- has told people in the past that they should NOT upgrade to Sailfish for those reasons -- differences which QiDi has done and refused to disclose.

Dan

[caall99]

This started happening after my most recent firmware flash to your newest master. Temperature held well before.

What are you and dbavatar working on now?

[dbavatar]

On Wed, Sep 14, 2016 at 8:00 PM, caall99 notifications@github.com wrote:

This started happening after my most recent firmware flash to your newest master. Temperature held well before.

What are you and dbavatar working on now?

I have not tried sailfish master yet, still using my branch.

[caall99]

How do they differ? When did they deviate from being the same?

[dcnewman]

On 14/09/2016 5:00 PM, caall99 wrote:

This started happening after my most recent firmware flash to your newest master. Temperature held well before.

What are you and dbavatar working on now?

My printers running Sailfish are

Core-XY with Azteeg X3 Core-XY with FF MightyBoard clone Rep 2 with MBI MightyBoard rev G (heavily modified machine) ZYYX with MBot3d MightyBoard clone and dual extruders (modified for dual extrusion) Thing-o-Matic with Gen 4 electronics

(Then I have printers with RepRapFirmware on ARM; and assorted other printers.)

[dbavatar]

On Wed, Sep 14, 2016 at 7:50 PM, caall99 notifications@github.com wrote:

The printer is a Qidi Tech. Essentially a replicator 1 dual and flashforge creator pro clone. I am using additional part cooling through a custom dual fan shroud (dbavatar recommended it in this thread) at all times for ABS, as it has been improving my print quality tremendously.

Would any air washing over the active hot end cause a similar issue? I do have insulated heater blocks.. granted they are wrapped side to side, and there is no insulation front to back where the heater cartridge and thermocouple go. My fan shroud is blowing back to front onto the right hot end... but it is directed down to the brass nozzle and below.

I had to tune my PID more aggressively than what came as defaults on my FFCP to hold set temp.

[caall99]

So i need to follow the documentation and change the PID "I" value to .45?

How is RepRapFirmware on an ARM working for you? How does it compare to Sailfish? Can you tell me more about that setup? Lastly, do you think its worthwhile upgrading my Qidi to RepRapFirmware with a Duet?

[caall99]

dbavatar do you recall your PID values?

[dnewman-polar3d]

On 14/09/2016 5:17 PM, caall99 wrote:

So i need to follow the documentation and change the PID "I" value to .45?

If you have a Rep 2X.

If you do not have a Rep 2X, do not do that. I do not recommend to anyone that they do PID tuning unless they really know what they are doing. And these firmwares do not implement true PID.

How is RepRapFirmware on an ARM working for you?

I like it a lot. It doesn't use Bresenham's line algorithm and instead runs each axis at its correct speed.

How does it compare to Sailfish?

Different. What I do like is that, like Sailfish, they take safety very seriously:

1. Electronics have heaters switched off on power up; doesn't require the firmware running to disable heaters.
2. Firmware on startup turns heaters off.
3. ARM watchdog enabled, working, and testable. So firmware, if it locks up, ARM resets and rebooting firmware ensures heaters off. Watchdog writes info to NVRAM for post mortem.
4. Secondary, software based watchdog; writes info to NVRAM for post mortem.
5. All heaters on hardware PWM. With software PWM, a firmware lockup can leave the heater on 100%.
6. Code to detect run-away heater and trigger alerts. (It's possible for the MOSFET controlling a heater to fail ON in which case the firmware can do nothing but try to send alerts).
7. Brown-out-detection interrupt which rights info to NVRAM for post mortem.
8. Very nice web interface.
9. Leverages ARM features (unlike the Marlin and Repetier ports to ARM which just try to be AVR like): a. High speed, parallel SD card interface. b. DMA for SD card, USB, etc. which speeds up those interfaces. c. Use of frequency based interrupts to detect issues with fans that have the RPM monitoring signal. d. Etc.

Lastly, do you think its worthwhile upgrading my Qidi to RepRapFirmware with a Duet?

Hard to say. I suspect that it will work better for you with your models. But without trying, and that's a lot of work changing the machine, it's hard to prove.

[caall99]

Thank you for all this... these are convincing arguments! I was curious more in regards to printing behavior, noise, motion, consistency of extrusion... in other words, does the ARM setup get rid of 99% of the motion planning related issues that I have reported on this entire thread - and if so, is processing power the reason, or different algorithms and code?

[dnewman-polar3d]

On 14/09/2016 5:40 PM, caall99 wrote:

Thank you for all this... these are convincing arguments! I was curious more in regards to printing behavior, noise, motion, consistency of extrusion... in other words, does the ARM setup get rid of 99% of the motion planning related issues that I have reported on this entire thread

I think they would be better. I'd run a print for you except that the only running RRF printer I have right now is a Delta. One is on loan, and the other I just pulled the RRF board out of to take with me to Ohio next week.

• and if so, is processing power the reason, or different algorithms and code?

All of the above: 32 bit, 5 - 7x faster processor (depending upon the board), hardware floating point, different algorithms, different motion control, no double and quad stepping when the step rate gets too high for the interrupt to handle, etc.

Dan

[dbavatar]

On Wed, Sep 14, 2016 at 8:23 PM, caall99 notifications@github.com wrote:

dbavatar do you recall your PID values?

8.125, 0.341, 32.376

[dnewman-polar3d]

FWIW, I announced on the jetty-firmware mailing list a 7.8 beta test (r1677) which includes these changes/fixes by dbavatar.

[ghost]

The ghost of Christmas present says YET_ANOTHER_JERK should not set scaling = 0; if ( current_speed[i] == 0 ) to avoid a divide by 0. Think of a circle, X & Y each hit 0 when the other axis is at its fastest speed causing shuddering and jerking when it's suddenly reduced to the slowest speed for no good reason. The old code that set s = FPDIV(max_speed_change[i], delta_v); and doesn't "break;" out of the loop works far better.

[dnewman-polar3d]

That old code had different issues. For example, the more facets a cylinder was broken into, the slower it would print the overall circular cross section. I'd have to dig up the old e-mail from late 2012 on the issue, but Emmett (heartgears) turned up that issue. That was much of the impetus for the current code.

[dnewman-polar3d]

Possibly,

FPTYPE s, cs = current_speed[i] ? current_speed[i] : delta_v;
if ( cs == 0 ) {
    scaling = 0;
    break;
}
else if ( current_speed[i] > prev_speed[i] ) {
    s = FPDIV(prev_speed[i] + max_speed_change[i], cs);
}
else {
    s = FPDIV(prev_speed[i] - max_speed_change[i], cs);
}

[ghost]

Well, I did 3 hours of testing that change instead, but no, it's not as good as the old code.

FYI: The main test I'm using is @ 72mm/s & 73mm/s (72 doesn't enter YAJ, 73 does) and it's an OpenSCAD 0.4mm cylinder that matches my nozzle size, this was a real object I was printing and it took me a while to work out what speeds were good and bad on the CTC: (also note, the top and bottom of the circle are not "flat" so speed 0 doesn't happen until it gets to the left or rightmost edge, rightmost in my tests because it starts on the left)

$fa=0.5; $fs=0.5; difference() { cylinder(r=25/2,h=20); translate([0,0,-1]) cylinder(r=(25-0.8)/2,h=22); }

MakerBot Desktop was used to generate the x3g. Also FYI, I reprogrammed the stepper timer so it was a fair bit slower to see what was happening in detail, as I thought the bearings were catching at higher speeds. That was illuminating, as it still looked like it was catching on something just in slow motion!

The old code has no jerks or shuddering, the current code has one big thump at X speed = 0 on the right where speed is at the maximum since the circle starts on the left.. Your new code has two small jerks at both top and bottom Y speed = (or near) 0 but with those speed changes, I'm no longer sure YAJ is entering into it since the maximum speed reached could be below 73mm/s.

Unfortunately, I'm not going to be able to help any more than this.

[dnewman-polar3d]

Thanks for trying it. The old code is known to have other issues. Maybe some day, I'll finish up the GPX extension I have which simply does all the planning on the desktop. Actually that part is mostly finished. It's changing the firmware to consume the results. The GPX extension just turns the entire motion planning into a linear programming problem. And since you have all the data available, the velocities before and after can be considered at each vertex. Not only does it work much better, it seems to give lower overall print times. It's just then a matter of making a new X3G command that carries the pre-planned segment data AND also extending the X3G packet size past 32 bytes. I'm hoping to have time to look at it in 2017, but we'll see.

[dbavatar]

On Wed, Dec 28, 2016 at 8:40 PM, dnewman-polar3d notifications@github.com wrote:

Thanks for trying it. The old code is known to have other issues. Maybe some day, I'll finish up the GPX extension I have which simply does all the planning on the desktop. Actually that part is mostly finished. It's changing the firmware to consume the results. The GPX extension just turns the entire motion planning into a linear programming problem. And since you have all the data available, the velocities before and after can be considered at each vertex. Not only does it work much better, it seems to give lower overall print times. It's just then a matter of making a new X3G command that carries the pre-planned segment data AND also extending the X3G packet size past 32 bytes. I'm hoping to have time to look at it in 2017, but we'll see.

I think this is the only real solution, for the fastest and smoothest printing. The cpu has enough horsepower to run the interrupts, especially if it's not doing complex math to compute accelerations in the interrupt like it is now. Then you can get rid of all the planning code, and the pipelined SD card read commit should remain. This should run the print head at physical limits at all times, unless the SD card can't keep up anymore.

[dbavatar]

On Wed, Dec 28, 2016 at 7:53 PM, Jasoroony notifications@github.com wrote:

Well, I did 3 hours of testing that change instead, but no, it's not as good as the old code.

FYI: The main test I'm using is @ 72mm/s & 73mm/s (72 doesn't enter YAJ, 73 does) and it's an OpenSCAD 0.4mm cylinder that matches my nozzle size, this was a real object I was printing and it took me a while to work out what speeds were good and bad on the CTC: (also note, the top and bottom of the circle are not "flat" so speed 0 doesn't happen until it gets to the left or rightmost edge, rightmost in my tests because it starts on the left)

$fa=0.5; $fs=0.5; difference() { cylinder(r=25/2,h=20); translate([0,0,-1]) cylinder(r=(25-0.8)/2,h=22); }

MakerBot Desktop was used to generate the x3g. Also FYI, I reprogrammed the stepper timer so it was a fair bit slower to see what was happening in detail, as I thought the bearings were catching at higher speeds. That was illuminating, as it still looked like it was catching on something just in slow motion!

The old code has no jerks or shuddering, the current code has one big thump at X speed = 0 on the right where speed is at the maximum since the circle starts on the left.. Your new code has two small jerks at both top and bottom Y speed = (or near) 0 but with those speed changes, I'm no longer sure YAJ is entering into it since the maximum speed reached could be below 73mm/s.

Unfortunately, I'm not going to be able to help any more than this.

The main problem with the new or old slowdown code is that it computes the slowdowns at the input to the planning queue, and as such can only be an estimate. Sometimes one will work better than the other. It would be better if it was being done as the plan is being executed, in interrupt mode, but the overhead here is something like O(32n), as it needs to be able to compute slowdown to 0 velocity at the end of any given block queue. Even more unfortunate is that there are detailed scenes for which 16 blocks is not enough to decelerate to 0 velocity while obeying the max acceleration specified, so either you print super slowly, or keep printing fast crossing your fingers more blocks show up in time, and sometimes they don't.

[killisch]

I'm a fair bit behind all of this, and trying to catch up. But could someone explain to me why the jerking is lessened quite a bit when i print over usb using Simplify 3d, as apposed to the exact same file/settings being printed from the SD card, it's not totally removed. but considerably reduced. Highlighting that the print is better over usb NOT the sd card, as everyone keeps telling me usb is crap. Is the board running out of computing power to calculate small curves? I'm only printing at 70mm/s using acceleration, on a wanhao duplicator 4s with the 1280 cpu.. running proper sailfish v7.7 I've gone as far as modifying the printer to use a bowden setup for both extruders so it's super lightweight. doesn't shake any more with acceleration turned off either, almost seems to be stopping momentarily. Would desoldering and sticking on a 2560 cpu be an option? i have the spare chip and hot air solder station.

***Updated to 7.8 beta and it's alleviated a whole lot of the issues i was seeing. created a few more but that'll take time to investigate. Cheers

[caall99]

Hey all,

Just checking in! I know Dan has been busy with life. I am wiping the dust off my Replicator 1 Dual clone, and curious if there have been any advancements made in motion planning as dbavatar was eluding to in his most recent comment. Thanks for everything.

-Chris

[Kuja-Project]

I havent read through all the messages from people, but its probably because Sailfish has issues with fan Mcodes M126 and M127 can turn on and off your acceleration settings causing your problem, you will need to update to a firmware that allows M106-107 codes, I would think

[markwal]

@TomO2015 Sailfish only receives commands in x3g binary format. It doesn't understand anything about M126, M127, M106 or M107. How those are handled are entirely dependent on how the program you use to translate them to x3g behaves. People typically use GPX, RepG or MakerBot DeskTop/MakerWare to create the x3g (Simplify3D uses GPX). Each of those handles the gcode differently in several instances (M126/M127/M106/M107 is one of those differences).

[Kuja-Project]

Thanks markwal, yes that's what I am implying, I can remember having an issue a long time ago here simplify3ds start script when converted through the GPX would override or turn off he acceleration control, it was a long time ago now but I think it was an M106 or the M126 being interpreted as the acceleration

[PRMoffatt]

I know this topic is a little old now, but I get the same thing on 7.7 with a 1280 - it seems to be much more prevalent when generating skirts or especially single wall extrusion fill with S3D - perhaps because it's making smaller line segments from interpolating outer and inner perimeters - to the point where an otherwise perfect print gets terrible moire patterns on the outside or even fails if the walls are thin enough. I'm just wondering if anyone got any further with it, I'm looking at compiling 7.8b with hammerfix, SD pipelining if I can as some seem to report that works better - but frankly I'm an absolute noob when it comes to compiling and software so I'm still reading documentation.

[ghost]

I guess this will be from the ghost of Christmas future.

Here are my further changes to Sailfish (the ones that are less controversial at least) that included a fix for this issue:

command.cc

platformAccess

... One machine I built didn't like the original calculations here at all:

//Calculate the dda speed. Somewhat crude but effective. Use the Z //axis, it generally has the slowest feed rate

// "Generally" doesn't cut it... Check X and Y so this works properly for all machines. float spmm = stepperAxis[X_AXIS].steps_per_mm; if (spmm > stepperAxis[Y_AXIS].steps_per_mm) spmm = stepperAxis[Y_AXIS].steps_per_mm; if (spmm > stepperAxis[Z_AXIS].steps_per_mm) spmm = stepperAxis[Z_AXIS].steps_per_mm;

int32_t dda_rate = (int32_t)(FPTOF(stepperAxis[Z_AXIS].max_feedrate) spmm /(float)stepperAxis[Z_AXIS].steps_per_mm*/);

runCommandSlice

... A large Z axis machine I built showed these non-sync commands were responsible for not allowing the machine complete prints. These commands are "timed" and should never allow any previous commands (specifically moving a slow Z axis to the bottom) to be included in their timeout period. Remove them from the if statement about syncing. My original suggestion (the "100% command" sync. fix) is no longer needed.

            //(command != HOST_CMD_FIND_AXES_MINIMUM) &&
            //(command != HOST_CMD_FIND_AXES_MAXIMUM) &&

... Optional change, allows unfriendly (makerbot) gcode to work properly on XY Min machines

                mode = HOMING;
                homing_timeout.start(timeout_s * 1000L * 1000L);

ifndef XY_MIN_HOMING

                steppers::startHoming(command==HOST_CMD_FIND_AXES_MAXIMUM,

else

                steppers::startHoming(((flags & ((1 << X_AXIS) | (1 << Y_AXIS))) != 0) ? false : command==HOST_CMD_FIND_AXES_MAXIMUM,

endif

                        flags,
                        feedrate);

host.cc

runHostSlice

... After homing, my Z and Y axis (one each on 2 different machines) would always move a little when the steppers were inactive - so disable the line of code that deactivates the steppers when the homing script finishes.

        //steppers::enableAxes(0xff, false);

motherboard.cc

doStepperInterrupt

... Changed test to be "greater only" (reading the docs suggested this was more correct??) and added advance test.

ifdef ANTI_CLUNK_PROTECTION

//Because it's possible another stepper interrupt became due whilst
//we were processing the last interrupt, and had stepper interrupts
//disabled, we compare the counter to the requested interrupt time
//to see if it overflowed.  If it did, then we reset the counter, and
//schedule another interrupt for very shortly into the future.
if ( STEPPER_TCNTn > STEPPER_OCRnA ) {
    STEPPER_OCRnA = 0x01;    //We set the next interrupt to 1 interval, because this will cause the
                //interrupt to  fire again on the next chance it has after exiting this
                //interrupt, i.e. it gets queued.

    STEPPER_TCNTn = 0;    //Reset the timer counter

    //debug_onscreen1 ++;
}
if (ADVANCE_TCNTn > ADVANCE_OCRnA) {
    ADVANCE_TCNTn = ADVANCE_OCRnA - 2;
}

endif

SDCard.cc

initCard

... Allowing longer ribbon cables to be used with a LCD/controller/SD-card SLOW_SD can be #defined from 0-6 if desired/needed.

ifdef SLOW_SD

speed = SLOW_SD;

else

speed = 0;

endif

... Don't set an error if it's slower than the fastest speed 0

ifndef SLOW_SD

                    if ( !speed )

endif

stepperaccelplanner.cc

plan_buffer_line

... Fixes the loud clunk that often happens on circles when scaling is set to 0 if current_speed[i] == 0. Whatever issues the old code had (when used in this one instance where current_speed[i] == 0) I've not seen in over a year of printing things with this change. Perhaps it was misunderstood I was only going back to the old code in this one case that always screws up and couldn't be worse?

            // We wish to moderate max_entry_speed such that delta_v
            // remains <= max_speed_change.  Moreover, any moderation we
            // apply to the speed along this axis, we need to uniformly
            // apply to all axes and, more importantly, to nominal_speed.
            // As such, we need to determine a scaling factor, s.
            FPTYPE s;
            if (current_speed[i] == 0) {
                s = FPDIV(max_speed_change[i], delta_v);
            }
            else if ( current_speed[i] > prev_speed[i] ) {
                s = FPDIV(prev_speed[i] + max_speed_change[i], current_speed[i]);
            }
            else {
                s = FPDIV(prev_speed[i] - max_speed_change[i], current_speed[i]);
            }
            if ( s < scaling ) {
                if ( s <= 0 ) {
                    scaling = 0;
                    break;
                }
                scaling = s;
            }

steppers.cc

setTargetNewExt

... Changed test from OR to AND to match previous define that's "inverted" to this one.

if !defined(CORE_XY) && !defined(CORE_XYZ)

    feedrate = ITOFP((int32_t)feedrateMult64);

    //Feed rate was multiplied by 64 before it was sent, undo

ifdef FIXED

    feedrate >>= 6;

else

    feedrate /= 64.0;

endif

endif

sd_raw.c

sd_raw_init

... I noticed that SELECT_CARD uses the existing static spi_rate value in init incorrectly.

/* now lower CS */
spi_rate = 6; // Ensure we are still in the slowest mode..
SELECT_CARD();

...

void sd_raw_send_byte(uint8_t b) { uint8_t tries = 0;

SPDR = b;
/* wait for byte to be shifted out */
while(!(SPSR & (1 << SPIF)) && (tries++ < 100))
  _delay_us(1);
//SPSR &= ~(1 << SPIF); // Docs suggest just read SPDR (which is faster) is enough..
tries = SPDR;

}

uint8_t sd_raw_rec_byte() { uint8_t tries = 0; / send dummy data for receiving some / SPDR = 0xff; while(!(SPSR & (1 << SPIF)) && (tries++ < 100)) _delay_us(1); //SPSR &= ~(1 << SPIF); return SPDR; // Docs suggest SPSR is reset by simply reading this.. }

sd_raw_send_command

... Allowing longer for a response (though 10 was always enough). Also different cards (FlashAir) would not always return 0xFF (on all SD card readers) while a reset was being processed. The correct way to handle this is to only test the high bit in a response rather than completely failing an initialise by returning an invalid response when not 0xFF (0x9F on W-03 or 0xF9 on W-04 models, on SD readers with no pull-up resistors, which could be why my mightyboard works ok).

/* receive response */
for(uint8_t i = 0; i < 255; ++i)
{
    response = sd_raw_rec_byte();
    if((response & 0x80) != 0x80)
        break;
}

[PRMoffatt]

Sorry about the delay - but thanks for the reply - I've been spending the time since you posted trying to go through and work out what does what but it's fairly complex for someone who's only programming experience is using a C++ book to level his table up - it's going to take me a while before I get anywhere near compiling what I need I think. Can I be very cheeky and ask if anyone has already compiled the firmware with the various hammerfixes for a 1280 mightyboard (it's a CTC replicator 1 clone)?

[tomservaux]

I can say without a doubt that running with 200mm/sec traversal speed does NOT solve the problem :) . I can't imagine who set it that high... hmmmmmmm

[jordam]

FFCP. I know its not official sailfish but I want others to see if this helps.

For some reason I am able to get much smoother results by increasing the speed on the LCD panel while printing vs speeding up my feed rate.

I've been spending some time trying to speed up my most common prints and for some reason balancing the feed rate set by my slicer and the speed multiplier I am using on the printer works way better then either one on their own.

[ArcanoxDragon]

Has anyone bothered to look into this any further? I experience this on a FlashForge Creator Pro (fork of Sailfish) and it's messing up prints. I captured some slow motion footage of the shuddering; it seems like it cuts deceleration off before finishing a segment, prints the last bit of it very quickly, then begins the next segment at full speed. I can actually see the extruder head and bed wobbling back and forth out of sync in the slow-mo due to the extreme jerk this causes...the quality of circular perimeters is abysmal.

[XZCE]

The ghost of Christmas present says YET_ANOTHER_JERK should not set scaling = 0; if ( current_speed[i] == 0 ) to avoid a divide by 0. Think of a circle, X & Y each hit 0 when the other axis is at its fastest speed causing shuddering and jerking when it's suddenly reduced to the slowest speed for no good reason. The old code that set s = FPDIV(max_speed_change[i], delta_v); and doesn't "break;" out of the loop works far better.

2nd best change I ever came up with in Sailfish... Here is my new number 1 change:

It prevents random speed up movements that ruin otherwise clean 3D prints.