Beiträge von marcoboy

    Ich muss hier einmal etwas Wasser in den Wein giessen: Kein Mensch vor Ort hat die Zeit und die Muße, sich mit derartiger Befehlszeilenlutscherei zu beschäftigen.

    Dann hast du das Prinzip einer RESTfull API nicht verstanden ;). Ist aber nicht schlimm, das UI -> User Interface ist damit offen. Jeder kann den Controller benutzen wenn seine Software in der Lage ist mit HTTP umzugehen. Du brauchst auch keine Software mehr installieren, ein Browser mit Javascript reicht aus. Hier kann man sogar mobile Geräte berücksichtigen usw..


    Durch die Open API können also auch Hersteller sich eigenen Anwendungen basteln oder den Controller in ihrer Software integrieren.. Schau dir das Beispiel mit Node RED an :), das könntest du mit anderen Konzepten nicht machen.


    Mir der "Befehlszeilenlutscherei" hast du nichts zu tun, das mit Javascript und erzeugt daraus HTML Code 8o..

    Oder der Controller läuft als Backend und oben drauf ein GUI... Oder die Geräte lassen sich per IOT steuern, z.bsp Alexa etc... Gemeinsamer Punkt ist die RESTfull API und die muss durchdacht sein. Die Struktur wird in soweit angepasst das der Client keine Kenntnis von dessen haben muss, er folgt einfach links -> HATEOAS



    Der Xmos Stack ist angeblich zertifiziert. Ich kenne die Kriterien nicht, vermute aber das sich diese er auf den Stream bezieht bzw. grundlegende Eigenschaften.


    Verständlicherweise kann ich mir nicht jedes Gerät kaufen und untersuchen :/. Bin aber offen wenn mir jemand etwas zur Verfügung stellt. Mein Controller Projekt kann aber ein wertvolles Tool dafür werden :). Durch die Open API könnten sich Hersteller eigene Scripte zum testen ihrer Geräte basteln...

    Warum ? Also ich hatte noch kein Gerät in der Hand welches den Standard erfüllte. Es sagt ja niemand das es nicht funktioniert. Laut Standard wäre es kein Problem Hersteller A mit B zu verbinden und es zu steuern. Nur halten sich die Hersteller mehr oder weniger nicht an den Standard. Das führt dann dazu das du zwei Controller Applikationen benötigst oder auch drei .... usw.


    Außerhalb von AVB haben andere Protokolle auch kein Problem mit der Switch..


    Es gibt ja nicht mal einen Controller der den Standard 100% unterstützt.. Aber daran arbeiten wir bereits 8o. Ich würde mich auch um die Switch kümmern , nur habe ich nur ein Hirn und zwei Hände.

    ja auch das Kommando write_descriptor funktioniert :) ... der base64 String "AA4AAQAAAAAAAAAAAAEAAAAAAAAADg=" ist ein descriptor ;)


    Die Response zeig ich aber nicht an, da das Kommando als nicht erfolgreich zurück kam. Laut Standard müsste es die aktuellen Daten zurück liefern -> da das aber kaum einer macht zeige ich sie lieber nicht an :/..

    So was neues :) Ich bin fast durch mit dem AECP Kommandos.. Ich habe alle

    Security Kommandos umgesetzt ! Somit ist dies der ein zigste Controller der das überhaupt unterstützt. Die Tokens bzw. KEYs müssen als base64 übergeben werden -> https://de.wikipedia.org/wiki/Base64 ... Da die Daten wie schon erwähnt nicht in UTF8 oder reservierte Zeichen enthalten... Ich habe den Xmos Stack so erweitert das dieser mir mit gültigen Daten Antwortet .. Leider ist auch in Wireshark an der Stelle einiges durcheinander geraten :( ..


    https://www.base64decode.org/ -> eG1vcyBmcmlzdCBrZWluZW4gYmFzZTY0IEd1cmtlbnNhbGF0 zum decodieren...


    Die Controller Values nehme ich auch als base64 entgegen und gebe sie so zurück. Wenn man 400 Werte mit value=10&value=1.... füllen muss wird das dann doch doof.


    Anbei habe ich mal einen Rasbpery Pi und Node Red probiert etwas zusammen zu basteln.. Um einfach mal zu schauen wie gut oder auch schlecht sich das Json verarbeiten lässt... Der Flow fragt ein Value ab und steuert abhängig des wertes eine LED :) ...




    Das hat in der IEEE1722.1 auch seinen Grund. Denn das Format ist bei dem CMD Control GET/SET wird nicht als Parameter übergeben. Um das Format heraus zu bekommen muss man in den Control Descriptor schauen.


    Damit ist auch klar das es eigentlich keine andere Möglichkeit gäbe die Daten beim Empfang ohne Kenntnis des Descriptors zu entschlüsseln. Also kommt das als byte Array zurück..


    Was für ein Gerät auch nicht schlimm wäre, denn wenn man was setzen will kennt man auch das Format ;) ...


    Ich habe jetzt zwei Möglichkeiten, entweder es den Anwender es zu überlassen die Daten so zu arrangieren und diese mir byte weise zu übergeben. Doch Vorsicht ! Ich bekommt die als String UTF8 Kodiert, reservierte Zeichen müssen entwertet werden. Json ähnlich.. Oder den Type auf Binär setzen...


    So ich habe das schon so einfach gemacht das man anhand des Formates die Values anhängt und somit das schieben entfällt.


    Man stelle sich einen Fader vor und der Client müsse die Daten so aufarbeiten.. Keine wirklich Lösung...


    So da bin ich fertig *lol* sämtliche Formate lassen sich jetzt dezimal eingeben ! Allerdings bei der Antwort muss ich noch was umstricken so das man Parameter mit übergeben kann. Der Count der Formate wird auch geprüft :)


    Das mit dem Parametern kann man auch in der REST Auflösen --/{entity_id}/{command}/{desc_type}/{desc_index}/{format}?value=1.999&value=-10.2

    Ja im Grunde geb ich dir recht.. Das spielt keine Rolle da das CGI Modul und der Controller auf der selben Maschine laufen. Alles was auf das Netz geht ist klar definiert nach IEEE sonst würdest du den String auch nicht lesen können ;)


    In C ist das Wurst und das umformen kann Problem mit Unions machen -> 32bit rein float raus :)


    Wenn du mir das float oder double übergibst muss ich das prüfen denn du kannst mir ja so etwas 1.1999929999299999999299999922229299929 übergeben .. geht noch weiter .... bis die zahl in China wieder raus kommt...


    Ich denk darüber nach... was ich vermeiden will das es zu einer unklaren Durchmischung kommt, gerade was die Parameter betrifft. value=hex&value=dezimal


    Ja soll offen sein unter welcher Lizenz ist noch unklar...

    Noch ein Beispiel mit welchen Problem man zu tun hat...


    Die Control values haben ein Format welches im entsprechenden Descriptor beschrieben ist. Dort sind Unterschiedliche Typen (8,16,32,64,float,double..) beschrieben... Beim setzen spielt das Format keine Rolle und taucht auch nicht im Command auf. Das führt dazu das man das Value nicht mehr anzeigen kann, auch nicht schreiben.. Ich muss ja wissen wie es sich byte weise zusammensetzt. Das steht im Descriptor und dann muss man sich die zahl HEX 0x5566 -> value[0]=0x55,value[1]=0x66 zusammen schieben.


    So wer jetzt noch mitkommt probiere das jetzt mit float oder double -> bitte.... kleiner Tip https://de.wikipedia.org/wiki/Gleitkommazahl


    So ein Käse unzumutbar...


    Ich stehe jetzt zwischen Baum und Borke.. Alle meine Values zeige ich HEX an, warum ? Bei einer Typen sicheren Programmiersprache wie Java weniger ein Problem, aber unter C will man schon wissen welcher Wert einen erwartet. 0x00 Bit 0x0000 16 Bit -> nächstes Problem MAC Adressen 0x11777277773 ist was völlig anderes als 11:77:72...


    Würde ich jetzt den Control Wert Dezimal entgegen nehmen würde ich das Prinzip verlassen :(.. Macht es aber einfacher für den Anwender, oder man muss im Client den HEX wert umformen. Irgend wie trotzdem doof... Nunja selbst EQ werte lassen sich setzen ...


    Hier mal ein String .... Anhand des Formates wird das dann korrekt an den Controller übergeben..

    Ist das nicht genau das was auch als Seminar hier angeboten wird ? Die Frage ist eben was man von solch einen Tag erwartet ? Geht man von unterschiedlichen Wissen der Teilnehmer aus wird es schwierig die Erwartungen zu erfüllen.


    Sich ein paar blinkende Ports anzuschauen ist nicht sehr Informativ :/..

    Das Ziel ist in der Version 1.0 kein halbfertiges Produkt zu liefern wie andere eben, deswegen der Fokus erstmal auf ein funktionierendes Back-End..


    Mir wäre es lieb wenn die Oberfläche jemand anderes macht zur gegeben Zeit...


    Denn ich habe was anderes vor da ich in Xmos keine Zukunft sehe.. einen eigenen AVB Stack auf ARM oder RISC-V.. Das letzte lockt mich 8o Wenn Muttis Breitband auch mal bei mir ankommt können interessierte ohne AVB Netzwerk das Projekt auch testen ...

    Das geniale ist ja daran das die eigentliche sprach Wurst ist .. ob Javascript,Java,nodeJs,PHP,Go oder sonst was alle können mit HTTP umgehen und auch mit Json...


    Das mit der Oberfläche dauert aber... im Kern des Controllers sind noch viele Baustellen. Aber mit der Oberfläche wird es dann leichter da man sich dann nur noch Gedanken machen muss wie man die Daten zur Verfügung stellt.


    Setzt die Konfiguration auf 3 mit python :huh:, ohne Kenntnis von AVB lassen sich somit andere Anwendungen bauen ... Unter der Haube unterstützt der Controller schon alle AECP Kommandos.. Das Aufwändige ist aber das darstellen in Json und RET API. Controller und fastcgi Modul sind zwei Programme, man könnte auch ein MQTT Modul andocken.. Was aber kommen wird ist ein Proxy wie dieser im Standard beschrieben ist. Somit ergibt sich eine einheitliche Schnittstelle.

    Huhu ... so das Konstrukt REST API steht... Die Ressourcen lassen sich über den Path erreichen und mit dem HTTP Methoden abfragen bzw. beeinflussen :) Man kann sogar eine LED auf dem Board schon steuern :). Allerdings hatte der Xmos Stack noch einen Bug mit der Paket Länge, mir fraglich bei einen zertifizierten code, der alles ander als 1772.1 konform ist. Immer mehr muss ich im Stack die Dinge gerade biegen. Damit habe ich das Gefühl das die Firma Xmos den Code schon aufgegeben hat, die letzte Änderungen war vor zwei Jahren.


    Ich habe mir mal zum Entwickeln der REST API ein anderes Tool besorgt als den Browser. Man kann hier auch die API Dokumentieren und natürlich testen, viel besser als mit dem Browser..


    Erstmal funktioniert das nur im body nur als "application/x-www-form-urlencoded".. Da query die Daten sowie so als Json benötigt -> auch dann "application/json"..


    Hierzu muss aber erstmal ein stream basierten Json parser bauen und nicht alles in den speicher zu laden :/ -> dauert...

    So ich habe die Jsons noch mal optimiert. Das RAW Value wird jetzt nur noch als String angezeigt. Der Rest wird dann aufgelöst. Der "Rohwert" in sofern nicht unbedeutend wenn man etwas setzen möchte. Z.bsp die Samplingrate welche sich in ein Pull Feld zusammensetzt... So muss der Anwender das nicht zusammenbasteln , er kann gleich das gewünschte Value aus dem supported Feldern aufnehmen und setzen.


    Video und Sensor Units werden nun auch voll unterstützt, der Support anderer Controller hört genau dort auf :/..

    PIN 7: mit Signal: ca. -8,5V Autsch ...


    Das ist das was ich vermute eine Seite ist Platt oder der Arbeitspunkt ist durch einen defekt verschoben.


    Ich wird den OPV nicht entfernen, der ist wahrscheinlich noch der Sargnagel...


    Spannung an Pin 5 u. 6 gegen Masse ?

    Anbei mal ein Beispiel wo der Riedel controller seine grenzen hat.


    Da wo es erst wird kommt nur murks raus... Offenbar so sehr das hier Array grenzen ungeprüft verlassen werden...


    Anbei mal meine response :) und die von wireshark als Beweis..


    Das Object "value" wird so wieder aufgenommen und per PUT Methode zurück gesendet. Damit man auch was verstellen kann :P..


    *json ist leider kein gültiges Format .. man kann das auch hier https://jsoneditoronline.org/ einfügen und und sich durch die Objekte arbeiten ;)

    Bei Reichelt wird deine Kundennummer gelöscht, wenn du nachweisen kannst das sie dir billige Kopien verkauft haben.


    Das ist bei der Tante Reichelt aber so gewollt, für 99% der Kunden reicht es und bei diesem zählt nur der Preis...


    Also ich würde nie auf die Idee kommen dort Leistungsbauelemente zu kaufen. Selbst ICs oder Spannungsregler. Das Zeug taugt nachweislich nichts.


    In dem Fall hier ist es Wurst denn sie sind nicht besser als das was dort schon verbaut wurde.


    Wenn man sich die Sache genauer anschaut kommt man zum Schluss -> billiger kann man das nicht bauen :D. Die LED dürfte bei dem Murks auch nicht lange halten und diese sind vermutlich auf eine Alu PCB gelötet. Der Bauer macht das mit dem 100W Lötkolben da er sonst keine Chance die teile nur irgendwie auf die PCB zu bekommen.


    Ich durfte mal solche Scheiben nach löten sich sie auch immer aussetzten, teilweise liegt wie oben schon erwähnt an dem Bonddraht.. Mal mechanisch drücken dann sieht man ob sie wieder an geht :D Mit Glück sind es nur die Lötstellen vom Bauer..


    Ich sag es aber gleich, du hast das gleiche Problem ohne Vorheizplatte aber das kennst du ja schon mit den FETs :/

    Bei ebay kauft man keine FETs :/ zumindest wenn man ein Interesse hat das einen das Zeug nicht um die Ohren fliegt.


    Mal die Leistungswiderstände prüfen ! Wenn einer hochohmig ist denkt der Treiber IC -> Überstrom.. Der Sollwert lässt sich mit dem Poti sicherlich einstellen und dieser wirkt auf dem "RESET" Der Sollwert kommt Analog (PWM) oder auch 0---10V ! möglich weise hat die PCB auch einen Strobeeingang, der direkt auf dem RESET wirkt.


    Was mich wundert die PCB besitzt keine Drosseln ?

    Halli Hallo -> Statusmeldung :)


    Das meiste an dem AECP Teil wurde umgesetzt, was fehlt ist alles das wo man den Controller als Payload Values übergeben muss. HTTP Methode PUT, der Anhang im Body wird wohl ein Json sein und zwar der Teil der als Value hier im Bild zu sehen ist.


    Das dumme daran war das es keinen Sinn macht solche Daten zu senden wenn sie nicht ein mal angezeigt werden. Also wurde der Control Descriptor komplett aufgelöst -> nochmal 80 Seiten die diesem Beschreiben !


    Da kein Gerät solche Fähigkeiten besitzt habe eins bauen müssen :/..


    Was man sehr schon sieht ist wie das ganze von statten geht.


    control_value_type beschreibt den type der Values

    control_type -> was es zu steuern gibt

    signal_type -> von wo das Signal kommt


    der Rest erklärt sich.. außer der "string" das ist der String Descriptor wo der String(Zeichenkette) liegt die das Value beschreibt. Sieben bedeutet -> NO_STRING.


    Der MAC machte dabei keine gute Figur, nach und nach stellte sich heraus das vieles nicht wie gewollt funktioniert. Teilweise kommt auch Daten Müll zurück.