Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched. Close

GPIO analog

skollmer
2018-10-17
2019-04-14
  • skollmer - 2018-10-17

    Ich versuche 2 Analogwerte mit dem BBB zu verarbeiten.
    Dazu verwende ich Analogwerte 1 und 2.
    Wenn beide Analogwerte aktiviert sind, werden automatisch die Analogwerte von 1 in 2 eingelesen.
    Egal was gemappt ist.
    Gibt es hierzu einen bekannten Fehler?
    Gibt es generell eine Beschreibung zur Analogwertverarbeitung von CodeSys in Verbindung mit den GPIOs?

    Gruss
    Stefan

     
  • eschwellinger

    eschwellinger - 2018-11-02

    Hi Stefan,

    nein bisher nicht, kannst du das mal reporten als Bug - Store my question-> Bugreport
    Grüße
    Edwin

     
  • CellOHorst - 2019-01-02

    Hey!

    Ich hab das exakt gleiche Problem!

    CODESYS for BBB Version 3.5.14 und so auch die IDE.
    Wir machen unser eigenes Linux. Hab eben aber auch mit dem aktuellen Debian für's BBB getestet: gleiches Problem.

    Ich hab einen Druck- und einen Vakuum-Transmitter von Festo.
    Wir haben eine Platine, wo das BBB drauf sitzt - da werden u.a. die 0-10V in 0-1,8V umgewandelt.
    Das funzt soweit, weil ich die 'RAW'-Values lesen kann (cat /sys/bus/iio/devices/iio\:device0/in_voltage1_raw), Quelle: http://processors.wiki.ti.com/index.php ... sers_Guide

    Nichtsdestotrotz bekomme ich im CODESYS lediglich den ersten Sensor angezeigt. Und NATÜRLICH habe ich die GPIO-Parameter von 'not used' auf 'AIN' gesetzt.

    Was liest CODESYS denn tatsächlich aus an der Stelle? Doch wohl nicht die RAW-Werte, oder? Denn: die sind im Standard-Devicetree ja garnicht vorhanden.

    Ich würde gerne Logs beisteuern, aber ich hab keine gefunden, die in irgendeiner Weise das Problem beträfen.

    Viele Grüße,
    Horst Noecker

     
  • eschwellinger

    eschwellinger - 2019-01-04

    Hi,
    ich denke das ist wirklich ein Fehler,
    ich trage dafür einen Bug ein..
    Du könntest natürlich mit dem Chardevice Library die Werte aus deiner Applikation abholen( klar ein nicht wirklich schöner Workaround)
    Ich hatte hier mal ein Beispiel abgelegt:
    l viewtopic.php?f=23&t=6247&start=30#p23176 l

    Grüße
    Edwin

     
  • CellOHorst - 2019-01-08

    Hallo Edwin,

    Danke für Deine schnelle Antwort.
    Das mit dem Character Device ginge - außerdem könnte ich natürlich auch direkt den Wert aus dem SysFS (/sys/bus/iio/devices) aus der Datei in_voltageX_raw auslesen (da stehen die korrekten Werte drin). Also per Sys Process Execute Command 2 (ginge das auf dem BBB? Also - Sys Process Execute Command verwende ich - ob die Funktion ...2 ginge, weiß ich nicht). Hab da Leerzeichen eingefügt, sonst haut das Forum aus irgendeinem Grund den Begriff raus...

    Nachteil beider Methoden ist aber, dass das etwas umständlich und - für meine Belange (besonders der letzte Weg) - zu langsam ist.

    Kannst Du mir evtl. sagen, wie lange es vmtl. dauert, bis sich jemand das angesehen und evtl. gefixt hat?
    Wir haben ein Projekt, bei dem wir dieses Jahr ~500 und ab nächstem Jahr ~1000 Beaglebones mit CODESYS einsetzen werden. Es wäre wirklich gut, wenn wir den Workaround nicht benötigen würden.

    Viele Grüße,
    Horst

     
  • eschwellinger

    eschwellinger - 2019-01-24

    Hi,
    wir versuchen es umzusetzen!
    Grüße
    Edwin

     
  • CellOHorst - 2019-02-07

    Edwin Schwellinger hat geschrieben:
    Hi,
    wir versuchen es umzusetzen!
    Grüße
    Edwin

    Bedeutet für mich jetzt: es ist definitiv ein Bug, richtig?
    Was meinst Du mit 'wir versuchen es umzusetzen'?
    Heißt das, dass Ihr noch überlegt, den Bug überhaupt zu fixen? Oder geht es 'nur' um die Zeit?
    Ich weiß sehr wohl, dass die neuen Kernel, insbesondere 4.19, der aber ja für lange Zeit dass Maß der Dinge sein sollte, viel Arbeit gebracht haben (mir auch).

    Bei uns werden die AINs für Vakuum-Sauger und andere Sensoren verwendet: das Portal saugt ein Teil an und darf erst weiter, wenn ein Schwellenwert unterschritten ist. Das geht ja auch.
    Bisher ist das noch ohne Softmotion, auch, weil ich da ein paar Probleme hatte. Ist auch wurscht an der Stelle, weil 'noch' nicht benötigt.

    Aber: parallel haben wir mehrere andere Analog-Sensoren. Wie geschrieben: parallel.

    Was RT angeht: ich denke, ich hab 'nen guten Jitter: komme so auf 96-120µs - hängt davon ab, wie lange ich warte. Nach ein paar Stunden wird das irgendwie mehr. Wie lange soll man nach einem Reset denn warten?
    Auf der Platine sind Codesys 3.5 SP13, MariaDB 10.3.11 (selber gebacken) und unser Dämon.

    Gruß,
    Horst

     
  • eschwellinger

    eschwellinger - 2019-02-13

    Hi,
    das bedeutet der Punkt ist im Backlog und hat ne Chance auf 3.5SP15 release behoben zu werden.
    Damit wir beide vom selben reden.. hier (Screenshot) in der Konfiguration spezifizieren als In/Out
    und dann in CODESYS IEC Code ganz normal gemappter Analogwert verwenden... das ist der Umfang dieses Punktes.

    Grüße
    Edwin

    IMG: ANA.png

     
  • CellOHorst - 2019-02-15

    Ja, wir reden exakt vom selben.
    So hab ich das ja auch gemacht - das funzt z.Zt. aber halt nur mit AIN0 und nicht mit AIN1-6 zusätzlich.

    Sind Sie auch auf dem User-Treffen in Hannover?

    Viele Grüße,
    Horst

     
  • eschwellinger

    eschwellinger - 2019-02-19

    Hallo Horst,
    ok dann passt es.

    Nein ich bin nicht beim User-Treffen in Hannover,
    aber meine Kollegen.

    Grüße
    Edwin

     
  • eschwellinger

    eschwellinger - 2019-04-04

    Hallo Horst,
    es gibt Probleme bei der Umsetzung dieses Punktes.
    Diese Treiber die es da gibt scheinen nicht korrekt/zuverlässig zu funktionieren.
    Hast du Erfahrung damit, funktioniert der Workaround für dich?

    Grüße
    Edwin

     
  • CellOHorst - 2019-04-14

    Hallo Edwin,

    so, wie es aussieht, kollidiert das Lesen der AIns mit den PWMs im SysFS.
    Als Workaround könnte man die PWMs beim Lesen der AIns kurzfristig deaktivieren und anschließend reaktivieren. Unschön.
    Ansonsten schreibt jemand, dass er es supergut mit den Programmable Realtime Units (PRU) hinbekommen habe: wenn Eure Programmierer das schaffen wäre das super (keine Interrupts, etc.).

    Der Workaround mit dem Character-Device funzt nicht: das liest ein oder paarmal und dann bleibt es auf dem letzten Wert stehen, bis ich das BBB neu starte.

    Gruß,
    Horst

     

Log in to post a comment.