Python errors: NameError: name 'false' is not defined

[vin750]

I am having issues with the python code, it seems the version of python I downloaded is being picky about how true, false and null values are declared.

Have you seen this before?

I tried changing the code and replacing the false with False, true with True and null with None but it doesn't seem to have worked. I open the gx file in flashprint to push it to the printer via USB but it doesnt show anything at all. The file has data, but it is not making sense to flashprint. See an example below.

    "allShortcutsEnabled": false,
                           ^^^^^
NameError: name 'false' is not defined. Did you mean: 'False'?

I am running Python

python -V
Python 3.12.1

[Jacotheron]

I have just upgraded my Python to v3.12.1, same as you to test it; After installing both dependancies, and running it I got 2 warnings (which I have fixed; it is an Syntax warning related to escaping within the regex lines).

With these lines fixed, I get no further errors.

There are also only 4 lines that contain "False" in the script (lines 29 through 32), and all of them define it as "False"; I was also unable to find any "allShortcutsEnabled" within the script. I am wondering if another script or something is interfering.

If you bypass the post-processor (for example commenting out that line), the resulting file should be a simple Gcode file. While the printer should be able to print it, it will only work in normal mode (dual extruder is possible with issues, but no ditto or mirror mode).

[vin750]

Thanks for replying, I downloaded your code again and worked flawlessly. Thanks again for sharing it.

I am doing some testing here with Prusaslicer to see if I can get better results than what I was getting with Flashprint, at the very least I will be able address the heat spots I get on small pointy areas of prints that lead to these areas overheating and deforming.

Right now I am using Flashprint only to push my gcode to the FFCP2 and since I can't use Octoprint reliably with it, I use a USB over IP bridge so the printer doesn't have to be next to me and I dont need to move the files with the sdcard.

What I ultimately would like to do is to port your setup to Orcaslicer, there a script that moves Prusaslicer settings to Orcaslicer and if your script works with it then I will have an even more versatile setup. Have you tried to use Orcaslicer?

[Jacotheron]

I have not used OrcaSlicer before, but I understand that it is based on PrusaSlicer, so perhaps it may work with little changes.

The Vendor file is mostly the setting you see in the interface, converted into a .ini file syntax (so all lowercase and no spaces), so it should be easy to see what to change (if it needs changing).

The Post Processor script is simply executed on the gcode output from the slicer, so it should work on most slicers; though it may need a couple of changes. All of the information the script processes are fetched using Regular Expressions (you can see them as the "re.compile" parts of the script) - so in order to use them, just ensure your slicer outputs the correct expression, or modify these lines to match the expression (Line 23-52).

The code is released under the MIT license, so you are welcome to fork the code, and make changes to get it compatible with Orca.

Personally I get good results with this profile. Something I do miss from the FlashPrint is the dual color shield - currently SP only does skirt (so sometimes the part is far away from the skirt, and it droops out of the nozzle while traveling). Though I have 5 printers, all of which have good profiles on SP, so I am not looking to migrate at this time.

Something I have done previously when there is small detail that easily overheat (for example small diameter layers, that print in no time), is to add a Box shape, where I set the X and Y size to for example 8mm, and the height up to where it is needed. This tower is thrown away afterwards, but due to the printer needing to move over to it, print its layer end then return, it gives enough time for the actual print's layers to cool sufficiently to not look weird. Ideally we would have better cooling on the printer, but this is a workaround. You can change this box's print settings to be different from the actual print (saving time, and material).

[vin750]

Thanks for the idea on managing heat spots, I have done something similar by printing multiple of the same model so the extruder has to travel more and there is more time for the layer to cool down but that is not possible when you print large models that have pointy parts at the top and the layer becomes smaller and smaller but the bed is fully occupied already.

I think prusaslicer has a dynamic cooling option that handles there, I am sure orca does even better.

I have tried with a script that someone wrote but there are issues understanding the Prusaslicer profile from you. I am not sure what the issues are yet but I will dive into this. In short if I can setup any kind of profile in orca that works and then use your script to post process it, that will be good enough.

See below.

https://github.com/theophile/SuperSlicer_to_Orca_scripts/

I will keep you posted.

[vin750]

Thanks again for your help, i have managed to import everything you did into Orca Slicer and it seems ok although I haven't printed anything yet.

I have another questions for you, if you can help. In Orca we only have Marlin and Klipper as options to create custom printers, inside the printer configuration I can choose the gcode flavour. What do you think would be more compatible to the FFCP2?

I see you used RepRap in your configs. Would you know how these would differ?

[Jacotheron]

So the flavor of Gcode can differ, and given your options, I would try the Marlin 2 flavor.

Typically the commands that start with G, are mostly the same, however some firmware may implement a different subset of these.
More commonly the commands that start with M, are where it will differ.

For a potential list (not up to date), you can see the differences at https://reprap.org/wiki/G-code

For this, I don't think it would cause issues, but generally the Marlin flavor is the "safe" option.

With Orca not having RepRap, I probably will wait for it before trying to migrate (4 of my 6 machines run RepRapFirmware, and all 5 of the 6 can be sliced in PrusaSlicer; only the CNC machine is handled elsewhere).

[vin750]

Thanks for the info.

This is weird because even though Orca does not support custom Reprap printers, it does support Reprap gcode flavour. So I am not sure how much difference this would make in the end.

I have been exploring how to use Orca and I have made progress. I have now added your post processing script and it seems to have worked too, although I haven't printed anything yet.

What I am trying to figure our now is how your script works, how does it know what gcode to add based on what extruder I am using or if I am using mirror or ditto modes? What does it change in the gcode to make it work batter with the FFCP2? Do I need to somehow pass any parameters to it?

I have tried to read the python code but I clearly didn't make much progress with that.

[Jacotheron]

The script is mostly tasked with generating the binary header that the printer want. It does not change actual g-code, since I did not want to go into the rabbit-hole of keeping gcode consistent after changing a few things (Just decided G-code generation is best left to slicers).

The binary header contains the image that should be displayed, by the printer when we select the file; which nozzles are used; whether we are in standard, ditto or mirror modes; printing time; filament usage; nozzle temperatures; layer heights; perimeters; printing speed; bed temperature.

The post-processor gets the g-code file, from a temporary location as direct input (which is why we have the "import fileinput" line).
The other libraries we use are:

1. re -> regular expressions, this is how we parse the file, to get the important settings from the file, so we can build the header.
2. sys -> how we read and write the file.
3. base64 -> we need to decode the base64 encoded thumbnail
4. io, BytesIO -> another step in handling the thumbnail
5. PIL, Image -> the converter we use to convert the PNG image (from PrusaSlicer) to Bitmap (BMP) binary so that this printer can understand it.
6. struct -> to define binary structures for the header
7. os -> for percentage information while processing

As you can see from the top of the processor file, we start with defining a couple of variables as well as regular expressions that we will attempt to match in the file.

Active extruders look for an M6 T<N> command ( being a number usually 0 or 1)
Printing Mode looks for M109 T<N> command (T2 being ditto; T1 being mirror)

The above g-code is inserted as Starting G-code - so it is already in the g-code and we simply have to find it, and add it to the binary header for them to do their job.

From line 107, we loop through each line, and we match the settings, and update the variables as needed. From 283, we start building the header.; after which we write the file (including all the gcode we received). After we close the file, the temporary file is moved to its final destination by the slicer.

The only place we change a gcode command directly, is replacing it with the "Cal-Pad" (for ditto/mirror), and then we ensure it is placed back. The Cal-Pad (line 327 -> 1011) is meant as optional calibration pad (like a raft) that the printer will decide to use, if the nozzles have different z-offsets. In their firmware, these are generated below the parts; since PS does not know how to generate this, I copied/pasted a simple one. For best results ensure your nozzles are level and does not need such a cal-pad (as this one will not work).

I noticed I have made a list of the g-codes used by the printer, that are non-standard. It can be seen on the Readme file at https://github.com/Jacotheron/FlashForge-CreatorPro2-PS-Profile#g-codes

[vin750]

Thank you very much again for your in-depth reply. I am making progress here.

With regards to the last paragraph about the two extruders having different Z offsets, that is a very tricky one because I never never been able to make them have the exact same Z offset. Maybe when the printer was new but after the first issue I had with a PTFE tube and had to take the extruder apart to to unclog it, it was never exactly the same again. Though now that I use a dial micrometer gage to level the bed and I use a flexible PEI bed that is super flat, I can get them within 0.02mm which is good enough in my opinion.

[Jacotheron]

Yes, that is tricky to get them exact, but exact is not required, and your value is completely fine. The printer have a maximum deviation value, which if exceeded between the 2 nozzles, will trigger the CalPad to be printed. I would think that it would be around 30-50% of layer height (since that would be where layer adhesion will become poor). I would expect the printer to level based on the lowest nozzle, to not scrape the bed, so the higher nozzle would have to print at greater than expected layer height.

So for someone testing this profile/post processor, if their printer starts printing the calpad, then they can know that their offset is more than the maximum deviation allowed.

A possible way to remedy such a situation, could be to use a shim to raise the lower nozzle (the shim going into the bracket holder that head; when we got the printer, the heads needed to be installed, this is where I propose). Since we are talking factions of mm, such a shim would also be very thin.