Hallo,
das mit dem Firmware Update ist nett, aber es ist Anstrengend wieder die ganzen Adressen neu in der LC3 eintragen zu müssen. Dadurch das ich jedes Modul einzeln die FW aufspielen muss und dann wieder alle in der alten reinfolge einsetzen muss ist ja nicht das Problem. Das eigendliche Problem ist das sich der Adressbereich wieder einmal geändert hat.
hatte ich in der alten Config die Aressen
angefangen mit DIO 1 I1 AT %IX1.9.0 so in der Globalen liste bei LC3 so hat sich dieses auf DIO 1 I1 AT %IX1.11.0 geändert. Was bitte schön soll das? Ich kann doch nicht immer wenn ein Firmwareupdate kommt die ganzen Adressen in der LC3 ändern.
..
was für eine Erklärung gibt es da nun wieder? Ich habe an der Hardwarconfig nichts geändert. weder Module hinzugefügt noch anderst Platziert. Alles ist so wie immer
Core V1.2
DIO Module 2
Virtuelles Modul 1
Mod Master und Slave
Hallo Ingo,
erst einmal wundert es mich, dass Du ein Update auf allen IO Modulen gefahren hast. Warum? Hattest Du EMV Probleme? So weit ich weiß doch nicht. Also hatten Dich doch die Änderungen gar nicht betroffen. Es gab von uns keine generelle Empfehlung, dass jedermann seinen Modulen ein Update verpassen soll. Uns ist eigentlich nur ein einziger Kunde bekannt, der die beschriebenen Probleme hatte, weil er mit den DIO extreme induktive Lasten über Schütze im selben Schaltschrank geschaltet hatte.
Wie auch immer, das andere Problem, welches ich sehe, besteht darin, dass Du offenbar nicht wie von uns in den Tutorials empfohlen Deine IOs in PiCtory mit einem sinnvollen symbolischen Namen versehen hast, der dann ja auch unter LC3 Verwendung findet. Es macht eben wenig Sinn, mit Adressen zu arbeiten, eben genau deshalb, weil sich diese bei einer geänderten Konfiguration (und dazu zählt natürlich auch eine geänderte Firmware) ändern können. Wenn jeder Ein- und Ausgang einen sinnvollen Namen verpasst bekommt ("Pumpe_3", "Temp_Vorlauf", etc.) dann sind 1) die Programme unter LC3 leichter lesbar und 2) Adressänderungen sind dann von LC3 Programmen völlig unabhängig. Natürlich können Änderungen in der Konfiguration dann immer noch Anpassungen in PiCtory erforern, aber eben nur dort und nicht etwa in LC3.
Viellecht solltest Du diese Erfahrung zum Anlass nehmen, dass Du die Defaultnamen in PiCtory gleich beginnst sinnvoll umzubenennen und diese Namensänderungen dann in LC3 mit globaler Suche und Ersetzen ebenfalls einpflegst. Dann sind künftig keine Anpassungen mehr in LC3 notwendig, sondern es muss nur einfach die geänderte Globals Deklaration importiert werden und die alte Deklaration ersetzen.
Und was bitte ist das Problem mit der geänderten Globals Deklaration " I1 AT %IX1.9.0", die nun bei Dir "I1 AT %IX1.11.0" heißt? Du importierst diese geänderte Globals Deklarationen und gut ist. Genau dafür sind ja diese Importwege da. I1 bleibt I1 und in Deinem LC3 Programm brauchst Du rein gar nichts ändern. Nur der Zugriff erfolgt auf andere Bytes und Bits im PA und dies wird durch die Globals Deklarationen gesteuert. Wo genau ist da das große Problem? Das geht doch alles mit LC3 mit wenigen Mausklicks.
Zu Deiner Frage: Die 3 Byte Unterschied in der Adressierung kommen durch zusätzliche Bytes, die der Core bereitstellt, in denen wichtige Informationen abgelegt sind. Ich vermute daher, dass Du sehr wohl die Konfiguration in so weit geänert hast, dass zuvor eine ältere Core-Version in PiCtory stand. Mit den Firmwareupdates hätte dann dieses Problem so oder so nichts zu tun.
Sorry Volker,
1. ich habe Symbolische Namen in der Pictory vergeben, also kann es daran ja nicht liegen.
2. soll auch ein Frequenzumrichter noch in den Schrank. Und bevor ich diese Probleme habe wollte ich es gleich umgehen mit dem Update. ist ja Logisch oder.
3. wenn ich die Datei exportiere, habe ich die Adresse ja mit in der Liste. Aber wenn ich diese nicht brauche und nur den Namen, dann ist klar das es so einfacher ist und ich nicht immer diese anpassungen machen muss. Warum schreibt ihr dann diese überhaupt mit und nicht nur die Symolischen Namen? Wenn ich die Adresse überhaupt nicht in der LC3 brauche.
Hallo Ingo,
also ein moderner Frequenzumrichter ist in der Regel sicher kein Problem für die DIOs mit der alten Firmware, weil e keine induktive Spitzenlat darstellt, wie ein schaltender Schütz, der hohe induktive Lasten an- und ausstellt. Aber egal, die Updates hast Du ja inzwischen eh gemacht.
Wegen des Ex- und Imports nach LC3 in ih mir nicht sicher, ob wir an einander vorbeireden: Was genau hast Du denn immer gemacht, wenn Änderungen in PiCtory stattgefunden haben? Du hast geschrieben "es ist Anstrengend wieder die ganzen Adressen neu in der LC3 eintragen zu müssen". Wo in LC3 hast Du diese Adressen eingetragen und wie hast du das denn gemacht?
Eiegntlich ist der Weg jener, dass die Adressen nur an einer einzigen Stele in LC3 auftauchen und das ist die Globals Deklraration. Aber genau die musst Du nicht manuell selber schreiben oder anpassen, sondern eben diekt aus PiCtory importieren. Das kannst Du so oft wie Du willst machen - also auch imme dann, wenn in PiCtory sich die Konfiguration geändert hat. Unter jessie geht das sogar ganz ohne Kopie über die Zwischenablage inach nur mit "IO Konfiguration übernehmen" im Projektexplorer von LC3 (siehe Tutorial dazu hier in unserer Plattform). Also nru zwei drei Mausklicks. azu muss natürlich er RevPi und das System, auf dem Du mit LC3 programierst, in demselben Netz sein. Aber das ist ja eh eine Grundvoraussetzung, wenn Du den RevPi irgendwie konfigurieren oder programmieren willst.
Vor Jessie war es nicht wesentlich schwieriger. Man musste dazu in PiCotoy die globals-Datei per Export erzeugen und den Inhalt in die Zwischenablage legen. Dann im LC3 Editor die vorhandene Globals Deklaration einfach mit dem Inhalt der Zwischenablage überschreiben.
das Problem ist ich habe für jedes Modul eine eigene Variablen liste, also 4 an der Zahl. Ich habe diese lieber getrennt als alles in einer, ist übersichtlicher für mich.
wenn ich nun unter pictory sage er soll es in die lc3 übertragen dann nimmt er alles und schmeisst sie in eine liste oder sehe ich das falsch. Daher dieser Aufwand.
wegen dem FU, ok kann sein das es funktioniert, aber es ist kein kleiner der nur einen motor von 0,75KW oder so schalten soll es handelt sich schon um einen der mit 3,5Kw arbeitet und da weiß ich nicht ob es dort zu problemen kommen kann.
Klar es gibt leute die machen das jeden tag da es ihr job ist sich mit sowas auseinander zu setzten, aber vergiss nicht ich bin privat mann und muss das erst alles selber testen. wenn es klappt ok wenn nicht dann muss ich einen anderen weg gehen, also habe ich dieses update gleich gemacht, ist ja nicht tragisch.
Die Sache ist ja schon gegessen und es funktioniert auch wieder so wie es soll.
