Print mess, I don't understand

What is the problem?

Hi all,

I'm pretty new with Octoprint and the 3d printing in general.

I have a FlashForge Finder 2 printing very well with Simplify3d via USB. I have installed octoprint on a PI 3B, connected it to the printer via USB and WiFI to the LAN.

I'm using the curl script to send the file automagically to octopi. Everything seems to be good, until when it starts printing: the bed doesn't get to the correct height and the extruder push the filament in the air. Sometimes the Z is correct, but there's way too much filament. There are no g-codes in octoprint, simplify3d has the same one that works with the usb.

With Cura... it's even worse: it's completely off even on X and Y.

The printer profile seems to be configured correctly to me:

Is there any other setting I should change on octoprint? My understanding was that without any g-code configured it was acting as a bridge between the slicer and the printer.

Anyone can help me with this?

What did you already try to solve it?

Recreate the printer profile, follow the tutorial online to configure my Flashforge Finder.
To check it wasn't a known issue, I have even stalled the 1.6.0 RC3, but same problem.

Have you tried running in safe mode?

No. The issue happens even with no plug in installed

Additional information about your setup

Raspberry PI 3B, OctoPi image with both stable and 1.6.0 RC3

I have even stalled the 1.6.0 RC3, but same problem.

While this is most likely not the issue I just want to point out that if you intend on using a RC then you should be coming from a working installation.

Anyway, what would really help here are some logs, specifically serial logs. Grab those and post them as well as the gco file being printed.

Be sure to try printing the file after enabling serial logging.

Thanks. I have rolled back to the 1.5.3. I will add some logs asap

Have a look on this:

grafik

Rectangular heatbeds (Cartesian printers) have their origin in the lower left.
CIrcular heatbeds (Delta printers) have their origin in the center.

Don't mix up the origin/homing position with park position.

Some cartesian printers do their Z homing in the center (usually when they have an proximity sensor or a BLtouch), but X and Y are alyways homed at a corner.

1 Like

Ahh good catch there. Could be it.

Ok, so that's not the problem. I have done some more tests with Cura + Octoprint. Here's the video:

https://youtube.com/shorts/8gwwA3Bf9qY?feature=share

Cura G-Code (from Configuring Ultimaker Cura To Support the Flashforge Finder 3D Printer | Cracked the Code β€” Adventures in electronics, tinkering and retro computing.)

;start G code
;Machine set up
M104 S{material_print_temperature} T0 ; extruder temp
M107 ; fan off
G90 ; absolute positioning
G28 ; home
M132 X Y Z A B; load axis offsets from eeprom
G1 Z50.00 F400 ; Lower bed
G161 X Y F3300 ; home x and y to min
M6 T0 ; select tool 0
M907 X100 Y100 Z40 A80 B20 ; Set motor voltages
M108 T0 ; Tool 0

;Nozzle purge move
G1 X-70 Y-70 Z0.3 ;Move to bottom left
G1 X70 E20 F1500 ; Extrude across bed
G1 Y-69.6 ; Move up 0.4
G1 X-40 E20 F1500 ; part way back extruding
G1 X-70 F2000 ; Drain nozzle
G1 Z5 ; lift head
;Main G Code Here

OctoPrint:

Here's the logs

octoprint.log (1.4 MB)

To be consistent, I've tried to remove the "Origin at center" even from Cura, here's the result:

https://youtube.com/shorts/XuNVVVdL688?feature=share

I had to manual shut down the printer to avoid damages

Ye you got the same stuff like me happening.

So long nobody digs deep into the firmware and alters the G-codes for Flashforge, it will never Print directly from Octoprint.

Mrnt on Github did alot, but he said he is missing alot of g-codes where the finder doesnt respond on.