Hinweise zu Bugs und deren Bereinigung
Posted: 09 Aug 2017, 18:16
Im April haben wir das letzte Mal über einige Fehler berichtet. Wir betrachten es als einen wichtigen Teil unserer "Revolution Pi", dass wir mit unserer Community offen und vertrauensvoll auch über die Fehler sprechen, die uns unterlaufen. Daher wollen wir Euch heute wieder einmal einen Bericht zu Problemen und Fehlern geben:
1) Gateway-Module
Einige Kunden hatten im Dauerbetrieb mit unseren Gatewaymodulen Störungen bemerkt. Wir sind diesem Phänomen nachgegangen und konnten letztlich feststellen, dass es unter ganz bestimmten Umständen auf der PiBridge zu Timeouts in der Kommunikation mit Gateways kommen konnte. Wir haben daher den Treiber für diese Kommunikation grundlegend durchforstet und so verändert, dass die Kommunikation mit Gateways nun fehlerfrei funktionieren sollte. Betreiber von RevPi Anlagen mit Gateways empfehlen wir daher dringend ein "sudo apt-get upgrade" auf den Anlagen durchzuführen, damit die neuesten Versionen des Kernel-Pakets auf dem Core laufen. Seit ca. 1 Woche produzieren wir die neu ausgelieferten Geräte mit der neuesten Version der Pakete und auch das Jessie-Image auf unserem Server enthält nun diese neuen Versionen. Ein Update der Gatewaay Firmware, wie ursprünglich mal im Forum angekündigt, war für diese Korrekturen nicht notwendig.
Trotz dieser Änderungen empfehlen wir Dir aus Gründen der Performance dringend. zwei Gateway Module nur mit einem CM3 gleichzeitig zu betreiben. Beim Betrieb von 2 Gateways Modulen am CM1 kann es zu erheblichen Performance-Einbrüchen des Systems kommen.
2) PiCtory
Im neu eingeführten Bereich der "erweiterten Konfiguration" für die virtuellen Geräte "Modbus Master" gab es Probleme beim Löschen von Aufgaben. Auch diese Probleme könnt Ihr mit einem "sudo apt-get upgrade" auf die neuste Version der Pakete vermeiden. Andere berichtete Probleme lagen an Timeouts bei der Kommunikation zwischen Browser und Webserver. Wir arbeiten daran, unseren Webserver performanter zu bekommen, allerdings wird dies dann erst beim einem der kommenden Releases sichtbar werden.
3) Virtuelle Devices Modbus Master / Slave
Leider ist beim letzten Release von Jessie eine Änderung in die Startsequenz hinein gerutscht, die dazu führte, dass Modbus-Master und auch Modbus Slave (virtuelle Module) nicht von alleine nach einem Reset oder Kaltstart gestartet wurden. Du musstest explizit ein "piTest -x" durchführen, um diese Stacks zu starten. Diese Problem wurde durch die neuen Paketversionen bereinigt. Die Stacks laufen nun beim Bootvorgang automatisch hoch, wenn die Dienste dazu von Dir in der Konfiguration aktiviert wurden.
Außerdem gab es Fehler bei der Zuweisung von Coils, wenn Du mehr als 8 "Read single Coil" Aufgaben (Tasks) hintereinander konfiguriert hattest (an Stelle von einem read multiple coil mit n coils). Die Bitwerte wurden dann nicht korrekt ins PA geschrieben. Auch dieses Problem ist mit den neuesten Paketen bereinigt.
4) TeamViewer RevPi
Der von uns angekündigte TeamViewer RevPi wird leider erst seit heute standardmäßig mit dem Image der neu produzierten Geräte ausgeliefert. Wenn Du auf der Web-Statusseite Deines RevPi in der Liste der aktivierbaren Dienste keinen Eintrag für den TeamViewer RevPi hast, dann ist dieser leider noch nicht installiert und muss als Paket nachträglich auf Deinen RevPi installiert werden. Wie Ihr den Dienst auf Eurem Gerät installiert und einrichtet, wird Euch in unserem Tutorialerklärt.
5) Missverständnisse beim Upgrade von Wheezy nach Jessie
Leider haben wir nicht ausdrücklich genug darauf hingewiesen, dass die im Tutorial zum Upgrade angegebene Übernahme bestimmter Dateiinhalte sich wirklich nur auf von Dir selber hinzugefügte Inmhalte in diesen Konfigurationsdateien bezieht. Keinesfalls darf einfach eine komplette Konfigurationsdatei aus dem alten Wheezy System in das neu installierte Jessie System kopiert werden. Wenn man dies zum Beispiel mit der config.txt macht, so werden bestimmte Einstellungen im device tree überschrieben und danach kann der Cryptochip des RevPi nicht mehr ausgelesen werden. Ein Login auf dem Webserver kann dann zum Beispiel nicht mehr durchgeführt werden. Es dürfen also maximal INHALTE solcher Dateien aus den alten Dateien in die neue Datei kopiert werden, die nicht von KUNBUS stammen, sondern vom User hinzugefügt oder geändert wurden. Die Verantwortung für was Du dabei machst, bleibt bei Dir und daher solltest Du schon ein wenig Linux-Kenntnisse mitbringen, wenn Du Dich an so eine Übernahme von Konfigurationswerten wagst.
6) Probleme mit dem Sockel für das Compute Module 3 beim neuen RevPi Core 3
Leider gab es wegen einer nicht vorhersehbaren Materialstreuung vereinzelt bei Kunden Probleme durch Erschütterungen auf dem Versandweg des RevPi Core 3:
Wir hatten dieses Gerät einer Typprüfung nach EN61131 auf einem Shaker unterzogen, bei dem extrem hohe Beschleunigungen und Vibrationen auf das Gerät einwirken. Die getesteten Geräte haben diese Prozedur fehlerfrei überstanden. Da es aber offenbar erhebliche Unterschiede bei den Haltekräten der Sockelklammern gibt, kam es beim Transport der Geräte zu einigen Kunden zu der unangenehmen Situation, dass sich das Compute Module 3 nach vorne aus dem Sockel verschoben hatte oder zum Teil komplett aus dem Sockel gelöst hatte. Um diesem Problem zu begegnen, haben wir als ad hoc Lösung alle Module, die seit 2 Wochen unsere Fertigung verlassen, mit einem 2-Komponenten-Kleber am Sockel fixiert. Zusätzlich haben wir zur Sicherheit die Verklebung der Kühlkörper ebenfalls von Klebefolie auf einen 2-K-Wärmeleitkleber umgestellt. Mittelfristig werden wir eine neue Revision der Hardware auflegen, bei der das CM3 mit dem Basisboard durch Bolzen verschraubt wird.
Wenn Du Dein RevPi 3 Vor Mitte Juli erhalten hast und das Gerät inzwischen im Schaltschrank in Betrieb genommen wurde, so besteht kein Anlass zur Sorge. Im Betrieb treten in der Regel ja nicht die extremen Beschleunigungen auf, die das gerät auf dem Transportweg zu schlucken hat. Wenn das Gerät allerdings schon bei der Inbetriebnahme nicht funktioniert, so hast Du leider sehr wahrscheinlich eines der Geräte mit zu schwacher Halteklammer des Sockels erhalten. In diesem Falle bekommst Du von uns umgehend Dein Gerät ausgetauscht. Im Zweifel solltest Du Dich an den Support von KUNBUS wenden, um Details dazu zu besprechen.
1) Gateway-Module
Einige Kunden hatten im Dauerbetrieb mit unseren Gatewaymodulen Störungen bemerkt. Wir sind diesem Phänomen nachgegangen und konnten letztlich feststellen, dass es unter ganz bestimmten Umständen auf der PiBridge zu Timeouts in der Kommunikation mit Gateways kommen konnte. Wir haben daher den Treiber für diese Kommunikation grundlegend durchforstet und so verändert, dass die Kommunikation mit Gateways nun fehlerfrei funktionieren sollte. Betreiber von RevPi Anlagen mit Gateways empfehlen wir daher dringend ein "sudo apt-get upgrade" auf den Anlagen durchzuführen, damit die neuesten Versionen des Kernel-Pakets auf dem Core laufen. Seit ca. 1 Woche produzieren wir die neu ausgelieferten Geräte mit der neuesten Version der Pakete und auch das Jessie-Image auf unserem Server enthält nun diese neuen Versionen. Ein Update der Gatewaay Firmware, wie ursprünglich mal im Forum angekündigt, war für diese Korrekturen nicht notwendig.
Trotz dieser Änderungen empfehlen wir Dir aus Gründen der Performance dringend. zwei Gateway Module nur mit einem CM3 gleichzeitig zu betreiben. Beim Betrieb von 2 Gateways Modulen am CM1 kann es zu erheblichen Performance-Einbrüchen des Systems kommen.
2) PiCtory
Im neu eingeführten Bereich der "erweiterten Konfiguration" für die virtuellen Geräte "Modbus Master" gab es Probleme beim Löschen von Aufgaben. Auch diese Probleme könnt Ihr mit einem "sudo apt-get upgrade" auf die neuste Version der Pakete vermeiden. Andere berichtete Probleme lagen an Timeouts bei der Kommunikation zwischen Browser und Webserver. Wir arbeiten daran, unseren Webserver performanter zu bekommen, allerdings wird dies dann erst beim einem der kommenden Releases sichtbar werden.
3) Virtuelle Devices Modbus Master / Slave
Leider ist beim letzten Release von Jessie eine Änderung in die Startsequenz hinein gerutscht, die dazu führte, dass Modbus-Master und auch Modbus Slave (virtuelle Module) nicht von alleine nach einem Reset oder Kaltstart gestartet wurden. Du musstest explizit ein "piTest -x" durchführen, um diese Stacks zu starten. Diese Problem wurde durch die neuen Paketversionen bereinigt. Die Stacks laufen nun beim Bootvorgang automatisch hoch, wenn die Dienste dazu von Dir in der Konfiguration aktiviert wurden.
Außerdem gab es Fehler bei der Zuweisung von Coils, wenn Du mehr als 8 "Read single Coil" Aufgaben (Tasks) hintereinander konfiguriert hattest (an Stelle von einem read multiple coil mit n coils). Die Bitwerte wurden dann nicht korrekt ins PA geschrieben. Auch dieses Problem ist mit den neuesten Paketen bereinigt.
4) TeamViewer RevPi
Der von uns angekündigte TeamViewer RevPi wird leider erst seit heute standardmäßig mit dem Image der neu produzierten Geräte ausgeliefert. Wenn Du auf der Web-Statusseite Deines RevPi in der Liste der aktivierbaren Dienste keinen Eintrag für den TeamViewer RevPi hast, dann ist dieser leider noch nicht installiert und muss als Paket nachträglich auf Deinen RevPi installiert werden. Wie Ihr den Dienst auf Eurem Gerät installiert und einrichtet, wird Euch in unserem Tutorialerklärt.
5) Missverständnisse beim Upgrade von Wheezy nach Jessie
Leider haben wir nicht ausdrücklich genug darauf hingewiesen, dass die im Tutorial zum Upgrade angegebene Übernahme bestimmter Dateiinhalte sich wirklich nur auf von Dir selber hinzugefügte Inmhalte in diesen Konfigurationsdateien bezieht. Keinesfalls darf einfach eine komplette Konfigurationsdatei aus dem alten Wheezy System in das neu installierte Jessie System kopiert werden. Wenn man dies zum Beispiel mit der config.txt macht, so werden bestimmte Einstellungen im device tree überschrieben und danach kann der Cryptochip des RevPi nicht mehr ausgelesen werden. Ein Login auf dem Webserver kann dann zum Beispiel nicht mehr durchgeführt werden. Es dürfen also maximal INHALTE solcher Dateien aus den alten Dateien in die neue Datei kopiert werden, die nicht von KUNBUS stammen, sondern vom User hinzugefügt oder geändert wurden. Die Verantwortung für was Du dabei machst, bleibt bei Dir und daher solltest Du schon ein wenig Linux-Kenntnisse mitbringen, wenn Du Dich an so eine Übernahme von Konfigurationswerten wagst.
6) Probleme mit dem Sockel für das Compute Module 3 beim neuen RevPi Core 3
Leider gab es wegen einer nicht vorhersehbaren Materialstreuung vereinzelt bei Kunden Probleme durch Erschütterungen auf dem Versandweg des RevPi Core 3:
Wir hatten dieses Gerät einer Typprüfung nach EN61131 auf einem Shaker unterzogen, bei dem extrem hohe Beschleunigungen und Vibrationen auf das Gerät einwirken. Die getesteten Geräte haben diese Prozedur fehlerfrei überstanden. Da es aber offenbar erhebliche Unterschiede bei den Haltekräten der Sockelklammern gibt, kam es beim Transport der Geräte zu einigen Kunden zu der unangenehmen Situation, dass sich das Compute Module 3 nach vorne aus dem Sockel verschoben hatte oder zum Teil komplett aus dem Sockel gelöst hatte. Um diesem Problem zu begegnen, haben wir als ad hoc Lösung alle Module, die seit 2 Wochen unsere Fertigung verlassen, mit einem 2-Komponenten-Kleber am Sockel fixiert. Zusätzlich haben wir zur Sicherheit die Verklebung der Kühlkörper ebenfalls von Klebefolie auf einen 2-K-Wärmeleitkleber umgestellt. Mittelfristig werden wir eine neue Revision der Hardware auflegen, bei der das CM3 mit dem Basisboard durch Bolzen verschraubt wird.
Wenn Du Dein RevPi 3 Vor Mitte Juli erhalten hast und das Gerät inzwischen im Schaltschrank in Betrieb genommen wurde, so besteht kein Anlass zur Sorge. Im Betrieb treten in der Regel ja nicht die extremen Beschleunigungen auf, die das gerät auf dem Transportweg zu schlucken hat. Wenn das Gerät allerdings schon bei der Inbetriebnahme nicht funktioniert, so hast Du leider sehr wahrscheinlich eines der Geräte mit zu schwacher Halteklammer des Sockels erhalten. In diesem Falle bekommst Du von uns umgehend Dein Gerät ausgetauscht. Im Zweifel solltest Du Dich an den Support von KUNBUS wenden, um Details dazu zu besprechen.