The trouble is, running it on my U1 that is not what is happening. Instead of selection sequence T0, T1, T2, T3, it is actually doing T2, T1, T2, T3!
I presume this is something to do with filament mapping locally within the U1 (no Orca/SnOrca involved, it is a G-Code file originally on a USB stick and now stored on the U1).
If this is not a specific “glitch” on my machine in particular, either the test file is inadequate or the instructions for using it are insufficient. Is there something I can do to override any mapping?
In case it proves to be relevant, I am running Paxx 1.4.1. I will try official 1.4.1 just to check…
Okay, official 1.4.1 made no difference. What cured it was Settings > Print Preferences > Filament Auto Mapping = OFF.
At first, I thought there is nothing in the G-Code to specify filaments, but after the actual G-Code there is a block titled “; CONFIG_BLOCK_START” (note the initial “;”, so the interpreter treats it as a comment). This block includes lines:
…so it wouldn’t surprise me if these are getting interpreted by the auto-mapping (what exactly is a 32-bit colour??).
Observations:
The toolhead gets picked up, and the part cooler fires up, then the toolhead is parked and the next one picked up. This is the same throughout the G-Code. If the pogo pins don’t make proper contact, the fan doesn’t start up. The toolhead is parked and then retried, but the failure of the fan to start somehow suppresses the fan on all subsequent actions for all toolheads.
I can see this happening on the control panel, the fan used to toggle between “OFF” and “ON”, and then stays “OFF” - even though there is no difference in the G-Code instructions. This may be a deliberate fall-back strategy, but I’m not keen on it.
At the end of the “print”, the toolhead swapper anomaly message IS NOT displayed, despite me being confident there were anomalies (and despite the message being displayed when anomalies occur in a real print). Without the message being displayed, there is no link to access the anomaly count for each head. The console (Fluidd) showed retries occurring.
I wonder whether the error report at the end is contingent on actually printing something. The test file only contains G4 (dwell) commands, not G1, so an “intelligent” warning system could decide the swapper anomalies had no impact on the actual print. If so, that makes the test file pretty well useless!
OK, I can follow up on this now. I have been in conversation with Support.
The toolhead ordering during the test file was because of Filament Auto Mapping. Turn that off (Settings > Print Preferences) and all is well – it goes T0, T1, T2, T3… instead of T2, T1, T2, T3…
This is a consequence of the filaments I had loaded in which head, and YMMV.
However, the test file has now been modified so that it is independent of the Filament Auto Mapping setting. T0, T1, T2, T3… ordering is forced.
Also, the test file has been modified so that the part fan no longer stops after the first pogo contact error.
It turns out that the anomaly detection is dependent on the fan running. A pogo pin contact error will result in the firmware re-attempting to pick up the head, and possibly fail and move on, and this will be seen in the Fluidd console log, but it only affects the part fan and if the part fan was not expected to run, even a failed retry is not logged as an anomaly.
This seems fine to me, the main problem (apart from the test file errors!) was that I didn’t understand the process.