Gleisgeometrie per Steuerschnittstelle

[gmd]

Neo,

du hast mich mal gefragt was mir an der neuen schnittstelle fehlt und ich war noch nicht vollstaendig im bilde. Das bin ich zwar immer noch nicht , aber zumindest kann ich jetzt eine funktion nennen die mir in der neuen schnittstelle fehlt.
303;name;0;1   also extended geometrie mit allen segmenten aus der alten schnittstelle.
Warum ? : wenn man ein Katalogkleis mit dem editor verbiegt und verlaengert, verkuerzt, etc. dann kann man das nicht erkennen. Ich kann keine flexibel verlegten gleise erkennen (selbe guid wie original, und auch nicht anders gekennzeichnet). Das ist fatal fuer meine blockerkennung und auch die plazierung von steuerobjekten, da kein durchgaengiger gleisplan errechnet werden kann. Damit wuerde mein konzept so wie die schnittstelle jetzt ausgelegt ist nicht mehr funktionieren, da luecken im gleisplan entstehen oder jegliche abweichung vom standardgleis vermieden wird, und das ist theorie.

Weiterhin, und das ist halt eine schoenheitssache und nicht existentiell, waere es schoen bei erzeuge objekt auch eine variation angeben zu koennen. Mein programm kennt alle variationen
und wenn du diese funktion implementierst, mache ich ein plugin mit dem man variationen eines modells zur auswahl auf dem board positionieren kann und nicht einzeln durchgehen muss.
Wenn man natuerlich nocht die anzahl von variationen abfragen kann waere das noch besser.

Gruss
gmd

[gmd]

Neo,
Ich bleibe mal bei diesem thread mit den rueckmeldungen bezueglich der neuen schnittstelle.
Ein ganz wesentliches problem, abgesehen von einzelnen funktionen, ist die performance beim anlysieren von gleisplaenen und 
orgnisieren groesserer objektmengen, bedingt durch die abwesenheit der kommandogruppen.
Ich kann natuerlich alle kommandos einzeln schicken, es funktioniert grundsaetzlich, aber der unterschied ist faktor 100 in der laufzeit.

Ich habe limits festgestellt in der anzahl der kommandos pro gruppe abhaengig vom typ des kommandos und habe empirisch zuverlaessige werte ermittelt.
Zum beispiel um fuer 500 objekte die koordinaten zu lesen brauche ich im gruppenmodus 103ms, transformationen lese ich in batches von 200, ebenenfalls um
die 100ms.
Das sind zeiten, die ich mit einzelkommandos niemals erreiche. Und das wird sich auch auf die steuerung auswirken, wenn eine entsprechende anzahl von operationen auszufuehren ist.
Derzeit werde ich nur diejenigen funktionen umstellen die nicht zeitkritisch sind und die neue schnittstelle lediglich fuer scripte verwenden.
Auch die verarbeitung von events ist durch das Json format langsamer geworden, wir reden hier zwar nur um wenige milisekunden, aber das addiert sich
natuerlich bei tausenden von events.
Meine app laeuft jetzt multicore und ich versuche zu optimieren wo ich kann.

Eine weitere funktion, die ich vermisse, ist lesen objektypen, also die moeglichkeit alle gleise zu lesen und nicht nur uber die selektion. Die alte schnittstelle sendet
zwar viele objekte die nicht typ 1 sind   auch wenn ich nur nach typ 1 frage, und hat auch fehler bei denen falsche typen zurueckgegeben werden, aber das filtern
ist immer noch schneller als bei einer gesamtselektion, da die anzahl der gleise in der regel deutlich geringer ist als die anzahl der nicht gleise.

Es stellt sich halt die frage, wie du die verwendung der schnittstelle in zukunft wirklich siehst. Fuer mich ist die alte schnittstelle in vieler hinsicht einfach besser,
und wie erwaehnt, das senden von scripten ist eine gute sache. Ich sehe die neue schnittstelle nicht wirklich als realzeitsteuerung fuer groessere anlagen.
Die voraussetzung dafuer sind einfach kommandogruppen.
Du wirst moeglicherweise auf die verwendung von scripten hinweisen, die zur laufzeit als eine art kommandogruppe verwendet werden koennen,
und  ich werde auch ausprobieren wo da die grenzen sind, fuer die kontruktionsphase ist die alte schnittstelle jedenfalls noch nicht ersetzbar.

Du koenntest zum beispiel
{"jsonrpc": "2.0", "method": "editor.getEntityContentID", "params": {"_class": "entity", "name": "BD_W3-E"}, "params": {"_class": "entity", "name": "BD-AG-B07"}, "id": 1}
verarbeiten, wie bei gruppierung usw. Das kommando wird nicht zurueckgewiesen, liefert aber nur eine guid, was ja nicht ueberrascht, wenn man den namen der
funktion betrachtet.

In summe, mit alter und neuer schnittstelle habe ich alle funktionen, die ich fuer meine app brauche. Ich erwarte auch nicht dass du wegen mir funktionen einbaust,
die nicht deinem langfrisitigen konzept entsprechen, aber wie schon gesagt, es kommt letztlich darauf an wozu die schnittstelle gut sein soll. 
Jedefalls bin ich dankbar, dass du die alte schnittstelle nicht gleich ersetzt hast, sondern dass ich beide parallel nutzen kann in der V9.

Gruss
Gmd

 

 

[Neo]

Hallo Gmd,

fehlende Funktionen kann ich gern nachimplementieren, aus diesem Grund gibt es ja noch die alte Schnittstelle, um zu sehen, was in der neuen benötigt wird und was nicht.

vor 10 Stunden schrieb gmd:

abwesenheit der kommandogruppen

Sind dir die Batch Requests von JSON-RPC bekannt? Du kannst auch mit der neuen Schnittstelle eine Gruppe von Einzelkommandos versenden, in dem du die Requests als JSON-Array versendest. Dieses Array wird immer in einem Stück verarbeitet, dazwischen gibt es keine anderweitige Unterbrechnung durch das Studio.

Viele Grüße,

Neo

[gmd]

Neo,

danke, wie sieht das mit den return werten aus, ich nehme an die kommen als json zurueck und in der reihenfolge der kommandos, correct ?
Werde das ausprobieren.
Ich bin nicht mehr weit davon entfernt die blockstrukturen automatisch zu erkennen und alle benoetigten steuereinrichtungen automatisch zu plazieren.
Werde weiter berichten, koennte ein plugin daraus werden.


Auslesen des gleisplans mit allen informationen und zeichnen des plans in rund 30 sekunden, da sind noch einige
einzelaufrufe drin.
Habe noch keine zeiten fuer die plazierung von signalen und kontakten. Ich muss noch scripte bauen fuer die
objektverknuepfungen. Aber alles in allem geht es vorran.
Habe auch schon mit ueber 10,000 gleisen getestet, welches der ausloeser war zu optimieren wo ich konnte. Das
beispiel oben hat 750 gleiselemente, ist also vergleichsweise klein.
Sagen wir mal eine rohanlage mit 2000 gleiselementen mit allen signalen und kontakten zu versehen und die signifikanten 
gleise alle mit blockkennungen versehen in unter 3 minuten, das waere so mein naechstes ziel.
Gruss
Gmd
 

[EASY]

Hallo,

vor 7 Stunden schrieb gmd:

wie sieht das mit den return werten aus, ich nehme an die kommen als json zurueck und in der reihenfolge der kommandos, correct ?

die Rückgabe ist auch ein JSON-Array und bei meinen Versuchen in der Reihenfolge.
(Zur Not gibt es ja noch die id zum Auswerten oder Selektieren von relevanten Antworten)...

Gruß
EASY