Störung eWicht/srcpd
Guido Scholz
Hallo zusammen,
nachdem ich mich unvermittelt als Mitglied dieser Mailingliste
wiedergefunden habe, scheint der primäre Anlaß die aktuelle
Unverträglichkeit der GA-Ansteuerung beim srcpd zu sein.
Ich habe das Thema auf der srcpd-Mailingliste aufgenommen. Eine mögliche
Lösung scheint das Aktivieren des 416-Fehlers zu sein. Am einfachsten
wäre es wohl, wenn David das mal ausprobieren würde. Dazu reicht es die
Zeile 187 in srcp-ga.c durch entfernen der Kommentarzeichen zu
aktivieren.
Kannst Du das mal testen, David?
Gruß
Guido
--
http://www.bayernline.de/~gscholz/
http://www.lug-burghausen.org/
David Rütti
Hallo Guido
Guido Scholz schrieb:
> Hallo zusammen,
> nachdem ich mich unvermittelt als Mitglied dieser Mailingliste
> wiedergefunden habe, scheint der primäre Anlaß die aktuelle
> Unverträglichkeit der GA-Ansteuerung beim srcpd zu sein.
>
> Ich habe das Thema auf der srcpd-Mailingliste aufgenommen. Eine mögliche
> Lösung scheint das Aktivieren des 416-Fehlers zu sein. Am einfachsten
> wäre es wohl, wenn David das mal ausprobieren würde. Dazu reicht es die
> Zeile 187 in srcp-ga.c durch entfernen der Kommentarzeichen zu
> aktivieren.
>
> Kannst Du das mal testen, David?
>
Klar, kein Problem. Werde ich am Sonntag testen+berichten.
Gruss
David
> Gruß
> Guido
>
>
Sven Schlender
> nachdem ich mich unvermittelt als Mitglied dieser Mailingliste
> wiedergefunden habe, scheint der primäre Anlaß die aktuelle
> Unverträglichkeit der GA-Ansteuerung beim srcpd zu sein.
Hi Guido, danke, dass Du nicht gleich schreiend wieder davon rennst ;)
Sorry nochmal für den etwas sanften Druck - wie geschrieben reicht ein
kurzer Wink und ich nehme Dich wieder von der Liste.
> Ich habe das Thema auf der srcpd-Mailingliste aufgenommen. Eine
> mögliche Lösung scheint das Aktivieren des 416-Fehlers zu sein. Am
> einfachsten wäre es wohl, wenn David das mal ausprobieren würde. Dazu
> reicht es die Zeile 187 in srcp-ga.c durch entfernen der
> Kommentarzeichen zu aktivieren.
Was mich so ein bisschen wundert - man benötigt beim srcpd nicht unbedingt
ein INIT-Kommando absetzen, um ein GA verwenden zu können?!
Gruß, Sven.
Guido Scholz
> Hi Guido,
Hallo Sven,
> Was mich so ein bisschen wundert - man benötigt beim srcpd nicht unbedingt
> ein INIT-Kommando absetzen, um ein GA verwenden zu können?!
richtig, der hat eine Art von "auto-init", wobei ich jetzt nachsehen
müßte, welche Voreinstellungen er dann für die nicht initialisierten
Paramater nimmt.
Guido Scholz
> > Was mich so ein bisschen wundert - man benötigt beim srcpd nicht unbedingt
> > ein INIT-Kommando absetzen, um ein GA verwenden zu können?!
> richtig, der hat eine Art von "auto-init", wobei ich jetzt nachsehen
> müßte, welche Voreinstellungen er dann für die nicht initialisierten
> Paramater nimmt.
Ich habe gerade nochmal nachgesehen, das sieht konkret so aus:
if (!isInitializedGA(busnumber, addr))
initGA(busnumber, addr, 'P');
Es wird in diesem Fall also das Protokoll auf P, gesetzt sowie Bus und
Adresse auf den konkreten Wert.
Ob diese Protokollvorwahl im Einzelfall immer zum richtigen Ergebnis
führt, ist mir nicht bekannt. Manche Bus-Treiber unterstützen nur ein
bestimmtes, da kann dann nichts schief gehen.
Sven Schlender
auch Dich habe ich jetztmal wieder von der Liste runtergenommen. Bitte sag
bescheid, wenn es für Dich _absolut_ ok ist, dass Du auf dieser Liste bist.
> > > Was mich so ein bisschen wundert - man benötigt beim srcpd nicht
> > > unbedingt ein INIT-Kommando absetzen, um ein GA verwenden zu
> können?!
>
> > richtig, der hat eine Art von "auto-init", wobei ich jetzt nachsehen
> > müßte, welche Voreinstellungen er dann für die nicht initialisierten
> > Paramater nimmt.
>
> Ich habe gerade nochmal nachgesehen, das sieht konkret so aus:
>
> if (!isInitializedGA(busnumber, addr))
> initGA(busnumber, addr, 'P');
Ok, aber dieses AutoInit ist so ein bisschen an der Spec. vorbei, oder?
Gruß, Sven.
da...@ruetti13.ch
Hallo Guido
> Ich habe das Thema auf der srcpd-Mailingliste aufgenommen. Eine mögliche
> Lösung scheint das Aktivieren des 416-Fehlers zu sein. Am einfachsten
> wäre es wohl, wenn David das mal ausprobieren würde. Dazu reicht es die
> Zeile 187 in srcp-ga.c durch entfernen der Kommentarzeichen zu
> aktivieren.
>
> Kannst Du das mal testen, David?
Nachdem ich in Zeile 186 zudem die letzte schliessende Klammer entfernt
hatte, konnte ich srcpd kompilieren. Nach der Änderung scheint srcpd
einwandfrei zu funktionieren. Auf jeden Fall habe ich keine negativen
Effekte entdeckt.
Im Folgenden ein kleiner Ausschnitt aus der Command-Sitzung:
<- Handshake ->
1249849106.815 200 OK GO 3
get 1 ga 1 1
1249849119.263 416 ERROR no data
get 1 ga 1 0
1249849126.784 416 ERROR no data
<- Init per spdrs60 und set 1 ga 1 1 1 50 ->
get 1 ga 1 1
1249849144.756 100 INFO 1 GA 1 1 0
get 1 ga 1 0
1249849160.904 416 ERROR no data
set 1 ga 1 0 1 50
1249849980.310 200 OK
get 1 ga 1 0
1249849980.388 100 INFO 1 GA 1 0 0
get 1 ga 1 1
1249849144.756 100 INFO 1 GA 1 1 0
>
> Gruß
> Guido
Gruss David
Sven Schlender
> > > > richtig, der hat eine Art von "auto-init", wobei ich jetzt
> > > > nachsehen müßte, welche Voreinstellungen er dann für die nicht
> > > > initialisierten Paramater nimmt.
>
> > > Ich habe gerade nochmal nachgesehen, das sieht konkret so aus:
> > >
> > > if (!isInitializedGA(busnumber, addr))
> > > initGA(busnumber, addr, 'P');
>
> > Ok, aber dieses AutoInit ist so ein bisschen an der Spec. vorbei,
> oder?
>
> Was sagt denn die Spezifikation dazu? Ist das verboten?
Nein, ist es nicht direkt. Aber wenn man sich das Kapitel 5.1 durchliest,
ist der dort angenommen Lebenszyklus eines Geräts durchaus mit INIT, GET,
SET, TERM beschrieben. Ich verstehe das zumindestens so.
BtW: Da ist mir aufgefallen, das nach den INITs des eWicht eigentlich kein
GET geschickt wird - das müsste ich wohl noch einbauen.
Gruß, Sven.
Guido Scholz
> Nein, ist es nicht direkt. Aber wenn man sich das Kapitel 5.1 durchliest,
> ist der dort angenommen Lebenszyklus eines Geräts durchaus mit INIT, GET,
> SET, TERM beschrieben. Ich verstehe das zumindestens so.
Vermutlich gibt es noch einen anderen Grund für dieses Auto-Init. Bei
einem SRCP-Server, der selbst die Signalerzeugung für die Anlage
übernimmt, also gemäß DD[LW], ist die Situation sehr einfach:
[SRCP-Client] <------> [SRCP-Server] ------> [Anlage]
Er hat alles unter Kontrolle, und bekommt Statusänderungen nur von den
angeschlossenen Cliens.
Anders bei einem SRCP-Server, der an einer Zentrale hängt. Hier können
Statusänderungen auch von der Zentrale kommen, die eventuell sogar noch
Handregler angeschlossen hat:
[SRCP-Client] <------> [SRCP-Server] <------> [Zentrale] ------> [Anlage]
|
[Handregler]
Das dumme ist nun, dass die Zentrale kein SRCP kann, sondern z.B. nur Echos
der bereits an die Anlage geleiteten Stellbefehle des Handreglers an den
SRCP-Server weiterleitet. Die Zentrale sendet also quasi direkt ein SET
ohne vorgeschaltetes INIT. Dann braucht man halt ein Auto-Init.
> BtW: Da ist mir aufgefallen, das nach den INITs des eWicht eigentlich kein
> GET geschickt wird - das müsste ich wohl noch einbauen.
Warum brauchst Du nach einem Init ein Get? Wenn schon, dann ein Set.
Wertet Dein eWicht eigentlich Nachrichten des Info-Kanals aus?
David Rütti
Hallo
Ich habe mir die neue eWicht Firmware 1.0.5 auf Herz und Nieren geprüft.
Und hier kommt mein Senf :-)
- GA delay: Bei mir (Upgrade von 1.0.4) war er auf -1 gesetzt, sollte
m.E. was passenderes (z.B. 50 ms) sein
- Geschwindigkeitsstufen beim Drehgeber:
So wie ich es sehe, ist die Zählgeschwindigkeit (in 1er, 10er, oder
100er) abhängig von der Drehzeit, also etwa nach 3 s 10er und weiteren
3s 100er. Ich finde dies nicht ergonimisch und bin meistens mehrmals
über das Ziel hinausgeschossen. Ich wünsche mir eine Abhängigkeit von
der Drehgebergeschwindigkeit. Also langsam drehen 1er, mittelschnell
drehen 10er und schnell drehen 100er
- Schnelles Wechseln zwischen GA <-> GL:
Funktioniert. Allerdings hat sich ein kleiner Bug eingeschlichen: Bei
mehrmaligem Ändern der GA-Adresse (>= 3) ohne zwischendurch auf GL zu
wechseln, kann anschliessend nicht mehr auf die Lok gewechselt werden.
Druck auf GL bewirkt dann ein Umschalten auf eine alte GA Adresse.
Umgekehrt habe ich keine unerwünschten Effekte gefunden.
Gruss
David
Sven Schlender
> Das dumme ist nun, dass die Zentrale kein SRCP kann, sondern z.B. nur
> Echos der bereits an die Anlage geleiteten Stellbefehle des Handreglers
> an den SRCP-Server weiterleitet. Die Zentrale sendet also quasi direkt
> ein SET ohne vorgeschaltetes INIT. Dann braucht man halt ein Auto-Init.
Ok - soweit verstanden.
> > BtW: Da ist mir aufgefallen, das nach den INITs des eWicht eigentlich
> > kein GET geschickt wird - das müsste ich wohl noch einbauen.
>
> Warum brauchst Du nach einem Init ein Get? Wenn schon, dann ein Set.
SRCP:Spec.:
After INIT any write access to the affected device by SET or INIT for all
active sessions is invalid until
reading access is processed by the commands GET or VERIFY(depending on the
device group) or
TERM. This includes the session executing the INIT.
Vermutlich will man so erzwingen, dass ein Client Kenntnis über den
Grundzustand erlangt.
> Wertet Dein eWicht eigentlich Nachrichten des Info-Kanals aus?
Ja - eigentlich werden alle Zustände auf dem eWicht aus INFO-Nachrichten
abgeleitet.
Gruß, Sven.
Sven Schlender
wieder einmal vielen Dank fürs Testen.
> - GA delay: Bei mir (Upgrade von 1.0.4) war er auf -1 gesetzt, sollte
> m.E. was passenderes (z.B. 50 ms) sein
Ja, das hat etwas mit dem Upgrade zu tun (EEPROM-Speicherstelle steht auf
0xFF :). Wenn Du einen Reset auf Werkseinstellungen durchführst, wird Du
feststellen, das der initiale Wert derzeit auf 500 ms steht.
> - Geschwindigkeitsstufen beim Drehgeber:
> So wie ich es sehe, ist die Zählgeschwindigkeit (in 1er, 10er, oder
> 100er) abhängig von der Drehzeit, also etwa nach 3 s 10er und weiteren
> 3s 100er.
Es geht nicht über die Drehzeit, sondern über die Anzahl der inkrementierten
Schritte.
> Ich finde dies nicht ergonimisch und bin meistens mehrmals
> über das Ziel hinausgeschossen. Ich wünsche mir eine Abhängigkeit von
> der Drehgebergeschwindigkeit. Also langsam drehen 1er, mittelschnell
> drehen 10er und schnell drehen 100er
Ja - gut. Das ist jetzt nochmal ganz anders, als wir es bisher hatten. Aber
ich denke, das das vermutlich die bessere Lösung ist. Ich werde mich da
nochmal dransetzen und das einbauen.
> - Schnelles Wechseln zwischen GA <-> GL:
> Funktioniert. Allerdings hat sich ein kleiner Bug eingeschlichen: Bei
> mehrmaligem Ändern der GA-Adresse (>= 3) ohne zwischendurch auf GL zu
> wechseln, kann anschliessend nicht mehr auf die Lok gewechselt werden.
> Druck auf GL bewirkt dann ein Umschalten auf eine alte GA Adresse.
> Umgekehrt habe ich keine unerwünschten Effekte gefunden.
Mmmh, ok, das muss ich mir anschauen. Wieder mit srcpd getestet?
Sieht so aus, als es würde es bald eine 1.0.6 geben :)
Gruß, Sven.
David Rütti
Gern geschehen!
>> - GA delay: Bei mir (Upgrade von 1.0.4) war er auf -1 gesetzt, sollte
>> m.E. was passenderes (z.B. 50 ms) sein
> Ja, das hat etwas mit dem Upgrade zu tun
Habe ich mir gedacht. Dann ist ja alles i.O.
>> Ich wünsche mir eine Abhängigkeit von
>> der Drehgebergeschwindigkeit. Also langsam drehen 1er, mittelschnell
>> drehen 10er und schnell drehen 100er
> Ja - gut. Das ist jetzt nochmal ganz anders, als wir es bisher hatten.
> Aber
> ich denke, das das vermutlich die bessere Lösung ist. Ich werde mich da
> nochmal dransetzen und das einbauen.
Wäre wahrscheinlich das ergonimische, wenn Du so was einbauen könntest.
Als Alternative und sicherlich einfacher zu implementiren wäre z.B. Push and
Turn :-) Solange Knob gedrückt, wird in 100er oä verstellt.
Mit der aktuellen Lösung komme ich gar nicht zu recht. Was meinen eigentlich
die Anderen?
> Mmmh, ok, das muss ich mir anschauen. Wieder mit srcpd getestet?
Genau. srcpd und Loconet sowie Loopback. Und zwar immer aus dem aktuellen
repisotory.
> Sieht so aus, als es würde es bald eine 1.0.6 geben :)
Freue mich schon aufs Testen.
Gruss
David
Sven Schlender
> Wäre wahrscheinlich das ergonimische, wenn Du so was einbauen könntest.
> Als Alternative und sicherlich einfacher zu implementiren wäre z.B.
> Push and
> Turn :-) Solange Knob gedrückt, wird in 100er oä verstellt.
> Mit der aktuellen Lösung komme ich gar nicht zu recht. Was meinen
> eigentlich die Anderen?
Nur Kurt Harders hat noch einen eWicht. Leider bisher kein Feedback von ihm.
Gruß, Sven.
Sven Schlender
ich muss jetzt nochmal in dieses INIT/GET/SET-Problem einhaken. Ich konnte
heute Morgen ein wenig mit der aktuellsten srcpd-Version rumspielen und ich
finde, dass es immer noch nicht ganz passt bzw. ich es noch nicht
vollständig verstanden habe.
Hier ein Mittschnitt der Session zwischen HyperTerm und srcpd (erstmalige
Initialisierung eines GAs mit Adresse 4)
GET 1 GA 4 0
1250575463.664 416 ERROR no data
INIT 1 GA 4 M
1250575470.852 200 OK
GET 1 GA 4 0
1250575477.883 416 ERROR no data
SET 1 GA 4 0 1 -1
1250575615.508 200 OK
GET 1 GA 4 0
1250575615.523 100 INFO 1 GA 4 0 1
Nach dem INIT des GAs kann srcpd trotzdem keine Daten liefern und bringt
"ERROR no data". Dabei sollte es doch einen Grundzustand geben? Ich muss
entgegen der Spec. erst SET absetzen, bevor der srcpd Daten zu diesem GA
liefert. Wo liegt mein Denkfehler?
Gruß, Sven.
mgr...@snafu.de
wissen, in welcher Stellung der Magnetartikel steht, das ist erst
eindeutig, wenn ein SET Befehl gesendet wurde.
Gruß - Michael
Guido Scholz
> Hi Guido, Hi David,
Hallo Sven,
> GET 1 GA 4 0
> 1250575463.664 416 ERROR no data
>
> INIT 1 GA 4 M
> 1250575470.852 200 OK
>
> GET 1 GA 4 0
> 1250575477.883 416 ERROR no data
hier könnte er allenfalls ein "101 INFO ..." zurückliefern, mehr hat er
zu dieser Zeit ja nicht anzubieten.
> Nach dem INIT des GAs kann srcpd trotzdem keine Daten liefern und bringt
> "ERROR no data". Dabei sollte es doch einen Grundzustand geben? Ich muss
> entgegen der Spec. erst SET absetzen, bevor der srcpd Daten zu diesem GA
> liefert. Wo liegt mein Denkfehler?
Mach doch mal einen Feature-Request für die "101 INFO" auf der
srcpd-Mailingliste.
Guido Scholz
> Am Tue, 18. Aug 2009 um 08:08:14 +0200 schrieb Sven Schlender:
> > Hi Guido, Hi David,
> Hallo Sven,
> > GET 1 GA 4 0
> > 1250575463.664 416 ERROR no data
> >
> > INIT 1 GA 4 M
> > 1250575470.852 200 OK
> >
> > GET 1 GA 4 0
> > 1250575477.883 416 ERROR no data
> hier könnte er allenfalls ein "101 INFO ..." zurückliefern, mehr hat er
> zu dieser Zeit ja nicht anzubieten.
Das war natürlich Unsinn, denn Du fragst ja konkret nach Informationen
von Port 0. Wenn der noch nicht gestellt wurde, gibt es auch keine Daten
zum Abfragen.
Das Abfragen des Protokolls ist wohl nicht vorgesehen, was aber kein
Problem ist, da der Client das selbst gesetzt hat. Sollte ein anderer
Client das Protokoll umstellen, bekommt der erste Client das über den
Info-Kanal per 101-Nachricht mitgeteilt.
Sollte jetzt wohl stimmen.
Sven Schlender
> ich denke das ist so OK, denn woher soll das Programm
> wissen, in welcher Stellung der Magnetartikel steht, das ist erst
> eindeutig, wenn ein SET Befehl gesendet wurde.
Ok - soweit die Realität.
Auch wenn ich nerve, aber ich sehe nicht, wie das alles mit der Spec.
zusammenpasst. Das sollte doch für uns alle der kleinste gemeinsame Nenner
sein.
Laut Spec. gibt es für GAs sehr wohl einen Default bzw. Grundzustand:
The default state of a device is indicated by zero on all ports.
Mir ist klar, dass mindestens ein SET abgesetzt werden muss, damit der
Server synchron mit der Anlage ist. Dennoch müsste er für ein GET nach dem
INIT eine valide Antwort der Form "100 INFO ..." liefern.
BTW: DDW macht es so!
Gruß, Sven.
Guido Scholz
> Hi,
Hallo Sven,
> Laut Spec. gibt es für GAs sehr wohl einen Default bzw. Grundzustand:
> The default state of a device is indicated by zero on all ports.
>
> Mir ist klar, dass mindestens ein SET abgesetzt werden muss, damit der
> Server synchron mit der Anlage ist. Dennoch müsste er für ein GET nach dem
> INIT eine valide Antwort der Form "100 INFO ..." liefern.
Du solltest Dich mit dem Problem mal auf drmb oder der
srcpd-Mailingliste melden.