tests/testdata/test_system.json aus sps_skel/data/test_system.dxf (dxf_anlage_export.py --projekt TestSystem): 9 Kreisel, 10 Separatoren, BTMT Beladung, SC Entladung. Treiber tests/test_test_system.lsp (TEST_TEST_SYSTEM, Menue Tests -> Testanlage test_system) nutzt dematic_arvato:bau-datei, in alltests.json aktiv (save dxf). [FIX] dxf_anlage_export.py: doppelte Kreisel-IDs (Kreisel einzeln gebaut, NUMMER beginnt mehrmals bei 1) bekommen die naechste freie Nummer, mit Hinweis + Test. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
24 KiB
JSON-Eingabe fuer den LISP-Bau
Welche Objekte sich aus einer JSON-Datei an einer gegebenen x/y/z-Koordinate
erzeugen lassen, in welchem Format sie beschrieben werden und welche
LISP-Routine sie baut. Grundlage sind die Testdaten in tests/testdata/*.json
und die Treiber in tests/test_*.lsp, die sie lesen.
Die zugehoerigen LISP-Routinen mit Signaturen stehen in
lisp_methods.md. Diese Seite ersetzt das fruehere
tests/testdata/object_data.md (geloescht in Commit e147b89, auf das Code-
Kommentare teilweise noch verweisen).
Feldnamen als Python-Konstanten: lib/testdata_schema.py buendelt die
Feldnamen/festen Werte der Abschnitte 1 (Kreisel), 2 (Einzelbloecke), 3 (VF
Standard/Etage) und 4.1 (Gefaellestrecke Modus 1) als benannte Konstanten
(sch.F_ABSTAND, sch.SEITE_LINKS, ...), genutzt von lib/dxf_anlage_export.py
(eigene, mit unseren Makros gebaute Zeichnungen). lib/dxf_scan_components.py
(fremde Zeichnungen) hat dieselben Feldnamen weiterhin als eigene String-
Literale - gleiches Schema, noch nicht auf das gemeinsame Modul umgestellt.
0. Uebersicht
| Objekt | Erkennungsmerkmal im JSON | Bau-Routine (Produktion) | Koordinaten-Eingang | Beispiel-Datei |
|---|---|---|---|---|
| Kreisel (Insert) | "function": "insert", KEIN block |
kreisel-insert-script |
x,y,z = Einfuegepunkt |
kreisel_tests.json, mubea.json, hundm05.json, dematic_arvato.json |
| Kreisel (Connect) | "function": "connect" |
kreisel-connect-script |
start_*, end_* |
(nur test_kreisel.lsp, z.Z. kein Datensatz) |
| Einzelblock (Separator, Scanner, BTMT, Eingang/Ausgang, Vario-Bausteine) | "function": "insert" + "block" |
direktes _.INSERT nach ssg-ils-block-laden |
x,y,z + rotation |
mubea.json, hundm05.json, dematic_arvato.json |
| VarioFoerderer Standard | test_id beginnt mit VF_, typ fehlt oder "standard" |
berechne-alle-winkel + variofoerderer-einfuegen + vf-block-erstellen |
x,y,z = KS_EIN des AS-Elements |
mubea.json, foerderer_tests.json |
| VarioFoerderer Etage | test_id VF_* + "typ": "etage" |
berechne-etage + etage-foerderanlage-einfuegen + vf-block-erstellen |
wie Standard | mubea.json |
| Gefaellestrecke Modus 1 | test_id GF_* bzw. "modus": 1 |
gefaellestrecke-einfuegen (bzw. gf-rebuild) |
start_mm = KS_EIN des AS-Elements |
mubea.json, gefaellestrecke_tests.json |
| Gefaellestrecke Modus 2 | "modus": 2 |
wie Modus 1, deltaL/hz aus zwei Punkten |
start_mm + linie_start_mm/linie_ende_mm |
gefaellestrecke_tests.json |
| Gefaellestrecke Modus 3 | "modus": 3 |
nur ueber test_gefaellestrecke.lsp |
start_mm, ende_mm, bogen |
gefaellestrecke_tests.json |
| VF-Linienzug-Kette (Spec) | Kopf mit spec_id, danach glied/sub |
vsp-bau-aus-spec (Replay durch vf-linienzug-modus) |
start_punkt = Kettenanfang |
hundm05.json |
| VF-Linienzug (Journal) | Kopf mit test_id, danach typ = point_abs/real/string/... |
vfl-journal-replay-start + vf-linienzug-modus |
erstes point_abs |
linienzug_tests.json, hm_recformat.json |
| Omniflo Bogen/Weiche | "type": "bogen" / "weiche" + sivasnr |
_.INSERT der <sivasnr>.dxf (Kern omni:insert-dxf fragt den Punkt interaktiv) |
x,y, Z = hoehe |
omniflo_tests.json, omniflo_strecke_tests.json |
| Omniflo Gerade | "type": "gerade" + profil |
omni:make-gerade |
x,y -> x_ende,y_ende, Z = hoehe |
omniflo_strecke_tests.json |
| Waagrechte Foerderstrecke | "typ": "gerade" + startpunkt |
kein Bau-Pfad (wird gemeldet und uebersprungen) | startpunkt, endpunkt |
dematic_arvato.json |
Nicht aus JSON baubar (es gibt keine Testdaten und keinen Treiber): Eckrad, Geruest, TEF-Foerderer-Linie, TRO-Marker, Connections, Omniflo-Ladeschleife. Fuer Eckrad und Geruest existiert ein skriptfaehiger Kern, siehe lisp_methods.md.
Allgemeine Regeln
- Einheiten: Laengen und Koordinaten in mm, Winkel in Grad.
Fahrtrichtung
hz: 0 = +X (Ost), 90 = +Y (Nord), 180 = -X, 270 = -Y. - Z ist absolut:
z(bzw. Z instart_mm/start_punkt) ist die Weltkoordinate des Einfuegepunkts, also die Einbauhoehe. - Dimension 2D/3D: Gebaut wird in der aktuellen Dimension
(
ssg-ils-dim-aktuell:*ssg-ils-dim*->DXFM_DIM, Default 3D). Das Felddarstellungindematic_arvato.jsonist reine Dokumentation und wird nicht ausgewertet;TEST_HUNDM05_2D/_3Derzwingen die Dimension. - Flaches JSON: Die meisten Dateien werden mit
ssg-load-jsongelesen (zeilenweise, ein Objekt je{). Verschachtelte Objekte und mehrzeilige Arrays darin funktionieren nicht - darum stehen z.B. die Glieder einer Kette als eigene Objekte hinter ihrem Kopf-Objekt. Ausnahme:TEST_DEMATIC_ARVATOliest mit dem rekursivenssg-json-laden. - Reine Doku-Felder:
comment,beschreibung,description,quelle,row,seq,gruppe,assigned_to,hoehe_unbekannt,darstellungsowie alleexpect_*/erwartung_*-Felder werden beim Bau nicht gelesen.expect_*pruefen die Python-Tests gegen das Ergebnis. - Template-Felder (nur
test_mubea.lsp):anzahl,delta_x,delta_yerzeugen aus einem EintraganzahlKopien, jeweils umdelta_x/delta_yversetzt;test_idbekommt dann das Suffix_01..._nn. Gilt fuer VF, GF und Einzelbloecke.
1. Kreisel
Block KREISEL_n, gebaut von KreiselInsert.lsp.
1.1 Insert (freier Punkt)
{ "id": "KR_Kreuz_Q1_0Grad", "function": "insert",
"x": 500, "y": 500, "z": 2500,
"abstand": 2000, "rotation": 0.0, "typ": "STANDARD" }
| Feld | Pflicht | Bedeutung | Default |
|---|---|---|---|
id |
ja (fuer den Treiber) | Kennung im Ergebnis; NICHT die Block-ID (die vergibt ssg-id-generate) |
- |
function |
ja | "insert"; ohne block = Kreisel |
- |
x, y |
ja | Einfuegepunkt. Liegt auf der Kreiselachse einen Radius (400 mm) vor der Mitte des Antriebsrads (AN), also am aeussersten Punkt der AN-Seite | - |
z |
ja | Einbauhoehe; wird als hoehe uebergeben und in das Attribut HOEHE geschrieben |
kreisel.default_hoehe (2000) |
abstand |
ja | Mittenabstand Antriebsrad - Spannrad | kreisel.default_laenge (2300) |
rotation |
nein | Drehung der Achse AN -> SP, frei (kein Raster) | 0.0 |
typ |
nein | "STANDARD" oder "PIN" -> Attribut KREISELART |
"STANDARD" |
drehrichtung |
nein | "GUZ" oder "UZS" -> Attribut DREHRICHTUNG |
"UZS" |
Treiber: kreisel:run-insert-test (test_kreisel.lsp), mubea:build-kreisel,
hundm05:bau-kreisel (auch fuer dematic_arvato.json/showroom_ils.json).
Nur hundm05:bau-kreisel liest drehrichtung aus und reicht sie an
kreisel-insert-script weiter; mubea:build-kreisel setzt es (noch) nicht um.
1.2 Connect (Start- und Endpunkt)
{ "id": "K2", "function": "connect",
"start_x": 0, "start_y": 0, "start_z": 2000,
"end_x": 5000, "end_y": 0, "end_z": 2000, "typ": "STANDARD" }
start_* und end_* sind die aeussersten Punkte der AN- bzw. SP-Seite.
abstand (= Distanz - Kreiseldurchmesser 800) und rotation werden daraus
berechnet. Die Einbauhoehe kommt aus start_z. Nur test_kreisel.lsp kennt
connect; die anderen Treiber bauen ausschliesslich insert.
2. Einzelbloecke (Separator, Scanner, BTMT, Eingang/Ausgang, Vario-Bausteine)
Jeder Eintrag mit "function": "insert" UND "block" wird als einzelner
Block eingefuegt, ohne Wrapper-Block und ohne Verkettung.
{ "id": "HundM05_SCANNER_02", "function": "insert", "block": "Scanner",
"x": 4095.5, "y": 1164.1, "z": 2154, "rotation": 270 }
| Feld | Pflicht | Bedeutung | Default |
|---|---|---|---|
block |
ja | Blockname OHNE _2D/_3D-Suffix |
- |
x, y, z |
ja | Einfuegepunkt = Basispunkt der Block-DWG (nicht KS_EIN) | - |
rotation |
nein | Drehung um Z | 0 |
id / test_id |
nein | Kennung im Ergebnis | SEPARATOR_<n> bzw. Blockname |
Ablauf: ssg-ils-block-laden loest den Namen auf data/ils/<block>_<DIM>.dwg
auf (3D-Fallback), danach _.INSERT eff pt "" "" rotation und
ssg-id-generate. Fehlt die DWG, wird Separator_SP eingefuegt.
Treiber: mubea:build-separator, hundm05:bau-sensor (auch Dematic).
Das Layer-Attribut LAYER wird dabei nicht angewendet; der Block landet auf
dem aktuellen Layer.
In den Testdaten verwendete Blocknamen
block |
DWG in data/ils |
Verwendet in | Hinweis |
|---|---|---|---|
Scanner |
Scanner_2D/_3D.dwg |
mubea, hundm05, dematic_arvato | |
Separator_SP |
Separator_SP_2D/_3D.dwg |
(Fallback) | Block von ILS_SEPARATOR_INSERT |
S-LP |
fehlt | mubea, hundm05, dematic_arvato | wird zu Separator_SP |
S-SP |
fehlt | dematic_arvato | wird zu Separator_SP |
BTMT-Beladung |
BTMT-Beladung_2D/_3D.dwg |
mubea, hundm05 | wie ILS_BTMT_Beladung |
SC_Entladung |
SC_Entladung_2D/_3D.dwg |
mubea, hundm05 | wie ILS_BTMT_Entladung |
Eingang / Ausgang |
Eingang_*/Ausgang_*.dwg |
mubea | Symbole wie ILS_EINGANG_INSERT/ILS_AUSGANG_INSERT |
AS_Element_90_links / _rechts |
vorhanden | dematic_arvato | loses AS-Element (sonst Teil eines VF/GF) |
ES_Element_90_rechts, ES_Element_30_rechts |
vorhanden | dematic_arvato | loses ES-Element |
Vario_Motorstation_500mm_rechts |
vorhanden | dematic_arvato | lose Motorstation |
Vario_Umlenkstation_500mm_rechts |
vorhanden | dematic_arvato | lose Umlenkstation |
Vario_Kurve_rechts_30_TEF_aussen |
vorhanden | dematic_arvato | lose Vario-Kurve |
Grundsaetzlich ist jeder Blockname aus data/ils erlaubt (es gibt keine
Whitelist). Die losen AS/ES-/Vario-Bausteine bilden aber keine Kette und keinen
VF_n/GF_n-Block - fuer eine zusammenhaengende Strecke Abschnitt 3-5 nutzen.
3. VarioFoerderer Standard und Etage
Block VF_n. Eingang sind die Gesamtmasse der Anlage; Winkel und
Teillaengen berechnet der Solver.
{ "test_id": "VF_Schnitt_C", "richtung": "Auf",
"deltaL": 9110, "deltaH": 474, "winkel": 21,
"gf_verteilung": "manuell", "L_GF1": 2298, "seite": "links",
"hz": 0.0, "x": 400, "y": 14120, "z": 1554 }
| Feld | Pflicht | Bedeutung | Default |
|---|---|---|---|
test_id |
ja | muss mit VF_ beginnen (steuert den Dispatcher in test_mubea.lsp) |
- |
typ |
nein | "standard" (AS/ES 90 Grad) oder "etage" (AS/ES 30 Grad, uebereinander) |
"standard" |
richtung |
ja | "Auf" oder "Ab" |
- |
deltaL |
ja | horizontale Gesamtlaenge inkl. AS/ES, Boegen, GF-Vor-/Nachlauf | - |
deltaH |
ja | Hoehendifferenz (Betrag; Vorzeichen kommt aus richtung) |
- |
winkel |
nein | Bogenwinkel erzwingen, nur aus der Kandidatenliste (vario.bogen_winkel: 3, 6, 9, 12, 15, 18, 21, 27, 33, 39, 45, 51). Ist er nicht loesbar, wird NICHT gebaut |
kleinster gueltiger Winkel |
L_GF1 |
nein (mubea) | Vorlauf-Laenge (GF vor dem Foerderer); Nachlauf = Rest von L_GF |
- |
gf_verteilung |
nein (foerderer) | "gleichmaessig", "vorne", "hinten"; in mubea.json nur Doku (dort zaehlt L_GF1) |
"gleichmaessig" |
seite |
nein | "links"/"rechts" (Seite der AS/ES-Elemente) |
"links" |
hz |
nein | Fahrtrichtung | 0.0 |
x, y, z |
ja (mubea) | Startpunkt = KS_EIN des AS-Elements; z = Einbauhoehe am Anfang |
- |
Hinweise:
foerderer_tests.jsonhat stattx/y/zeinen Kopf-Eintrag{"y_abstand": 600}: alle Foerderer starten bei x = 0, z = 0 und werden umy_abstandversetzt. Dieses Format kennt nurtest_foerderer.lsp."Ab"mitdeltaH< 1 ist geometrisch unmoeglich und wird abgewiesen.- Der Treiber schreibt nach dem Bau
vf-edit-xdata-schreiben(Typ +hz), damit der Block per Doppelklick editierbar ist.
4. Gefaellestrecke
Block GF_n: AS-Element -> Staustrecke (skaliert) -> Separator -> ES-Element.
Eingang ist die horizontale Laenge, nicht die Hoehendifferenz - die ergibt
sich aus Laenge und Neigung.
4.1 Modus 1 - Werteingabe
{ "test_id": "GF_Mubea", "modus": 1,
"deltaL_mm": 9110, "hz_grad": 180.0, "winkel_grad": 2.27,
"start_mm": [9510, 12300, 2028],
"as_seite": "links", "es_seite": "links",
"as_winkel": "90", "es_winkel": "90" }
| Feld | Pflicht | Bedeutung | Default |
|---|---|---|---|
test_id |
ja | in mubea.json muss sie mit GF_ beginnen |
- |
modus |
nein | 1 |
- |
deltaL_mm |
ja | horizontale Gesamtlaenge AS + Staustrecke + Separator + ES | - |
winkel_grad |
nein | Neigung der Staustrecke | 3.0 |
hz_grad |
nein | Fahrtrichtung | 0.0 |
start_mm |
ja | [x, y, z] = KS_EIN des AS-Elements; Z = Einbauhoehe oben |
- |
as_seite, es_seite |
nein | "links"/"rechts" |
"links" |
as_winkel, es_winkel |
nein | "90" oder "30" (als STRING) |
"90" |
Die Staustrecke ergibt sich aus
L_stau = (deltaL - aus-dx - ein-dx - 300 * cos(w)) / cos(w)
(300 = gefaelle.separator_breite). Eine Ziel-Hoehe gibt es nicht.
In gefaellestrecke_tests.json stehen deltaL_mm, winkel_grad und
z_start_mm in einem gemeinsamen Kopf-Eintrag ohne test_id und gelten fuer
alle Faelle der Datei.
4.2 Modus 2 - Richtung aus zwei Punkten
Wie Modus 1, aber deltaL und hz werden aus linie_start_mm ->
linie_ende_mm berechnet (nur X/Y). start_mm bleibt der Einfuegepunkt und
ist unabhaengig von der Linie.
{ "test_id": "M2_hz000", "modus": 2, "start_mm": [0, -35000, 5000],
"linie_start_mm": [0, -35000, 0], "linie_ende_mm": [10000, -35000, 0],
"as_seite": "links", "es_seite": "links", "as_winkel": "90", "es_winkel": "90" }
4.3 Modus 3 - Linienzug
In der Produktion nicht skriptbar (gf-linienzug-modus waehlt vorgezeichnete
LINE/ARC-Objekte per Maus). test_gefaellestrecke.lsp zeichnet die Leitlinie
selbst und baut sie nicht-interaktiv nach. Zwei Formen:
{ "test_id": "M3_Bogen", "modus": 3,
"start_mm": [30000, -50000, 2000], "ende_mm": [38500, -43500, 1800],
"bogen": {"winkel_grad": 90, "radius_mm": 500, "seite": "links"},
"as_seite": "links", "es_seite": "links", "as_winkel": "90", "es_winkel": "90" }
{ "test_id": "M3_hz270", "modus": 3, "richtung": "Sued",
"start_mm": [0, -50000, 5000],
"deltaH_quelle": "M2_hz000", "deltaL_quelle": "M2_hz000", ... }
deltaH_quelle/deltaL_quelle uebernehmen die Masse eines frueher gebauten
Falls. Dieses Format ist an den Treiber gebunden. Fuer neue Anlagen besser
eine VF-Linienzug-Spec (Abschnitt 5) mit Linie-GF/GF-Bogen verwenden.
5. VF-Linienzug-Kette (Spec)
Beliebige Ketten aus GF-Linien, GF-Boegen, Vario-Kurven und VF-Einheiten,
ohne Dialog gebaut (VF_SPEC_BAU, TEST_HUNDM05). Eine Kette = ein
Kopf-Objekt, danach ihre Glieder (glied) und deren Unterknoten (sub) in
Baureihenfolge. Ergebnis ist ein VF_n-Block mit vollem SSG_VF_EDIT-Journal
(per Doppelklick editierbar).
{ "spec_id": "VF_spec_LZ_01", "modus": 1,
"start_punkt": [4912.2, 1230.9, 2154.0], "start_hoehe": 2154.0,
"as": 1, "as_winkel": "90", "as_seite": "links" }
{ "glied": "Linie-GF", "nr": 1, "dl": 2249.3, "hz": 90.0,
"gefaelle": "winkel", "winkel": 3.0, "ende": "nein" }
{ "glied": "Horizontal-VF", "nr": 2, "dl": 3256.9, "gf_verteilung": "einlauf",
"vf_sep_vor": 0, "vf_sep_nach": 0, "vf_ende": "nein", "vf_separator": 0 }
{ "sub": "vario-kurve", "winkel": 90, "seite": "rechts", "variante": "innen" }
{ "sub": "motorstation" }
{ "glied": "ES", "winkel": "90", "seite": "links" }
Kopf
| Feld | Bedeutung |
|---|---|
spec_id |
Kennung der Kette |
modus |
1 (nur Modus 1 hat einen Uebersetzer) |
start_punkt |
[x, y, z] Kettenanfang (KS_EIN des AS-Elements bzw. erstes Glied) |
start_hoehe |
Einbauhoehe am Start |
as |
1 = AS-Element setzen, 0 = nicht |
as_winkel / as_seite |
"90"/"30" bzw. "links"/"rechts" |
Glieder (glied)
glied |
wichtigste Felder |
|---|---|
Linie-GF |
dl, hz (nur beim ersten Glied der Kette), laenge_modus (endpunkt/hoehe/steigend), ende (ja-mit-es/ja-ohne-es/nein), sep_vor, sep_nach, gefaelle (hoehe/winkel) + hoehe bzw. winkel |
GF-Bogen |
winkel (30/60/90), seite |
Vario-Kurve |
als eigenes Glied (Kettenanfang) vom Uebersetzer noch NICHT unterstuetzt -> Spec-Fehler; Vario-Kurven als sub einer VF-Einheit angeben |
Horizontal-VF |
dl, eingang_hoehe, gf_verteilung (haelfte/einlauf), vf_sep_vor, vf_sep_nach, vf_ende (ja-mit-es/nein/automatisch/zielpunkt-ohne-es), vf_separator (nur bei vf_ende = nein) + sub-Knoten |
Linie-VF |
dl, hoehe, optional winkel_idx + sub-Knoten |
Linie |
dl, hoehe, segment_typ (GF/VF), optional winkel_idx |
ES |
winkel ("90"/"30"), seite |
Unterknoten einer VF-Einheit (sub): horizontal (sep_vor, sep_nach),
vario-kurve (winkel, seite, variante aussen/innen), auf-ab
(richtung auf/ab, hoehe), motorstation, kettenende (es,
es_winkel, es_seite).
Ja/Nein-Felder (as, sep_vor, vf_sep_vor, es, ...) als 1/0 oder
"ja"/"nein"; mehrwertige Felder (ende, vf_ende) nur mit den genannten
Woertern. Vollstaendige Regeln
(Menue-Codes je Frame, hz nur einmal, Verhalten bei winkel_idx):
variofoerderer.md, Abschnitt 8b.
Die Spec wird nicht von Hand geschrieben, sondern mit
python lib/vf_spec_export.py <protokoll.json> <spec.json> aus einer
aufgezeichneten Kette erzeugt. Fehlerhafte Specs werden komplett abgewiesen
(vsp-pruefen sammelt alle Fehler, gebaut wird dann nichts).
Andere Objekte in derselben Datei: Neben den Ketten darf hundm05.json
Kreisel (Abschnitt 1) und Einzelbloecke (Abschnitt 2) enthalten. Erkennbar
sind sie an function; vsp-gruppieren ueberspringt sie, und
hundm05:bau-zusatzobjekte baut sie nach den Ketten. vf_spec_export.py
haengt sie beim Neuerzeugen unveraendert ans Dateiende.
6. VF-Linienzug (Eingabe-Journal)
Das Rohformat hinter der Spec: die Antworten auf die Fragen des interaktiven Linienzug-Ablaufs, in Reihenfolge. Nur fuer Regressionstests gedacht - fuer neue Anlagen die Spec (Abschnitt 5) verwenden.
{ "test_id": "VF_hundm05_LZ_01", "anlagetyp": "linienzug", "modus": 1, ... }
{ "typ": "point_abs", "wert": [4912.2, 1230.9, 2154.0], "kommentar": "Startpunkt" }
{ "typ": "real", "wert": 2154.0, "kommentar": "Hoehe (Z)" }
{ "typ": "string", "wert": "1", "kommentar": "AS-Element? Ja" }
{ "typ": "step", "wert": "Linie-GF", "kommentar": "Glied-Marker" }
{ "typ": "point_rel", "dL": 2249.3, "hz": 90.0, "kommentar": "Endpunkt" }
{ "typ": "int", "wert": 90, "kommentar": "Vario-Kurve Winkel" }
typ: point_abs (absoluter Punkt), point_rel (Abstand dL + Richtung
hz, hz nur beim ersten Segment), real, int, string (Menue-Code als
String), step (Glied-Marker, beim Replay uebersprungen). Kopf-Feld heisst
anlagetyp, nicht typ, damit Kopf und Eingabe unterscheidbar bleiben.
| Datei | Treiber |
|---|---|
linienzug_tests.json, linienzug_tests_stufe2.json |
TEST_LINIENZUG, TEST_LINIENZUG_STUFE2 |
hm_recformat.json (5 echte HundM-Ketten, erzeugt mit lib/vf_journal_export.py) |
TEST_HM_RECFORMAT (in alltests.json abgeschaltet) |
7. Omniflo
7.1 Bogen und Weiche
{ "id": "821104025", "type": "bogen", "sivasnr": "821104025",
"x": 219.4, "y": 223.06, "hoehe": 2000, "drehung": 0.0 }
| Feld | Pflicht | Bedeutung | Default |
|---|---|---|---|
type |
ja | "bogen" oder "weiche" |
- |
sivasnr |
ja | Sivas-Nummer = Dateiname %DXFM_OMNIFLO%/<sivasnr>.dxf |
- |
x, y |
ja | Einfuegepunkt ($INSBASE der DXF, gesetzt mit set_einfuegepkt.py) |
- |
hoehe |
nein | Z des Einfuegepunkts UND Attribut HOEHE |
2000 |
drehung |
nein | Drehung + Attribut DREHUNG |
0 |
Es gibt kein z: die Hoehe ist zugleich die Z-Koordinate. Gueltige
Sivas-Nummern: data/json/omniflo_boegen.json, omniflo_weichen.json.
Treiber: omni:test-insert (test_omniflo.lsp), omnistr:insert-bogen
(test_omniflo_strecke.lsp).
7.2 Aluprofil-Gerade
{ "seq": 1, "type": "gerade", "profil": "AP110", "laenge": 1000.0,
"x": 2000.0, "y": 0.0, "x_ende": 3000.0, "y_ende": 0.0,
"drehung": 0.0, "hoehe": 2000, "id": "0003" }
profil = "AP60", "AP110" oder "APG110". Die Gerade laeuft von
(x,y) nach (x_ende,y_ende) auf Z = hoehe; Laenge und Drehung folgen
aus den Punkten (laenge ist nur Doku). Gebaut mit omni:make-gerade.
8. Waagrechte Foerderstrecke (gerade) - noch ohne Bau-Pfad
{ "test_id": "GERADE_Arvato_01", "typ": "gerade", "laenge": 8313.39, "hz": 90.0,
"startpunkt": [2334.97, 177818.67, 0.0], "endpunkt": [2334.96, 186132.06, 0.0] }
Ein Antriebs-/Umlenkstation-Paar ohne Hoehendifferenz, so von
lib/dxf_scan_components.py ausgegeben (ein VarioFoerderer ist bei
deltaH = 0 nicht loesbar). TEST_DEMATIC_ARVATO meldet diese Eintraege und
ueberspringt sie. Passende Primitive waere insert-hz-scaled-block-by-ks
(vf_etage.lsp) mit Staustrecke_SP_1000_mm, siehe
lisp_methods.md.
9. Testdaten-Dateien im Ueberblick
| Datei | Inhalt | Treiber / Befehl |
|---|---|---|
kreisel_tests.json |
8 Kreisel (insert) |
TEST_KREISEL |
foerderer_tests.json |
Kopf y_abstand + 17 VF Standard |
TEST_FOERDERER |
gefaellestrecke_tests.json |
Kopf + GF Modus 1/2/3 | TEST_GEFAELLESTRECKE |
omniflo_tests.json |
27 Boegen, 80 Weichen | TEST_OMNIFLO |
omniflo_strecke_tests.json |
Streckenzug aus Geraden und Boegen | TEST_OMNIFLO_STRECKE |
linienzug_tests.json / _stufe2.json |
Eingabe-Journal je einer Kette | TEST_LINIENZUG / TEST_LINIENZUG_STUFE2 |
hm_recformat.json |
5 HundM-Ketten als Journal | TEST_HM_RECFORMAT |
hundm05.json |
5 HundM-Ketten als Spec + Kreisel, Separatoren, Scanner, BTMT | TEST_HUNDM05, VF_SPEC_BAU |
mubea.json |
Gesamtanlage: Kreisel, VF Standard/Etage, GF-Template (20 Stueck), Separatoren, Scanner, BTMT, Eingang/Ausgang | TEST_MUBEA |
dematic_arvato.json |
Vorlage aus dxf_scan_components.py: Kreisel, Einzelbloecke, gerade (Hoehen fehlen) |
TEST_DEMATIC_ARVATO (abgeschaltet) |
showroom_ils.json |
ILS-3.0-Showroom-Vorlage aus dxf_scan_components.py (Kreisel, Gefaellestrecken; Hoehen teils Platzhalter), gleicher Treiber wie dematic_arvato.json |
TEST_SHOWROOM_ILS |
test_system.json |
Testanlage aus dxf_anlage_export.py (sps_skel/data/test_system.dxf): 9 Kreisel, 10 Separatoren, BTMT Beladung, SC Entladung - Vorlage fuer die sps_skel-Pipeline (CSV -> TRO -> SCL), gleicher Treiber wie dematic_arvato.json |
TEST_TEST_SYSTEM |
hundm05_linienzug_polylines.json |
Polylinien aus extract_polylines.py |
kein Treiber (Analyse-Daten) |
vfl_journal_hm05_abbruch.json |
rohes Journal (kind/value) eines abgebrochenen Baus |
kein Treiber |
10. Eigene Anlage beschreiben - Kurzanleitung
- Kreisel als
insert(Abschnitt 1):x/yam aeussersten Punkt der AN-Seite,z= Einbauhoehe. - Einfache Steig-/Fall-Strecken mit fester Form als VF Standard/Etage (Abschnitt 3) bzw. Gefaellestrecke Modus 1 (Abschnitt 4.1), Startpunkt jeweils = KS_EIN des AS-Elements.
- Ketten mit Kurven, mehreren VF-Einheiten oder GF-Boegen als Spec
(Abschnitt 5) - am einfachsten eine Kette einmal interaktiv bauen, mit
lib/vf_journal_export.py+lib/vf_spec_export.pyals Spec exportieren und Startpunkt/Laengen anpassen. - Separatoren, Scanner, BTMT-Stationen, Eingang/Ausgang als Einzelblock (Abschnitt 2).
- Aus Kreisel, Einzelbloecken und Specs gemischt baut derzeit nur der
HundM05-Treiber (
TEST_HUNDM05); fuer VF Standard/Etage + GF zusammen mit Kreiseln den Mubea-Treiber (TEST_MUBEA) als Vorlage nehmen.