Flush - Funktion, Datenbank füllen und Realtimemodus

[RHH]

Hallo zusammen,

ich verwende PL erst seit wenigen Tagen, d. h. ich bin relativ neu hier, und muß zu aller erst ein riesen Kompliment an Abacom aussprechen und das exzellente Preis – Leistungsverhältnis der Software(n) (von Abacom) loben. Ich kenne als Alternative zu PL, LabView was natürlich für keine Projekte völlig überzogen, meiner Meinung nach aber auch mittlerweile zu stark überladen und natürlich auch nahezu unerschwinglich ist (für kleine Firmen und für Privat).

Ein paar Anregungen für künftige Upgrades habe ich aber trotzdem (soll aber keine Kritik sein)

Nach ersten Erfahrungen mit der seriellen Schnittstelle (...mein Beitrag im Forum) vermisse ich eine Art „Flush“ – Funktion für den Schnittstellenpuffer. Unter VB kann ich mit derartigen Funktionen den Puffer von Datenmüll (irgendwelchen Resten o. ä.) befreien. In PL hab ich keine Ahnung wie man das realisieren kann.

Als weitere Anregung würde ich gerne empfehlen eine Datenbankschnittstelle zu realisieren. Z. B. ADODB – Connection ähnlich wie unter VB für Access Datenbank oder das Einbinden eines ODCB – Treibers z.B. für MySQL. Es könnten dann Messwerte direkt in eine Datenbank geschrieben werden. Ich verwende diese Funktionalität sehr oft.

Unklar ist mir auch noch, ob es bei PL eine Art „Realtimemodus“ gibt. D. h. wie verhält sich PL wenn in einer Timerzeit z. B. monostabile Kippstufe mit 100ms Impulszeit, plötzlich Windows Aktivitäten startet. Welche Priorität haben die Zeitglieder in einer PL – Anwendung gegenüber dem Betriebssystem, könnte man hier evtl. Betriebssystemaktivitäten für zeitkritische Anwendungen zurückstellen? (ähnlich z. B. OP100 bei Simatic oder REALTIME unter VB)

Danke für’s evtl. Feedback hierzu

Gruß
RHH

[irrerpolterer]

Hallo RHH!

Du hast schnell die Vorzüge und Grenzen von PLE ausgelotet.

Kleine Tips:
Für Deine Datenbankanbindung der Meßwerte: Du kannst zur Laufzeit den Inhalt einer Tabelle (Funktionsblock Tabelle) immer als *.xls-Datei abspeichern. Per Excel-Makro paßt Du die Datensätze an und kannst Sie in Deine Datenbank importieren.

RS232: Warum immer die RS232 hänge ein anschauliches Projekt an. Es enthält die Rückkoppelung, die Abtastung und die Übernahme des RS232-Empfangs in die Tabelle. Ich habe das ganze verfeinert und fünfmal umgeschrieben. Deswegen ist nur noch diese Version selbsterklärend. Wenn ich sende, muß ich warten, dann empfangen, dann verzögert den Empfang in die Tabelle schreiben und mit den Wartezeiten die Wiederholungen ausschließen oder absichtlich einfangen. Beim Loggen mußt Du die falschen Werte (unplausibel) auch noch aussortieren mitm Komparator. Das passiert, wenn Windows Deine PLE runtime mal unterbricht und utopische Werte auf einmal in der Tabelle stehen. Ich töte nach dem Erkennen der kompletten Hardware alle ungenutzten Windowsservices und dann passiert das sehr selten. Echtzeitfähigkeit ist immer unter Windows nur begrenzt möglich. Siehe Simulationsfrequenz/Optimierung als eigener thread.

Grüße

[RHH]

Hallo "polterer"

danke für dein Feedback.

Über Excel oder über LOG-Files (txt-Files) die Daten in eine Datenbank bringen ist mir schon bekannt, nur wenn man eine Anwendung für den "Nur Anwender" erstellt sollte das automatisiert werden, denn das wird sonst meistens nichts. Ich persönlich habe über diesen Umweg nichts einzuwenden. Ich denke da mal, wenn ich super viel Zeit habe, über eine selbstgemachte dll nach (nur die Zeit und die notwendigen Nerven hab ich im Moment nicht, und mit dll für PL hab ich auch null Erfahrung)

RS232 ist immer noch ein Standard bei Messgeräten und Industrieanwendungen. USB ist für die Home- und Mulitmedia- Hobbyanwender. Windows hat auf USB viel zu viel Eigendynamik, d.h. es wird da ständig vom System rumgemacht ohne dass man es merkt oder weis (Beschreibungen sucht man vergebens dazu) Ich hätte auch kein Problem mit GBIP (Messtechnikstandard) Denke das wäre auch noch ein mögliches Upgrade für PL.

Das mit der Echtzeit wollte ich nur informativ wissen, eben wie sich PL in Verbindung mit Windows verhält. Ein Echtzeitsystem ist immer relativ, in VB gibt es die Möglichkeit das System nahezu auszuknipsen (aber nur sehr kurz < 1 Sekunde sonst gibt es evtl. Bluescreen ) LabView bietet dies auch an, aber so was ist immer nur sehr kurz möglich, auf Dauer geht das nicht. Windows kann schon mal locker für 500ms den Rechner blockieren, interessant wäre da zu wissen was PL in dieser Zeit macht. Das war meine eigentliche Frage. Ich habe meinen Ursprung mitunter in der Regelungstechnik und da weis man, dass man einen PC mit Windows höchstens für eine Füllstandsanzeige in Echtzeit verwenden kann ...also Messzyklus > sek. Windows mit PL, oder LabView oder VB ist für mich immer nur die Userschnittstelle und der Datenspeicher (mit Visualisierung o. ä.) Zeitkritische Anwendungen oder sichere Prozesse erhalten bei mir immer einen eigenen externen DSP (ADWin - Karte oder so ...Zykluszeiten <1ms)

Danke für dein Beispiel, ich werde es mir in Ruhe mal angucken.

Gruß Roland

[irrerpolterer]

GPIB als DLL existiert schon siehe

viewtopic.php?f=31&t=787&hilit=Gpib

viewtopic.php?f=31&t=749&p=751&hilit=GPIB#p751

Bitte wegen den Details fragen, muß selber wieder eine Testpoint-runtime mit GPIB-Interface zum Laufen bringen oder per PLE neu schreiben. Auf Wunsch verschicke ich die DLL auch per Email.

Zeitkritische Anwendungen:
Idealerweise funktioniert es ganz ordentlich mit PLE und vor allem wegen 1/2 Jahr Erfahrung mit PLE. Ich kann binär die Schaltzustände und mit dem GPIB-Bus prima den Druckwert von 10 Druckschaltern (alle immer gleicher Druck) loggen. Obwohl einige innerhalb einer Sekunde schalten und trotzdem meine Anwendung dies auch mit unterschiedlichen Druckwerten erfasst.

Ansonsten verlasse ich mich auf SPS. Ich habe heute gehört wie es gut mit Labview geht: Ein PC für die Realtime-runtime und ein zweiter für die Visualisierung des Projekts. Dann rennt die Anwendung richtig


Grüße