Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 11 bis 20 von 30

Thema: Eigener AMS/ADS Client

  1. #11
    Neals ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    24.04.2008
    Ort
    Lübeck
    Beiträge
    324
    Danke
    8
    Erhielt 64 Danke für 62 Beiträge

    Blinzeln


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von MarkusP Beitrag anzeigen
    Viel Spaß noch!
    Darum geht es mir in erster Linie ausserdem lerne ich dabei noch was und vielleicht kommt am Ende ja sogar was ganz gutes dabei rum.

    Beispiele:
    Wenn ich einen Server habe, möchte ich da ungerne eine Echtzeitinstanz drauf installieren. Meine Software ist unabhängig von jeglicher Beckhoff-Installation. Ausserdem hat ADS ziemliche Schwierigkeiten mit Routing, was durch die Kapselung in TCP erledigt ist. Ich kann meinen Client erweitern und zusätzliche Funktionen einbauen, bin nicht mehr eingeschränkt durch die Beckhoff-Dll. Baue meine dll modular auf, das man auch ein Server implementieren könnte. Da bei Beckhoff alles auf ADS aufbaut, habe man ja extrem viele Möglichkeiten damit zu arbeiten. Die ADS Bauteile sind alle inklusive und kostenlos. Kann mir sehr leicht mit Hilfe der Datei nen Proxy zwischen z.B. ADS und ner Datenbank bauen. Dann könnte ich aus der SPS über ADS auf meine Datenbank zugreifen, lesen, schreiben. Mir fällt da viel ein was ich damit machen könnte.

    Warum baut ihr denn den OPC Server, den gibts doch schon: TwinCAT OPC Server.

  2. #12
    Registriert seit
    13.01.2007
    Beiträge
    304
    Danke
    35
    Erhielt 29 Danke für 25 Beiträge

    Daumen hoch

    Find' ich schon gut, dass es immer noch Idealisten wie Dich gibt, die auch noch des Spaßes wegen so was auf die Beine stellen!

    Den OPC-Server machen wird deshalb, da ich beim Beckhoff OPC einiges vermisse, das ich von früher verwendeten Servern kenne, aber nicht missen möchte. (Inbetriebnahmetools, Debugging, Fehlerprotokollierung etc.) Und laut Google, gibt es für Beckhoff (via ADS wohlgemerkt) keinen anderen OPC-Server! Also müsste da doch "internationaler" Bedarf bestehen....

    An Deiner Lösung hätte ich auch Interesse, vielleicht können wir uns ja austauschen?

    Schönen Tag noch

  3. #13
    Neals ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    24.04.2008
    Ort
    Lübeck
    Beiträge
    324
    Danke
    8
    Erhielt 64 Danke für 62 Beiträge

    Standard

    Habe jetzt was vorläufiges fertig.
    Aber ganz nett: Habe ne Methode geschrieben, mir der sich Routen auf Geräten eintragen lassen, ist ganz Hilfreich, wenn man kein TwinCAT hat
    Wer sich das mal ansehen will, schickt einfach seine Mailadresse per PM an mich und ich schick ihm das Programm.

    Habe noch Probleme bei Notifications:
    Ich habe ja jetzt alles Synchron gemacht, zB:
    Schicke Packet Read, warte auf Eingang von Daten, auswerten und zurückgeben.

    Die Notifications kommen jetzt ja zwischendurch, entweder schreibe ich den kompletten Client Multithreaded, dann müsste man mit jeder Funktion nen Callback mitgeben, ein Thread der durchgehend eingehende Daten ließt und danach dann den richtigen Callback feuert. Das währe eh der nächste Schritt gewesen, wenn alles synchron läuft, jedoch sollten die synchronen Methoden eigendlich bestehen bleiben.

    Mir fällt keine Art ein, wie ich in den synchronen Client die Notifications einbauen soll.
    Geändert von Neals (29.10.2008 um 14:14 Uhr)

  4. #14
    Registriert seit
    14.08.2004
    Beiträge
    824
    Danke
    45
    Erhielt 73 Danke für 66 Beiträge

    Standard

    Richtig, du musst den synchronen Teil, vom asynchronen Teil trennen. Ist leider nicht anders zu machen. Irgendwie überschneiden sich dabei die Klassen.

    Code:
    Variable ---> Int ----> Access Async 
                           ----> Access Sync
    Variable ---> Byte ----> Access Async 
                            ----> Access Sync
    Massiver Threadeinsatz ist eigentlich nur bei der Kopplung Programm-Twincat gefragt. Mit async-Logik braucht es eigentlich keine weiteren Threads. Das hat auch später im Anwenderprogramm Vorteile, weil man da dann nicht bei den Controls darauf Rücksicht nehmen muss.

  5. #15
    Neals ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    24.04.2008
    Ort
    Lübeck
    Beiträge
    324
    Danke
    8
    Erhielt 64 Danke für 62 Beiträge

    Standard

    Jetzt ist auch eine Implementierung für UDP eingebaut, damit ist man nicht mehr auf TCP beschränkt... Nachteil an der Sache ist, das ich den Port von TwinCAT verwenden muss. Um an die eingehenden Daten zu kommen, muss also TwinCAT aus sein... deswegen überlege ich die UDP Lösung raus zu nehmen.

    Sorry Frog, aber irgendwie hab ich nicht ganz verstanden wie du das meinst...

    Ich muss ja einen Thread haben, der durchgehend Empfängt und guckt ob ne Notification da ist. Hatte überlegt, bei ner Anfrage den zu blockieren und Synchron weiter zu arbeiten. Dann sende, Daten empfangen, wenns ne Notification ist, Event feuern und nochmal empfangen... wenn Daten da sind, verarbeiten, ausgeben, Thread wieder starte.
    Geändert von Neals (29.10.2008 um 21:11 Uhr)

  6. #16
    Registriert seit
    14.08.2004
    Beiträge
    824
    Danke
    45
    Erhielt 73 Danke für 66 Beiträge

    Standard

    Eine Notification arbeitet doch so, dass du eine Msg. von der SPS bekommst. Eigentlich braucht es nur einen Thread, der die Variablen aktualisiert.

    Ansonsten wärst du gezwungen, für jede Notification einen Thread aufzumachen. Das dumme dabei ist, dass dann auch bei der Programmierung der GUI nicht einfach losprogammiert werden kann, sondern da bestimmte Regeln eingehalten werden müssen. Bisher habe ich mich darum drücken können, aber wenn man auf VS2008 schaut, wird das bestimmt nicht mehr möglich sein.

  7. #17
    Registriert seit
    22.11.2007
    Beiträge
    731
    Danke
    6
    Erhielt 89 Danke für 62 Beiträge

    Daumen hoch

    ich würde erstmal folgende einschränkungen machen:

    pro thread nur eine synchronaktion - d.h. dein read, write oder notify ist blockierend

    jeder thread braucht eine "connection" zu deinem receiver_thread

    connection
    buffer: answer_data
    event: answer_received

    mit irgendwas in deinen empfangsdaten musst du die connection(client)
    eindeutig identifizieren und zuordnen - damit du den answer_received.event der entsprechenden connection triggern kannst

    also in der art

    communicator::
    receiver_thread
    {
    buffer: data;
    while ( true )
    {
    dein_ADS_receive( data );

    // informieren die entsprechende connection
    map[ data.key ].anwer_data = data;
    map[ data.key ].answer_received.set(); // feedback an den client
    }
    }

    dann kannst du schön waitforsingleobject - or whatever auf antworten für deine "connection" warten - das reduziert die menge der freifliegenden callbacks

    connection = communicator::connect();

    read_var test_read( connection, "welche var" );

    test_read.request();
    --> schickt die anfrage über die leitung
    --> (merkt sich im sender_thread das nachricht erwartet wird)

    test_read.wait( timeout );
    --> wartet darauf das connection.answer_received
    durch den reciver_thread signalisiert wird

    x = test_read.value();

    mit einer notifiy koennte es so aussehen

    notifiy test_notfy( connection, "auf was auch immer" );

    test_notify.start();

    while( test_notify.wait() )
    {
    x = test_notiy.value();

    test_notify.stop(); // nur einmal erwarten
    }

    communicator::disconnect( connection );

    und die Anbindung an ein GUI(Konsolen) System würde ich dann darauf setzen weil das gibts viele Wege - Windows Messages, COM, QT-Slots usw.

    desweiteren hast du dann in der basis eine voll mach-dein-threading-selber system das zum benutzer hin leicht auf synchrone konstruktionen ala

    read_synchron( connection, var )
    {
    read_var var( connect, var )
    var.wait();
    }

    verbogen werden kann

    hoffe mein c++-java-pascal-artiger pseudocode ist nicht zu verwirrend
    Zitieren Zitieren ich würdes es möglicherweise so machen  

  8. #18
    Registriert seit
    14.08.2004
    Beiträge
    824
    Danke
    45
    Erhielt 73 Danke für 66 Beiträge

    Standard

    Warum sollte man mehrere Threads aufmachen, wenn einer reicht? Sobald etwas über den die Verbindung hineinkommt und es gibt nur eine(!), müssen die entsprechenden Variablen ein Update erfahren. Hätte es pro Variable eine Verbindung gegeben, wäre ein Thread pro Variable sinnvoll gewesen.

  9. #19
    Registriert seit
    22.11.2007
    Beiträge
    731
    Danke
    6
    Erhielt 89 Danke für 62 Beiträge

    Standard

    Ich hab ja auch nicht über den Teil gesprochen den der Benutzer in
    die Finger bekommt - eher den Aufbau der dahinterliegenden Kommunikationsschicht - um seine (a)synchron Aktione besser(leichter) implementieren zu können ohne eine Callback-Party zu starten

    noch dazu ist er dann freier in der Anbindung andere System z.b. VB würde sicher von einem COM-Frontend profitieren, QT denke eher an einer SLOT integration - und in der Konsole gibts das alles nicht - da hätte ich eher gern so einen Wait-Mechanismus

    und das schöne daran ist - deine Anforderung oder Idee lässt sich damit genauso implementieren

    ciao LowLevelMahn

    BTW:

    die connection ist keine ADS-Verbindung sondern eher ein Identifikationshandle für die client(read,write,notify) <-> receiver_thread Kommunikation
    wobei Client auch wieder ein grosses Wort für ein Trivialding ist

    und noch was: bist du dir bewusst das über den receive viele verschiedene pakete kommen, d.h. unsortiert read- und write-request antworten durchmischt mit notifies?
    Neals Problem ist das er gerne ein Verhalten in der Leitung hätte als würde alles synchron ablaufen (vereinfach die Implemtierung sehr sehr stark) - aber trotzedem nicht die
    asynchronen sachen wie die notifies (die einfach so zwischendurch das plappern anfang) mit wilden orgien da reinzupfuschen

    mein Ansatz verändert mal primär das Verhalten so das sich die einzelnen Funktionen nur mit ihren Aufgaben beschäftigen müssen - von was du spricht ist schon ein Treppenstufe weiter oben

    @Neals
    wie kannst du die Pakete eindeutig Identifierzen ( also z.B. das Paket gehört zu Read1, das zu Write2 usw.)?
    und unter welchem System entwickelst du gerade? Windows, WinAPI, C/C++
    Geändert von LowLevelMahn (30.10.2008 um 12:17 Uhr)
    Zitieren Zitieren ich weiss schon was du meinst  

  10. #20
    Registriert seit
    14.08.2004
    Beiträge
    824
    Danke
    45
    Erhielt 73 Danke für 66 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Eine Callback-Party braucht es auch nicht, wenn die Bibliothek die Werte der Variablen updatet. Ich mache es jedenfalls so mit meiner Lib.

    Die Kunst besteht eher darin, die Verbindung nach einem Abbruch (wegen Kabel etc) abzubauen und wieder aufzubauen, damit der PC nicht irgendwann stehenbleibt. Du brauchst eine Liste oder ähnliches, in der die Daten zu allen Variablen gespeichert werden. Der Kommunikationsthread sorgt dann für den Abbau und den Neuaufbau.

    Und COM benötigt man eigentlich kaum, denn .Net bietet soweit alles. Nur 1 oder 2 Interfaces müssen definiert werden.

Ähnliche Themen

  1. SINUMERIK 840D eigener Text-Editor
    Von bit_schubser im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 21.04.2010, 16:47
  2. WinCC 6.2 Server/Client Bedienung nur Client
    Von Jens Qualmann im Forum HMI
    Antworten: 2
    Letzter Beitrag: 22.08.2008, 19:06
  3. eigener Hilfetext in STEP7 Bibliothek
    Von Anonymous im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 09.05.2007, 12:33
  4. Eigener Bereich Antriebstechnik
    Von Maxl im Forum Stammtisch
    Antworten: 8
    Letzter Beitrag: 17.02.2006, 01:55
  5. Erstellen eigener log. Bausteine
    Von Manticor im Forum Simatic
    Antworten: 12
    Letzter Beitrag: 11.07.2004, 11:09

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •