Ein Sprachmodell kann ZPL schreiben. Zeichnen kann es das nicht — im Chatfenster steckt kein Renderer, also sieht das Modell nicht, ob das eben geschriebene Etikett leer ist, sich überlagert oder halb neben dem Medium liegt. "KI-ZPL-Rendering" ist deshalb kein Schritt, sondern eine Schleife: Das Modell schreibt den Code, ein Renderer macht daraus ein Bild und eine Liste von Befunden, und diese Befunde gehen zurück an das Modell.
Die Schleife braucht genau das eine, was dem Modell fehlt: einen Aufruf, der ein Bild und die mitgelieferten Warnungen zurückgibt. Das ist eine einfache HTTP-Anfrage — aus einem Agenten, einem Skript oder einem Notebook.
curl -X POST "https://labelixa.com/v1/printers/8dpmm/labels/4x6/0/" \
-H "Content-Type: text/plain" \
--data-binary $'^XA\n^FO50,50^A0N,40,40^FDLabelixa^FS\n^FO50,120^BY2^BCN,80,Y,N,N^FD1234567890^FS\n^XZ' \
-o label.png -D -Brauchbar für ein Modell wird die Antwort nicht durch das Bild, sondern durch die Befunde daneben. Eine Warnung, die den übersprungenen Befehl benennt, ist etwas, woran ein Modell arbeiten kann; ein Bild allein nicht.
| Header | Was er aussagt |
|---|---|
Content-Type | Standardmäßig image/png; für PDF Accept: application/pdf senden. |
X-Warnings | Nur vorhanden, wenn der Renderer etwas übersprungen oder nicht vollständig gezeichnet hat — ein unbekannter Befehl, ein Feld außerhalb des Etiketts. |
X-Total-Count | Wie viele Etiketten der eingereichte Code erzeugt; ein Index wählt eines davon aus. |
X-Plan | Der Tarif, dem die Anfrage angerechnet wurde — bei einem anonymen Aufruf free. |
X-RateLimit-Remaining | Verbleibende Renderings im aktuellen Zeitfenster. |
Anonymer Agentenverkehr wird dem Tarif free angerechnet und pro IP begrenzt — genug, um eine Schleife auszuprobieren, zu wenig, um sie produktiv zu betreiben. Ein API-Schlüssel verschiebt sie auf das Kontingent des Kontos.
| Tarif | Anfragen pro Sekunde | Etiketten pro Monat |
|---|---|---|
| free | 3 | 5.000 |
| starter | 5 | 25.000 |
| pro | 10 | 100.000 |
| business | 20 | 500.000 |
| enterprise | 20 | nach Vereinbarung |
Dieselbe Schleife funktioniert für die anderen Etikettensprachen, die einem Assistenten begegnen können — EPL, TSPL und CPCL haben eigene Render- und Diagnose-Endpunkte.
| Sprache | Endpunkt |
|---|---|
| ZPL | /v1/printers/{dpmm}dpmm/labels/{width}x{height}/{index}/ |
| EPL | /v1/epl/render |
| TSPL | /v1/tspl/render |
| CPCL | /v1/cpcl/render |
Zwei Grenzen gehören ausgesprochen, denn ein Assistent nennt sie nicht von selbst. Erstens: Ein Modell, das seine Ausgabe nie gerendert hat, rät — ZPL ist nachsichtig genug, dass auch falscher Code oft irgendetwas druckt; "es hat ZPL erzeugt" ist nicht dasselbe wie "es hat das richtige Etikett erzeugt". Zweitens: Das Rendering ist eine Vorschau — es findet Fehler im Code, nicht in Firmware, Schriften oder Kalibrierung des Druckers.
Browser-Vorschau öffnen → API-Referenz lesen → KI-Assistenten verbinden (MCP) →
Sie können ZPL schreiben, und das gut. Zeichnen können sie es nicht: Im Chatfenster gibt es keinen Etiketten-Renderer, also prüft nichts die Ausgabe, bis etwas außerhalb des Modells sie rendert.
Über einen Werkzeugaufruf. Assistenten, die MCP sprechen, lassen sich mit einem Render- und Prüfserver verbinden und rufen ihn selbst auf; andere werden von einem Skript gesteuert, das dieselbe HTTP-Anfrage stellt.
Weil das der einzige Teil der Antwort ist, den es lesen kann. Eine Warnung, die den übersprungenen Befehl oder das herausgefallene Feld benennt, macht aus einer Vermutung eine Korrektur.
Behandeln Sie es wie jeden anderen Code: rendern, Befunde lesen und vor einer Serie testdrucken. Der Renderer findet Code-Fehler; den Rest findet das erste physische Etikett.