Hallo Falk,
speckenbuettel hat geschrieben: ↑Sa Nov 12, 2022 8:03 amdas wichtigste zuerst: ich hoffe du hast Covid gut überstanden? Für "gute Besserung" ist es jetzt wohl zu spät - hoffe ich?
Danke, noch ein klein wenig Postcovid mit müdigkeit, ansonsten geht es wieder. Kann schon langwierig sein, sowas.
speckenbuettel hat geschrieben: ↑Sa Nov 12, 2022 8:03 amIch finde es nur weiterhin merkwürdig dass ich eine neue Transaktion mit 10 Bit anlegen konnte, in der voreingestellten Transaktion aber diese Auflösung nicht auswählen konnte. Daher bin einfach nicht auf die Idee gekommen, eine neue Transaktion anzulegen.
Klar, die Oberfläche hat die andere Einstellung ja auch angeboten, was der Fehler ist (also die alternative Einstellung anzubieten, obwol die Backend-Software das gar nicht umsetzen kann).
speckenbuettel hat geschrieben: ↑Sa Nov 12, 2022 8:03 amZusammenfassend scheint es also so zu sein, dass eine einmal angelegte Transaktion nicht mehr geändert werden kann. Sondern nur eine neue Transaktion angelegt und dann die alte gelöscht werden kann. Ist das so beabsichtigt?
Jein, nur wenn dadurch ein Wechsel des 1-Wire Bausteines ansteht.
Ich sollte das besser erklären.
In der 1-Wire Technologie gibt es den alles steuernden Master und die Slaves (heutezutage würde man diese Begriffe nicht mehr wählen).
1-Wire Slaves sind Bausteine von Analog Devices (eigentlich von Dallas Semiconductor erfunden, die wurden dann von Maxim Integrated aufgekauft und Maxim wurde nun wiederum von Analog geschluckt) die - abgesehen von einem Prozessor - über fest verdrahtete Funktionen verfügen.
Auf Multisensoren - wie hier dem Kabelmessfühler - werden zwei 1-Wire Slaves gleichzeitig benutzt.
1 x DS18B20, das ist ein präziser Temperatursensor, der eine Genauigkeit besser 0,5 K aufweist (typisch eher 0,1 K) und in der Auflösung von 9 bis 12 Bit eingestellt werden kann
1 x DS2438, der drei AD-Wandler enthält und ebenfalls einen Temperatursensor, mit einer "Genauigkeit" von nur 2K und einer festen Auflösung von 13 Bit
Das 1-Wire System im Hintergrund agiert mit den einzelnen Chips entsprechend deren Protokoll und der Scheduler führt die vom Kunden angelegten Aufträge aus.
Uns hat diese Slave-zentrische Sichtweise nicht gefallen, weil der Kunde kauft ja ein Gerät und aus wievielen Slaves das besteht, sollte er nicht wissen müssen. So wie bei KNX, da muss man ja auch nicht wissen, wieviele Chips mit welchen Funktionen dort eingebaut sind, sondern man nimmt die Applikation in der ETS und wählt die Parameter und Objekte aus, die man nutzen möchte.
Wir wollten das also entsprechend nachbilden und haben für unsere Geräte in der Software hinterlegt, aus welchen 1-Wire Slaves diese besteht. Der Kunde sollte das so gar nicht sehen (nur im Slave Manager). Wie bei der ETS Applikation wählt man nur den Wert aus, den man haben möchte.
Der Punkt hier ist, dass die Backend Software, wenn der Kunde einmal einen Wert ausgesucht hat, der von einem der beiden Bausteine kommt, nicht mehr umschalten kann auf den anderen Baustein.
Hinsichtlich der Temperatur bedeutet das, dass wenn man 13 Bit gewählt hat, dann nutzt die Software für diese Transaktion nun den DS2438. Bei einer Auswahl von 9 bis 12 Bit, müsste auf den Baustein DS18B20 gewechselt werden, das kann der Scheduler aber halt nicht (es muss eben für jeden möglichen Fall auch die passende Routine enthalten sein in Software).
Darum: Wir werden das Frontend umbauen (oder haben schon), dass es nicht-mögliche Auswahlen nicht mehr anzeigt. Auch die Fehlermeldung wird verbessert. Man muss dann eben eine weitere Transaktion anlegen, was ja nicht so schlimm ist.
lg
Stefan
wie soll ich mich jetzt da freundlich ausdrücken? 
