[Feature] On FTP: Rebuild print_weight & print_length Attributes when error / integration restarts

[Lemonadel]

Describe the feature

Hello,
I was digging around idea if it's possible to get these Attributes especially after integration was restarted / updated mid print or first message given with print start was somehow missed, when using ftp_mode ( switch.PrinterName_load_model_data_from_printer == True ).

So, it looks like that in /Metadata/slice_info.config for each .3mf file there is - in each filament row - it's matching {color} and {type}.
It has to match existing External_Spool or AMS Tray(s) used for that current print and this knowledge can be used to get the match.

So in details:
The same {color} and filament {type} can be found in Attributes of AMS device Tray.
So two loops and correct Tray can be found for creating AMS Tray Attribute for [print_weight] and [print_length] ;)

one filament:

multifilament (sorry if hard to read):

Before the above, checking if Printer is using AMS_X or External_Spool can be done by looking:
if [sensor.PrinterName_active_tray_index]
is != 255 --> AMS is used
else --> External_Spool

so if [active_tray_index] is 255 then for sure this 1 filament row from <slice_info.config> is about External_Spool (which btw has also color and type Attributes - but these are not needed to be checked to get the match).
I don't think there is a possibility to slice with both AMS and External_Spool to be used - so it's easy check.

--Possible issue--
Only issue is when the same color and filament type is used in >=2 AMS slots (i.e. for Auto Refill).
Then sadly there could be mismatch and 1st tray match found could be used (not perfect but I think it's most of times used this way or write it as "Unknown Tray")...

But solution for that would be daemon / watcher looking if any of these not-sure-which-tray has Attribute {Active} == "true" - then correct one is found.
If any of these trays were not used during last integration work (i.e restart happened when these Trays were already used) - then is only situation when mismatch can happen (probably first match would be used again).
Edge issue case - someone somehow used >=2 the same color/type slots for different parts -> then there is no way to get it correct.
maybe for this issue solving the Attribute "Unknown Tray" can be used >=2 times?

--Summary--
Not sure if it's worth coding - but sharing the idea ;)
At least for me it would save time playing with additional entity to store previous values of last print in case of power loss / HA device restart / somehow integration fail ;)

Of course - I will be happy to test ;)

What device is this for?

AMS

Other Information

No response

[AdrianGarside]

This gets close but it's an imperfect solution. Maybe it's good enough as a fallback when the integration got restarted mid-print. I was, however, thinking of recording the filament remapping data as I observe it so I can keep using it across restarts. Including the start time since that's another thing we lose in lan mode (I back fill in Cloud mode via a cloud REST API). But that's also got a gap that the integration must be running at print start to observe the data and I need to find a good way to reliably associate it to the current print in case the integration wasn't running across a print start to avoid using data from the wrong print start for the new print.

[AdrianGarside]

Although print start I can infer from the 3mf model timestamp now...

[rsocko]

@Lemonadel - how are you getting the gcode and config data of the print? I wanted to look at ways to interpret the gcode for similar purposes.

[Lemonadel]

@Lemonadel - how are you getting the gcode and config data of the print? I wanted to look at ways to interpret the gcode for similar purposes.

Hey,
So it’s the following:

On MacOs:
(on Windows use WinSCP + WinZip/ 7zip etc)

1. Connect via FileZilla and connect via FTPs with following settings:
   IP of printer, port 990, “implicit FTP over TLS”,
   Login: bblp
   Password: access code from printer physical screen
2. Go to /cache folder and then look for interesting .3mf file
3. Download it on disk
4. Extract .3mf file contents via opening it in Unarchiver
5. Go to /Metadata folder in extracted file folder

Naturally steps 1-3 can be done by reading physical sd-card via card-reader as well

[AdrianGarside]

Looking at a test print I don't think there is enough information in the files to do this:

I printed a model set to filament 1 in the slicer (a blue) but remapped to filament 4 (black) as I printed.

slice_info.config has:

    <filament id="1" tray_info_idx="GFL96" type="PLA" color="#2850E0" used_m="8.01" used_g="23.90" />

project_settings.config has:

    "filament_colour": [
        "#2850E0",
        "#BB3D43",
        "#D4B1DD",
        "#161616"
    ],
    "filament_cost": [
        "20",
        "24.99",
        "20",
        "20"
    ],

plate_1.json has:

    "filament_colors": [
        "#2850E0"
    ],
    "filament_ids": [
        0
    ],

There's nothing that tracks that the blue print filament #1 (#2850E0) actually became the black filament #4 (#161616). That's why we currently must observe the transient ams remapping data in the mqtt payload - that is the only place that records the remapping.

Am I missing something about your examples where that isn't the case?

[rsocko]

@Lemonadel - how are you getting the gcode and config data of the print? I wanted to look at ways to interpret the gcode for similar purposes.

Hey, So it’s the following:

On MacOs: (on Windows use WinSCP + WinZip/ 7zip etc)

1. Connect via FileZilla and connect via FTPs with following settings:
   IP of printer, port 990, “implicit FTP over TLS”,
   Login: bblp
   Password: access code from printer physical screen
2. Go to /cache folder and then look for interesting .3mf file
3. Download it on disk
4. Extract .3mf file contents via opening it in Unarchiver
5. Go to /Metadata folder in extracted file folder

Naturally steps 1-3 can be done by reading physical sd-card via card-reader as well

thank you.

I got the impression from the more recent release notes that it was possible to extract the gcode in some way through the HA integration. Do you know if that's possible and how?

[AdrianGarside]

We download the 3mf from the printer but only currently to a temporary file and then it’s deleted. And we don’t currently extract the gcode file from it. What did you want to do with it?

[Lemonadel]

Looking at a test print I don't think there is enough information in the files to do this:

I printed a model set to filament 1 in the slicer (a blue) but remapped to filament 4 (black) as I printed.

slice_info.config has:

    <filament id="1" tray_info_idx="GFL96" type="PLA" color="#2850E0" used_m="8.01" used_g="23.90" />

project_settings.config has:

    "filament_colour": [
        "#2850E0",
        "#BB3D43",
        "#D4B1DD",
        "#161616"
    ],
    "filament_cost": [
        "20",
        "24.99",
        "20",
        "20"
    ],

plate_1.json has:

    "filament_colors": [
        "#2850E0"
    ],
    "filament_ids": [
        0
    ],

There's nothing that tracks that the blue print filament #1 (#2850E0) actually became the black filament #4 (#161616). That's why we currently must observe the transient ams remapping data in the mqtt payload - that is the only place that records the remapping.

Am I missing something about your examples where that isn't the case?

Good catch.
Actually I ran prints when AMS was already set up, which means - not played with switching filaments during print / after first one was printed and 2nd time the same is started.

For this case it could work but as you showed reality differs and if AMS slots changes since print was downloaded all this idea stopped being reliable.