Jacotheron / FlashForge-CreatorPro2-PS-Profile

PrusaSlicer Profile for the FlashForge CreatorPro2 3D printer
20 stars 6 forks source link

Overacceleration/overspeed (left head) #3

Closed SmallWings7080 closed 1 year ago

SmallWings7080 commented 2 years ago

First, I would like to say thank you for your work. I can finally print with the slicer I use all the time. Regarding the problem: I cut into layers in the mode of only the left exture, everything goes well, the printer recognizes the file and starts printing. From this moment on, the problems begin, it seems to slip with too much acceleration or speed, because the printer begins to behave inappropriately at moments of travel, namely to move very quickly (it seems that the speed is 300+ mm/s) and thus the motor on axes Y and X begins to wedge. The right extruder works fine. The settings from the file were not changed. PrusaSlicer 2.4.2

Jacotheron commented 2 years ago

This is extremely weird that it would try to overspeed; the stock speeds programmed in, does not go above 50mm/s printing speed, and 130mm/s for travels (as can be seen in the Print Settings); most of these speeds were already defined when I got it from Frank - I mostly worked on the post processing stuff.

Can you perhaps place a sliced file in zip and upload here, for me to take a look?

Can you also confirm the firmware version of your printer?

I have actually started thinking on reducing the travel speed a bit, as my printer was making some noise traveling, but it is both heads, and not causing any issues (just being distracting, due to not having silent stepper drivers).

SmallWings7080 commented 2 years ago

This speeds work fine with the right head, but i don't know why, with the left at any speed I have troubles.

File added 18650.zip

Firmware version: V1.8 20210221

I replaced the driver the next day when the printer arrived :) Last week I installed a 12V power supply and 3 fans on the board, instead of a very noisy 24V + add a magnetic base. I am currently working on the cooling system, because after the "water" test, I realized that the models are not blown at all (I don't know how they designed it so that it blows into the opposite wall, and not at the model), which leads to overheating, surfacing, and bending :(

Jacotheron commented 2 years ago

I have the exact same version of firmware on mine; I checked the gcode, and the speeds are exactly what I would expect.

You mentioned you replaced the driver (which driver?), are you sure that the microstepping is correct? Based on what I know is stock, it uses 16x microstepping, so if you have for example only 8x or 4x you would reach double or quadruple the intended speed, respectively; and the distances will be off by quite a lot.

Some way you can perhaps check this, is halve all the speeds (including from the start gocde - see the F-parameter), and see if it works then, and what the actual distance is, vs what you expected. That may give an idea on what microstepping was used.

SmallWings7080 commented 2 years ago

Drivers, TMC2226, working fine almost a year. Distances all fine. Really, i don't know what causes this problem ;/ But tried one more time with another model, same result. If you printing and everything is fine than i must deeply look to my printer ;)

Jacotheron commented 2 years ago

Everything I slice works very well on mine, no issues.

Can you perhaps also do a test with the FlashPrint slicer, to confirm whether it also happens there (if it does not happen there, send the test file to me - then I can compare the 2 and see if somehow a binary value is incorrectly calculated).

If FlashPrint also fails, then it is obviously a hardware/firmware issue.

SmallWings7080 commented 2 years ago

Yes, I print with FlashPrint very often because I have to print 2 parts at the same time. I tested the printer for a whole day, it works on a flash print, Prusaslicer only has the right head.

Today I also found a problem, prusslicer does not work in duplicate mode. The left head rolls out to the m iddle, the sound of the internal beating of the motors, then the printer supposedly starts printing, but the sound of the beating of the extruder(both) motor and the filament is not squeezed out(both). Also, the distance from the table is very large.

Duplicate.zip

Jacotheron commented 2 years ago

It is really weird that the 2 slicers produce such difference in results.

I have compared the 2 gcodes you sent and in the header they are extremely similar (the differences are not what I would expect to make any issue - I am examining it with HxD, a hex editor so that I can see the value of each byte in the file):

  1. 0x28 -> according to a source I used, this value is used for the extruder mode, and I have it set to hardcoded values (3 is normal, 19 duplicate and 35 being mirror) based on what I got during my tests. PS have this as 19 (duplicate); FP have this as 17. It should not really be an issue (others have reported that they get a different number from FP, but it may have something to do with a few other settings).
  2. 0x1C -> this is the print time in seconds, as 4 bytes (obviously 2 different slicers will differ on how long it should take).
  3. 0x20 -> this is filament usage for right, followed by filament usage for left, as 4 bytes. In PS, the Left shows as 0, so this may be a small bug in my post processor (as with ditto and mirror, both should be the same); however I have printed many ditto/mirrors the past few months and no issue found.
  4. 0x36 -> left extruder temperature is here set as 0, which should be the same as right, may be part of same small bug, but should not affect speeds at all.
  5. 0x38 -> this is the binary bitmap image, which will obviously differ.

The print speeds are encoded at 0x30, and in both files are they 60 (mm/s). Thus it should not be an issue.

If you want to test on the Extruder Mode, which differs a bit, you can edit the "ff-creator-post-processor.py" script in your favourite text editor (I use Notepad++, but almost any would work, though line numbering makes it just a lot easier). You can then change the "19" on line 112 to "17".

When slicing it should then use the 17 for ditto mode, and you can see if that made any noticeable difference.