drlex0 / ffcp-gcodesnippets Goto Github PK

Hi, so I just got a FF Creator Pro with dual extruders, and I'm trying to use PrusaSlicer with it for its painting functionality.
I am fairly certain that I followed the instructions exactly, but upon exporting a GCode, there is no X3G file being created alongside it. The debug file and the momentary popup after exporting both say everything is functioning, but I am not getting an X3G file out of it.

I'm sure it's because I am not as hardcore code savvy as most 3D printer enthusiasts are, so I'm sorry ahead of time if it's something stupid.

Windows 10
PrusaSlicer 2.5.0
GPX 2.6.8
Strawberry 5.32.1.1

Everything is freshly installed, literally. I just built this PC 2 days ago for use with 3D stuff.

bunnytest.zip

This line in start_gcode seems to move the print outside of the printable area:

G92 X118 Y72.5 Z0 E0 B0; set (rough) reference point (also set E and B to make GPX happy). This will be overridden by the M132 below but ensures correct visualisation in some programs.

Alpha1 is fine, so it might be related to: prusa3d/PrusaSlicer#6996 but are we ok to remove that line (noticed the reference to GPX)? Even 2.3.3 gcode displays as off to the bottom left in prusa-gcodeviewer 2.4

Also, the x3g file isn't being moved to the final target, its staying in /tmp/, which looks like prusa3d/PrusaSlicer#6952

My workaround is to give make_fcp_x3g.pl a path to pass to gpx based on the new SLIC3R_PP_OUTPUT_NAME environment variable:

333,334c333,340
< 	print "Executing: ${gpx_esc} ${arg_p} -m \"${MACHINE}\" ${in_esc}\n" if($verbose);
< 	my $gpx_out = qx(${gpx_esc} ${arg_p} -m "${MACHINE}" ${in_esc} 2>&1);
---
> 	my $out_esc;
> 	if ($ENV{'SLIC3R_PP_OUTPUT_NAME'}) {
> 		$out_esc = $ENV{'SLIC3R_PP_OUTPUT_NAME'};
> 		$out_esc =~ s/\.gcode$/\.x3g/g;
> 		$out_esc = shellEscape($out_esc);
> 	}
> 	print "Executing: ${gpx_esc} ${arg_p} -m \"${MACHINE}\" ${in_esc} ${out_esc}\n" if($verbose);
> 	my $gpx_out = qx(${gpx_esc} ${arg_p} -m "${MACHINE}" ${in_esc} ${out_esc} 2>&1);

Which is akin to the hacks suggested in prusa3d/PrusaSlicer#6042 which is a change that makes no sense to me (or others!)

2.4.0a2 output:

[2021-09-25 20:42:53.379256] [0x00007f3c94ff4640] [error]   GCodeProcessor encountered an invalid toolchange, maybe from a custom gcode.
Highest Z coordinate found: 150
Fixing incorrect M104 command for single-extrusion setup
Ensuring correct display in gcode.ws
Running retraction script...
Executing: "/usr/local/bin/retraction-improver.pl" -o "/tmp/LnDay2lQQu" "/tmp/.108708.gcode.pp"
Invoking GPX...
Executing: "/usr/bin/gpx" -p -m "fcp" "/tmp/.108708.gcode.pp" "/home/simon/PinHeaderSnappingJig.x3g"

2.3.3 output:

Highest Z coordinate found: 150
Fixing incorrect M104 command for single-extrusion setup
Ensuring correct display in gcode.ws
Running retraction script...
Executing: "/usr/local/bin/retraction-improver.pl" -o "/tmp/GypogpiayX" "/home/simon/233.gcode"
Invoking GPX...
Executing: "/usr/bin/gpx" -p -m "fcp" "/home/simon/233.gcode" 

I’m printing ABS, using the left nozzle only. Without a brim, this works fine. But when I add a brim, after the first layer is done, it starts heating up the right nozzle as well, which of course is undesirable. It continues to print with the left nozzle though.

I’m using PrusaSlicer, latest version, curious if this is an issue with the slicer or the G-Code configs?

Thanks!

— Leif

I owe you my sanity. I imported a release from 2018 into Slic3r, and my ASA started working and my PLA stopped collapsing. A vast feeling of relaxation ensued.

Just tried the updated gcode snippets on 1.41.3 (don't like 1.42beta2 at all!) and the start gcode seems quite odd.

It does the wipe and tear at the front left as usual but then proceeds to move the nozzle to the back of the bed and drop the bed and reheat the nozzle from 140 again, then do the homing and wipe again.

Assume that's not expected behaviour, although the gcode seems to show it:

T0; start with the right extruder. We will switch to T1 after having moved the print head to provide enough space for the nozzle offset.
M73 P0; enable show build progress
M140 S65; heat bed up to first layer temperature
M104 S140 T1; preheat nozzle to 140 degrees, this should not cause oozing
M127; disable fan
G21; set units to mm
M320; acceleration enabled for all commands that follow
G162 X Y F8400; home XY axes maximum
G161 Z F1500; roughly home Z axis minimum
G92 X118 Y72.5 Z0 E0 B0; set (rough) reference point (also set E and B to make GPX happy). This will be overridden by the M132 below but ensures correct visualisation in some programs.
G1 Z5 F1500; move the bed down again
G4 P0; Wait for command to finish
G161 Z F100; accurately home Z axis minimum

A diff of the new start gcode on 142beta2 vs the old gcode on 141.3 doesn't show much difference, but there are different hyphens and left/right differences (did i paste the right gcode instead of left?)

System: MacOS Catalina

Hi, after upgrading my Mac to Catalina, the files in /bin got automatically moved or deleted. Therefore I re-downloaded the latest version of the make_fcp_x3g script. I didn't upgrade the rest as other scripts seem to not have been modified since my installation (my gCode configs are around 8-9 months old)

The conversion script runs fine, but after laying the first 2-3 layers correctly, FCP starts offsetting by around 2-3mm at each new layer, each time on -Y axis, moving towards the front of the printer, until the head starts bashing against the front panel.

I wonder if there might be a bug in the updated script, or did I miss something?

make_fcp_x3g wrapper script seems to use \d instead of [0-9] for digits which errors with:

WARNING: could not find highest Z coordinate. If this is a valid G-code file, the make_fcp_x3g script needs updating.

The fix is (PR seemed like overkill):

diff --git a/make_fcp_x3g b/make_fcp_x3g
index 108d41a..6bc219e 100755
--- a/make_fcp_x3g
+++ b/make_fcp_x3g
@@ -267,7 +267,7 @@ function get_highest_z
       # Extract highest Z value in a G1 command from the last 2048 lines of a file.
       local gcode=$1

-       tail -n 2048 "${gcode}" | grep -oE '^G1 [^;]*Z\d*\.?\d+' | \
+       tail -n 2048 "${gcode}" | grep -oE '^G1 [^;]*Z[0-9]*\.?[0-9]+' | \
           awk '{print $2}' | cut -b 2- | sort -g | tail -n 1
}

Hey Dr Lex!

First off, big fan of your work and dedication to this project, absolutely amazing stuff!

I'm having an issues with both single tool 0 profiles (FFCP Single Material Left and Left Flex).

After slicing in PrusaSlicer, post processing in Perl and sending the GCode to OctoPrint, the file starts printing with no issues until it puts the first layer down and then Tool 0 sets itself to the Filament 'Other Layers' temp. Every time I print I need to turn Tool 0 heat to off.

I have looked through the GCode and Perl script but am unable to figure out why this is happening.

Attached are my print settings, GCode and project file.The perl script remains unchanged.

OS and the version of PrusaSlicer:
Windows 10 (build 20221) & PrusaSlicer 2.2.0

The version of your GPX binary:
2.6.5

The version of your Perl runtime:
Strawberry Perl (64-bit) 5.32.0.1-64bit

Profile Files and GCode.zip

• Import STL into PrusaSlicer
• Slice
• Send to Octoprint
• Print
• Layer 1 complete - Extruder T0 sets to 'Other Layers' heat of the selected filament profile.

The WSL path conversion doesn't seem to handle spaces in the user account path. C:\Users\Some Name becomes /mnt/c/Users/Some, which fails.

GPX version 2.6.7, OS: Ubuntu 16.04, PrusaSlicer version 2.2.0

Hi DrLex0,

I'm trying to use the script to automatically convert the g-code file to x3g file. I have turned debug setting on and it says I did not give it permission to be executable, but I think I did that..

Can you help me double check if I am missing anything?

gcode2x3g.zip

Just a heads up - I'm not sure if this will apply to newer versions of Slic3r or PrusaSlicer, but with the SuperSlicer fork, the First layer height cannot be larger than the Base layer height in Slicing configuration under Print Settings. Here's the details: supermerill/SuperSlicer#2060

See PrusaSlicer issues 6336, 5073.
Thank God I moved to relative E long ago. Otherwise this would have broken pretty much all the post-processing scripts. Now it should suffice to just add a G92 E0 command to layer change code.

There's a model of the FFCP build plate on https://www.thingiverse.com/thing:3772642

This file can be loaded into the PrusaSlicer using the "bed shape" setting

The results are quite nice, though the file appears to be too far back by a few mm

Still a nice way to visualize the print within the printer.

I use your brackets for my glass bed and have the front one on the right hand side.

When using your gcode with ABS (right extruder) the ooze/wipe/loop doesn't work so well as I guess it interferes with the bracket.

How do I change the gcode to always use the left side for that (like PLA)? I can't see much difference between the left/right extruder gcode for the ooze/wipe, other than hyphens (e.g. X70 vs X-70):

149c145
< G1 X70 Y-74 F4000; chop off any ooze on the front of the bed
---
> G1 X-70 Y-74 F4000; chop off any ooze on the front of the bed
151c147
< G1 X-121 E24 F2000; extrude a line of filament across the front edge of the bed (3mm from the front edge)
---
> G1 X121 E24 F2000; extrude a line of filament across the front edge of the bed
154,156c150,152
< G1 X-108 Y-74 F4000; cross the extruded line to close the loop
< G1 X-100 F4000; wipe across the line (X direction)
< G1 X-90 Y-79 F6000; Move back for an additional wipe (Y direction)
---
> G1 X108 Y-74 F4000; cross the extruded line to close the loop
> G1 X100 F4000; wipe across the line (X direction)
> G1 X90 Y-79 F6000; Move back for an additional wipe (Y direction)
160c156

Was hoping you might have an answer, but when using your presets, and trying to print some PLA at 205 degrees, it seems to send it to the FFCP with a target of 140 degrees. If I monitor the FFCP via Octoprint using a normal print (.x3g) it reports the correct temperature. So, something is going wrong here, even though the Filament settings shows a target of 205 in Slic3r.

Any ideas ?

Describe the bug

Provide a clear and concise description of the bug here.
Using SuperSlicer with "import PrusaSlicer bundle" method, slicing fails with unknown variable error
Parsing error at line 98: Variable does not exist ;cooling enabled = [cooling] ^
Environment
Garuda Linux, using superslicer-prerelease-bin from the aur., Using latest gpx via aur and git, perl version 5.36.0
Include the following things:

• Your OS and the version of PrusaSlicer the issue is encountered with.
  Mind that bugs with alpha releases of PrusaSlicer should probably not be filed. Wait at least until the next beta release.
• The version of your GPX binary (try gpx -?)
• The version of your Perl runtime (try perl --version), and if Windows, what kind of runtime (Strawberry Perl, Cygwin, or through WSL).

To Reproduce
Slice Anything. Error pops up on Dualstrusion setup, other setups produce absolutely nothing.
By far the most useful thing you can provide, is a PrusaSlicer project file (3MF) that demonstrates the problem: use “Save Project” in the File menu. If possible, also include both the final .gcode and .x3g files. You can package everything into one ZIP file.

• If specific steps are required to reproduce the behavior, list them here.

Describe the bug

Expect: .x3g output
Actual: no .x3g, have follow the troubleshooting but no luck. The -c check output still ok.

Environment

• System: MacOS Sonoma 14.3
• Slicer: prusaSlicer 2.7.1+MacOS-arm64
• GPX: GPX 2.6.8
• Perl: perl 5, version 30, subversion 3 (v5.30.3)
  The actual result has packed into zip file, no FAIL file.
  https://drive.google.com/file/d/1ietsh5570Y8XoQlyOg14rv20wMBtxvsA/view?usp=sharing

Describe the bug

When printing with the 'FFCP single material L' printer profile, the print is shifted to the right along the X-axis and is not centered on the build plate.

Environment

• Your OS and the version of PrusaSlicer the issue is encountered with.

Arch Linux, with PrusaSlicer v2.1.0

• The version of your GPX binary (try gpx -?)

gpx 2.5.3 (from git master branch)

• The version of your Perl runtime (try perl --version, obviously not needed if you are not using the Perl-based post-processing scripts).

v5.3.0

To Reproduce

Please attach the project file (3MF) that demonstrates the problem and if possible, a ZIP with both the final .gcode and .x3g files.
jerker_cable_clip.zip

• If specific steps are required to reproduce the behavior, list them here.

I opened the attached stl in Prusa Slicer, made no changes to the position or rotation, sliced, exported gcode (including conversion to x3g with your script) and printed. The print was offset from the center of the bed. For a small print like the included example, this is not a problem, but for larger prints this is a major problem.

Describe the bug

Small part taking 45.5 hours and using 13.8km filament

Environment

Windows 10, Slic3r 1.3.0, GpxUi v2.5.2

To Reproduce

Slicing included stl using the Right nozzle Start code found here results in the gcode (Does not work.gcode) is estimated to take 45 hours and take 13.8km of filament.
slicing using the starting gcode here https://3duniverse.org/2014/01/05/using-slic3r-flashforge-creator/ (Surger Bobbin Holder v6.gcode)is estimated to take 60 min and use 2.12m of filament, but an error is thrown

(line 146) warning G92 emulation unable to determine all coordinates to set via x3g:140 set extended position
current position defined as X:0.00 Y:0.00 Z:0.00 A:0.00 B:0.00
(line 146) warning G92 emulation unable to determine all coordinates to set via x3g:140 set extended position
current position defined as X:0.00 Y:0.00 Z:0.00 A:0.00 B:0.00

slicing with Flashprint gives an estimated print time of 42 min and also uses 2.11 m of filament (Flashprint.x3g)

if you also know why both gcode > x3g files open in flashprint showing they are centered on the corner of the bed and so would largely print off the bed of range of motion allows, I would apricate that but that is not the issue at hand

Tests.zip

Description

Since PrusaSlicer 2.4.0 there is a new bridging method, similar to other slicers. See description in the PrusaSlicer 2.4.0-alpha1 release notes. By using older configs in 2.4.0 thick_bridges are enabled by default, which is the old Slic3r behavior.

I had great success using the new bridging method with PLA by disabling thick_bridges in the settings.
I propose to disable thick_bridges at least for PLA configs.

Environment

I am using an unmodified Flashforge Creator Pro.

Hi,
I´ve already been browsing around PrusaSlicer forums for help on this issue but I`ve found nothing so far, so I assume something is wrong in the .bat file for the postprocessing script.
Whenever I´m trying to export G-Code PrusaSlicer gives me this error message

Post-processing script C:\Users\david\Downloads\FFCP-GCodeSnippets-master\slic3r_postprocess.bat on file C:\Users\david\OneDrive\Desktop\3DProjects\Buchse.gcode failed.
Error code: 1

Greetings