Dual Extrusion Problems

[adcurtin]

I have a powerspec 3d pro (rebadged flashforge creator pro) running sailfish 7.7. I'm trying to do dual extrusion prints, but running into crazy problems.

It seems whenever the printer switches from toolhead 0 to toolhead 1, the printer thinks its current location is the location of the next move command, but it doesn't actually move there. (If I'm understanding the gcode commands correctly, it's almost like the printer is interpreting the first G1 command after M135 T1 as a G92 instead)

I've tried reflashing my printer, including completely reimaging it by uploading a new bootloader over ISP, then reuploading the firmware. same problem.

I've tried .x3gs I sliced and printed a long time ago that worked, now they don't. I've tried slicing new things, printing from .x3g on SD card, and from .gcode via octoprint and gpx. All of them exhibit this same problem.

changing the T1 extruder offset in the firmware had no effect. leaving it set at X = 0 and Y = 0 after the flash resulted in the same print as setting X=34 and Y=0 (via the onboard LCD) and printing again.

Here's a picture of a failed print: https://www.dropbox.com/s/7b7oeo0qx6kk7mk/2019-01-07%2000.33.39.jpg?dl=0

note the migration of the prime pillar.

I can post the gcode if it'll help. I also have a serial.log from octoprint.

I'm a little lost on what the problem could be here.

is there any logging sailfish does that I can enable?

void s3g_command_display(s3g_context_t *ctx, s3g_command_t *cmd)

{

     char buf[64];

     const char *fmt;

#define F(v) (cmd->t.v)

     switch(cmd->cmd_id)

     {

     …

     case HOST_CMD_WAIT_FOR_TOOL :

  writef(ctx, "Wait for tool %hhu, poll delay %hu ms, timeout %hu s",

F(wait_for_tool.index),

F(wait_for_tool.ping_delay),

F(wait_for_tool.timeout));

  break;

where does that writef go? anywhere I could see easily?

[adcurtin]

at this point, I think my next step is to modify the gcode for the test print, and either add some extra G1s or G92s, and see if that has any effect.

with gpx and octoprint, can I just send gcode to the printer? G1 X0 Y0 didn't seem to do anything, even when the extruder wasn't homed.

being able to manually run some gcode would probably help me figure out (at least a temporary) solution a bit easier.

[neoteric]

1. When you are reflashing the firmware, are you following the instructions in the sailfish manual to the letter, including setting your extruder offsets correctly?

2. I would recommend you ask the question here; https://groups.google.com/forum/#!forum/flashforge  it is a more active forum on the topic you are asking about.

[adcurtin]

yup, I've followed those procedures carefully (though, I initially upgraded to sailfish a long time ago and have no idea what the original offsets were). I can print single extruder just fine. And changing the toolhead offset has absolutely no effect whatsoever. I get the same result when I set the X offset to 0 and when I set the X offset to 34.

I'll try posting on the other forum.

I tried adding repeated G1s after the M135 T1s, which made no difference.

I tried adding G92s with a -34 offset, and again that had no effect.

I think my next step is going to be trying a completely different mainboard. I have a 1280 based mightyboard from a replicator 1, so hopefully it'll be close enough to a drop in replacement that I can test with that easily

[Michael Herron]

Admittedly haven’t carefully followed what you’ve done thus far, but GPX  needs these parameters also.  I’ve been bitten by similar issues (but not toolhead offset yet).

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

[Dan Newman]

> It seems whenever the printer switches from toolhead 0 to
> toolhead 1, the printer thinks its current location is the
> location of the next move command, but it doesn't actually move
> there.

Keep in mind that a tool head switch doesn't cause any motion in and
of itself. MakerBot, when they introduced dual extrusion decided
that the toolhead offset would be added to the next incoming G0/G1
command. Which means, in general, that the next move will be incorrect
if it requires motion in either the X or Y direction. E.g., instead
of moving from, say, (100, 100, 0) to (100, 200, 0) the printer might
move from (100, 100, 0) to (134, 201, 0) [assuming a toolhead offset
of (34, 1) and that a tool change command is issued while at
(100, 100, 0)]. Clearly the printer creates a line with the wrong
slope and travels too far (which causes the extrusion to be spread
out over a longer line).

Consequently, on MakerBot printers, when you do a tool change you
have to ensure that the next G0/G1 command merely moves in the Z
and/or E direction. Which is what Makerbot's slicers would then
ensure: retract filament in Tool 0, then switch tools, then do
the unretract in Tool 1, then resume the print. That unretract
of Tool 1 would then also effect that toolhead translation in X & Y.

Now this doesn't explain why old prints no longer work if they worked
before. Sailfish certainly hasn't changed how it does this: it has
always followed this MakerBot style of handling tool changes.

Dan

[adcurtin]

Consequently, on MakerBot printers, when you do a tool change you
have to ensure that the next G0/G1 command merely moves in the Z
and/or E direction.  Which is what Makerbot's slicers would then
ensure: retract filament in Tool 0, then switch tools, then do
the unretract in Tool 1, then resume the print.   That unretract
of Tool 1 would then also effect that toolhead translation in X & Y.

Oh, thank you for explaining this! what I read gave me the impression that I needed an X or Y move without extruding.

I'll try editing the gcode and switching the G1s I added to be T1 unretracts (which is thankfully a lot easier since I don't have to care about x y coordinates specific to each tool change location).


The old prints worked on sailfish even, and are x3g, so there should be no GPX in the loop. The only GPX settings in octoprint seem to be changing the EEPROM on the printer, and the printer profile says it doesn't affect sliced files (it's only used for slicing and for the gcode preview). I've also tried newly sliced prints from the SD card, and had the same problem.

Is there any reason not to erase the EEPROM? the menu says that could make my printer inoperable, is that just because it wipes the offsets?

 

[adcurtin]

I wiped the EEPROM, didn't fix it.

Here's what the dual nozzle calibration gcode print looks like: https://www.dropbox.com/s/1fhy8ewpcrs3yyf/2019-01-09%2017.29.48.jpg?dl=0

since that's sample gcode, and I printed with repg sailfish, that rules out a slicer problem, and rules out octoprint as the problem as well. my tooldhead offsets were both set to 0 for this.

I tried disabling p stop, and disconnecting that from the mainboard, no effect.

I think the next step is to try the makerbot mighyboard I have instead of the creatorboard. I think it should be a drop in replacement, I already updated the board to the latest sailfish (for rep1, since it's only a 1280). I might try the sailfish for flashforge creator I / II / X since afaik this printer is the creator X with a couple upgrades.

[adcurtin]

I swapped the mainboard. the other board has no problems with dual printing. (and both extruder offsets set to 0)

on the creatorboard, I even tried reflashing the 8u2, but that didn't make a difference (as expected, since SD dual printing had problems too).

My gut at this point is telling me a brown out or something messed up the mega2560, so I ordered another one and we'll see if that fixes it. I'm not really sure what else it could be at this point.

[Dan Newman]

If a new board works and the old doesn't, then it is wild theory
time. For example, maybe there was a bad digital potentiometer or
a stepper driver with an incorrect resistor on
the old board causing a bit too little current to the X or Y stepper
driver. Combine that with a fast retraction/unretraction speed
for filament. That could cause the resulting tool change motion --
effected as part of the retraction or unretraction -- to move a
little too fast and to stall that axis? But it would have to be
very consistent judging by your pictures.

The digipots are part of the main board. The stepper drivers you
can swap around to test. If you do swap stepper drivers, be sure
to always power the boards off first. And mind the orientation of
the stepper driver daughter cards: there's two ways they can be
plugged in but only one is correct and the other way can cause damage
to the electronics.

Dan

[adcurtin]

the printer doesn't even seem like it's trying to move when the shift happens. it starts printing with T1 so quickly there isn't time for it to have attempted a move. The bad board is very consistent. with the same file, it will print the same result every time.

I'll see about putting the bad mainboard back in and taking a video, since that can probably rule out a bit.

[adcurtin]

here's a video of the dual extrusion calibration print: https://photos.app.goo.gl/Ztt8LhBed5jRv8yG8

skip to 1:18, which is just before the tool change.

here's the resulting print (which I cancelled before it finished): https://photos.app.goo.gl/TBhsLd6LNPfBLGAX7

[Rich Webb]

The video helps and it's indeed weird. It not only fails to incorporate the T0 to T1 offset but it eats the travel move. Maybe Dan has an idea?

[adcurtin]

ok, so it's not the atmega2560. I swapped that, and got the same behavior. I also swapped all 5 of the stepper drivers from the other mainboard that printed dual just fine. still didn't fix it.

What are the digipots used for? Any other ideas what I should check?


If you check the video at 1:36, you can head the stepper for extruder 1 having some difficulties. This doesn't happen when I do a single extruder print with just that extruder. I think that might be a clue.

[Rich Webb]

Still weird. Weirder? The digipots (digitally controlled potentiometers) set Vref for the stepper driver chips. Vref in turn sets the max current limit for the driver. Might be worth checking those.

[adcurtin]

I sent G130 X20 Y20 Z20 A20 B20 to the printer and measure all VRs to be 0.4V. I sent G130 X127 Y127 Z40 A127 B127 to the printer and measured XYAB at 1.7V, and Z at 0.7V. They all seem to be working.