J-Log.eu - Forum

OK, Stephan, aber was soll ich da machen?

Der Sensor antwortet, wenn der Empfänger seine Adresse anfragt, Binär- oder textuelle Adresse, and that's it.

Was immer der Sender da treibt, ich sehe im Augenblick keine Möglichkeit, das zu beeinflussen.

Was natürlich sein könnte, wäre, dass sich der Sender nicht die Adressen merkt, die er während seines Sensor Scans sah (der hält 16s an), sondern nur die, die er, sagen wir mal, innerhalb der ersten Sekunde antworten sah.

Dann würde das mit JLog natürlich nicht funktionieren.

Man könnte dazu einen Test machen: JLog ohne SD starten oder bereits unter Spannung haben, bevor der Empfänger seine sieht. Oder Sender aus/an.
Tritt der Vergesslichkeitseffekt dann nicht mehr auf, dann isses das.

Ich würde mal gern dem Typen bei SJ die Löffel langziehen, der den ganzen Sensor Detection Scheiß verbricht. Da sind soviel Bugs drin! Alleine das Selektieren eines Sensors mit dem linken Touch Pad is 'ne Challenge, auch nach Ablauf des Scans. Probier' das mal, wenn alle 5 Sensortypen da sind. Da passiert nur Mist. Man selektiert den falschen Sensor, weil er einem in der letzten Millisekunde unter dem Cursor wegrutschte. Man schaffte es, den gewollten zu selektieren, geht in ein Sub Display von ihm, - und landet in einem anderen Sensor.

Der dafür verantwortliche Pfuschkopp hat offenbar nicht einen Sensor-Selektionsstatus, sondern viele in seiner Firmware, die miteinander konkurrieren.
Was aber viel "verabscheuenswürdiger" ist: Es wird ganz offenbar nicht getestet!

_________________
Tom

OH man, da habe ich ja was losgetreten, aber danke das Du immer noch Gehirnschmalz in die Sache steckst. Es liest sich so, als hätte sich eine Menge Frust aufgebaut. Schade, dass der Kontakt zwischen Dir und Ralf nicht mehr so ist, wie er wohl einmal war.

Noch eine Erläuterung zum Thema aus dem Graupner Forum, das kann ich übrigens bestätigen:

Wenn man die Ansagen programmiert und abgerufen hat, dann Sender und Modell ausschaltet, Sender wieder einschaltet (NICHT das Modell!) und den "Nächste Ansage"-Hebel betätigt, dann ist sie noch gespeichert! Schaltet man nun das Modell ein, verliert der Sender erst die Einstellungen.


Folgendes versuche ich jetzt mal zu testen:

Man könnte dazu einen Test machen: JLog ohne SD starten oder bereits unter Spannung haben, bevor der Empfänger seine sieht. Oder Sender aus/an.
Tritt der Vergesslichkeitseffekt dann nicht mehr auf, dann isses das.


Danke Tom

Mein Verhältnis zu Ralf ist bestens.

"Frust".. Es nervt einfach so langsam, aber eben über alles, alleine, was mich Futaba schon für Zeit kostete. Das Komische ist, dass immer der Bock zum Gärtner gemacht wird. Immer ist der Leidtragende schuld, verantwortlich, Heilung zu finden, fehlende Dokumentation zu ersetzen etc.pp. Und was erntet er dafür? Nur Häme.
Na ja, ich gebe ja zu, dass mir diese ganzen Naseweisen in all den Foren hochgradig auf den Zeiger gehen.
Es ist wirklich schlimm teilweise, aber komischerweise nur in den deutschsprachigen Foren und nicht überall dort.


Das läuft doch so, auch vor der MZ schon:
Sieht der Sender den Empfänger wieder, löst er den Start des Sensor Scans durch den Empfänger aus. Es ist also egal, ob Sender aus/an bei laufendem Empfänger oder Empfänger ein, wenn Sender schon an war.

Und was tut er dann (der Sender), wenn der Scan gestartet wurde? Er löscht erst mal alle Sensoren, die er in der letzten Session kannte. Bis dahin merkt er die sich (blöderweise), in der Hoffnung, sie in dieser Konstellation wiederzusehen.
Zweck der Übung ist offenbar, sich das letzte Binärdisplay merken zu können im Sender, es beim Wiedereinschalten wieder zu bringen (der User muss nicht erneut erst selektieren), und es dann wieder zu befüllen, richtig flüssig aber erst nach Ablauf der 16 Sekunden Sensor Scan.

Nur hat der Implementator der MZ Software hier offenbar einen gedanklichen Fehler gemacht. Er löscht jetzt auch die gespeicherten Ansageeinstellungen von Sensoren, die in einer nächsten Session nicht mehr da sind. OK.., ich finde ja, die SJ-Menschen sollten sich nicht mit so einem Schickmick befassen (und dabei weitere Bugs produzieren), sie haben genug zu tun an den Fehlern von davor, - wenn sie sie denn mal durch Testen bemerken würden. Leider sind ja Asiaten auch nicht gerade "kommunikativ", siehe auch Futaba.. Außerdem fehlt immer noch Essentielles, ein Idle Line Protocol auf dem Bus, z.B.

Der Fehler ist offenbar, dass er das Löschen vornimmt, bevor er überhaupt einen neuen Status hat, der Scan abgeschlossen ist.
Das ist es, was ich oben meinte: Seine State Machine stolpert über ihre eigenen Füße. Ist der Programmierer vielleicht ein Fan von Walter Ulbricht, indem er dessen "Überholen ohne einzuholen" versucht?

_________________
Tom

Schade, meine SD-Karte hat es gerade erwischt - Schluss mit testen. Da muss ich Morgen erstmal eine neue besorgen.

Na da hat SJ ja noch einige Hausaufgaben zu machen - Ärgerlich. Mal gucken ob sich zumindest Graupner nochmal dazu äußert.

Sorry wegen meiner Annahme, dass das Verhältnis zu Ralf nicht mehr so gut ist, das habe ich dann wohl rein interpretiert.

Schönen Dank und angenehmen Abend noch.

Graupner kämpft auch, SJ in die richtige Ecke zu bugsieren.

Das ist doch die Heldentat von Ralf. Er tat das Richtige für Graupners Arbeitsplätze, verschaffte dabei SJ einen potenten Markt. Eine Hand wäscht die andere. Das heißt aber nicht, dass er deren Arbeitsstil maßgeblich beeinflussen könnte. Auf der anderen Seite kann man aber die bisherigen Ergebnisse auch nicht als schlecht bezeichnen. Da hat Futaba verhältnismäßig viel Schlimmeres abgeliefert, obwohl man eigentlich anderes erwarten sollte.

Der Steller BLC+T, übrigens, ist nicht von SJ, wenn auch ebenfalls von einer Koreanischen Firma. Sprich, der Designer des BLC+T ist hinsichtlich von HoTT auch nur ein Applikator.

In meinem Kopf: Graupner == Ralf == Solidarität und Achtung vor seinem logistischen Einsatz. SJ == anonymes Ding für mich.

--------
Weg von Politik und Emotionen zur eigentlichen Sache: Der Sender sollte nicht vor Abschluss des Scans, - der stattfindet, sobald ein Wiedersehen zw. Sender und Empfänger erfolgte, - einen Sensor als "nicht wiedergesehen" markieren, denn das führt offenbar dazu, dass die Selektion für ständige Ansage gelöscht wird.

Für mein Gefühl tobt sich der Designer seit geraumer Zeit viel zu viel mit solchen "intelligenten Sachen" aus, als hätte er sonst nichts zu tun. Im Ergebnis, Sensor Scan und jetzt das on top, darauf fußend, schaftt er nur künstlich Probleme dadurch.
Anders gesagt: Wenn man nicht bereit ist, zu testen, ob man es richtig machte, hätte man es besser erst gar nicht getan.

_________________
Tom

Ich habe seit neuestem auch eine MZ-24 und habe mal ein paar Tests gemacht. Die gute Nachricht: Schaltet man die Stromversorgung des Modells ein, wartet bis der Jlog vollständig initialisiert ist (grüne und gelbe Leds flackern), und schaltet erst danach die MZ-24 ein, vergisst der Sender die Ansagen nicht.
Auf der MZ-24 habe ich die aktuelle Software 1.019, auf dem Jlog allerdings eine ganz alte JLog2_3.2.2BID_H4-34.22.bin. Wartet man das Initialisieren des Jlog nicht ab, vergisst die MZ-24 die Ansagen wie im Thread beschrieben.

Eine neuere Jlog-Version will ich nicht einspielen, da ich die Robbe-Bid-Chips angeschlossen habe, und dies bei neueren Versionen -leider, leider- nicht mehr unterstützt wird. Für neuere Versionen kann ich daher keine Aussagen machen.

Einen Bug der MZ-24 habe ich allerdings auch noch entdeckt: Im Ansagen-Menu des GAM (bei mir ist der Jlog wegen der alten Version noch ein GAM) kann man die Ansage für die Restkapazität (Treibstoff) nicht einschalten, da sie gar nicht angeboten wird. Entweder ich übersehe, wie man auf eine weitere Auswahlseite oder ähnliches wechselt, oder der Programmierer hat es schlicht vergessen. Hat hier jemand noch einen Tipp?

Viele Grüße
Peter

Hi Peter!

Das heisst: Bug. Wg. der Ansagen müsste die Firmware erst abwarten, was der Sensor Scan ergibt (16 Sekunden). Stattdessen guckt sie offenbar sofort, ob der Sensor da ist. Der Programmierer fährt, wie vermutet, zweigleisig, und sein neues Gleis (Ansagen-Config) ist das falsche!

BID: Mal sehen.. Wenn, dann ginge ja nur JLog2+JSend, wenn man nicht löten will.

_________________
Tom