2 Commits

Include renames

Author	SHA1	Message	Date
maziggy	3954d3a7e6	Choose which rack nozzle each filament prints from on an H2C (#1784) ... The Vortek rack holds six hotends, and a multi-colour plate is sliced to use a different one per colour so it can skip the purge. Which of the six each colour takes is not in the 3MF. The same plate, sliced and sent twice from Bambu Studio with a different choice each time, produces two files that differ only in rounding in the last digit of a few extrusion figures -- the filament grouping, the toolchange stream, the 120 nozzle-change markers and project_settings.config are all identical. The choice travels only in the dispatched nozzle_mapping. Bambuddy had no way to state it, so those plates went out with no nozzle assignment at all and the printer chose for itself. That is what levelled on one hotend and printed with another, millimetres above the plate. Every rack-bound filament now carries a position picker beside its AMS slot dropdown, listing all six with the nozzle each holds. An empty position, or one holding the wrong diameter or flow type, is shown greyed out with the reason rather than hidden, so someone looking for position 4 finds it. The choice is per filament *group* rather than per slot, because a group is one hotend: two filaments the slicer grouped together share it and cannot point at different positions. Nothing has to be picked. Positions are assigned automatically, preferring one already loaded with that colour, which on the plate this was built against reproduces Bambu Studio's own pick exactly. A nozzle currently picked up onto the carriage is offered too. The firmware drops its rack position from the report entirely rather than sending a placeholder (#943), and refusing it would rule out the position most likely to be wanted -- the one the last print left mounted. Only recoverable when exactly one position is missing; two gaps are genuinely ambiguous and stay unavailable. Positions are re-checked at dispatch, not just when queued, because the rack can be re-loaded in between. The two failure modes differ on purpose: an explicitly chosen position that no longer fits stops the print, names what the position now holds, and deletes the uploaded file from the SD card so it cannot be started by hand either -- an operator who named a hotend must not silently get a different one. An automatic assignment that cannot be made instead falls back to letting the firmware choose, which is what happened before any of this existed. The pick is stored as {group: position} rather than as the expanded nozzle_mapping, though that is what goes on the wire. That column means "Bambu Studio decided, forward verbatim", and only the group-and-position form can be re-checked against what is actually mounted at dispatch. The existing multi-rack refusal in extract_nozzle_mapping_from_3mf stays. It still guards the #2800 fallback, which can only ever name one rack id. Measured on the maintainer's H2C: rack position n is physical nozzle id 15 + n, confirmed by cross-referencing two captured dispatches against Bambu Studio's own dialog. extruder_max_nozzle_count names which carriage is the rack straight from the file, and is read rather than assumed -- a fourth independent confirmation of the carriage indices fixed in 45dc139. The print dialog is also wider, on every printer. Its filament rows carry the most horizontal content in it and adding a picker truncated names to "Bamb...". The column widths themselves only change on a rack machine. Tests: 44 unit covering the plan, the resolver, the mounted-nozzle recovery and every refusal; 9 dispatch integration asserting the two real captures end to end; 7 API round-trip; 33 frontend. The API ones exist because two integration bugs got through a green suite that tested the pieces and not the seams -- the group data reached only one of the three filament-requirements routes, and the field was declared on every schema except the create one, where Pydantic dropped it in silence.	2026-08-14 11:27:50 +02:00
maziggy	71a06f3638	Add batch orders with a quantity per plate (#342) ... Printing a multi-plate file in different quantities per plate meant queueing each plate separately and tracking the counts by hand: one shared Quantity field cannot say "plate 1 once, plate 2 twice, plate 3 three times". Each selected plate now carries its own quantity, and the submission becomes an order on a new Batches tab. The point is the distinction the old flat batch could not express. print_batch_plates stores how many runs of each plate were wanted, separately from what was queued, so a run that fails, is cancelled or is skipped does not satisfy a target -- the order goes on saying it owes a print instead of quietly under-delivering. Queue remaining re-queues exactly what is missing, for the whole order or one plate, by cloning the most recent item for that plate: that inherits the printer or model target, AMS mapping, filament overrides and print options along with the validation they already passed, rather than re-serialising twenty fields through a template that would drift from the model the first time someone adds a column. Clones append to the end of the relevant printer's queue and take the same advisory lock the add-to-queue route does; positions are per-printer sequences, not global. Cost is measured, not estimated. print_log_entries gains queue_item_id, set where the queue item is already in scope, so each run's material and energy are attributed through the item that produced them -- an unrelated reprint of the same archive never lands in an order's total, and a multi-plate order gets each plate's own cost rather than the whole file's via the plate-scoped estimate from #2614. Before any run has completed there is no honest figure, so cost reads as unknown instead of a fabricated 0.00. The Batches tab wires up GET /queue/batches, which has been unreferenced since the batch MVP shipped, along with six locale keys that were translated and never used. It is a separate tab because an order outlives the queue that produced it: once its runs finish they leave the active queue, so Queue and History each hold half the picture. completed was not a reachable status before now, so every batch created since April is still marked active however long ago its last print finished -- 73 of them on the development install. A startup pass closes out the finished ones: those whose runs all completed become completed, and groupings whose items were all cancelled become cancelled, which is what they are. Not applied to orders, which state their intent independently of their runs and still owe the work. Only batches with nothing queued or printing are considered, and repeating the pass also catches an order whose last run landed while the process was down. Batches with neither items nor targets are no longer listed at all -- empty shells left when a grouping's items went with their source archive. Dispatch applies the same source-file gates as POST /queue/. It creates queue items, so without them it would be a weaker door to the same outcome; the archive and library-file checks move into shared helpers so a third route cannot drift from them.	2026-08-04 11:11:36 +02:00