serielle Schnittstellen gleichzeitig bedienen

[NoCee]

Hallo zusammen,

ich habe folgendes vor:
Mehrere Maschinen mit einer seriellen Schnittstelle schicken meinem Programm (Win-PC) mit einem speziellen festen seriellen Protokoll
irgendwelche Daten. Mein Hauptprogramm stellt die Daten in einem Fenster dar. Mein Programm kann auch Daten an die Steuerungen
zurück schreiben. Es werden ca. 7 serielle Schnittstellen bedient (RS232). Die Komunikation zu den Geräten möchte ich selber schreiben.
Das ganze ist eigentlich recht lahm, 1200 bzw. 2400bd.

Mit 1 Schnittstelle seh ich da eigentlich kein Problem (ich möchte da Synaser nutzen). Aber, wie geh ich da grundsätzlich vor,
wenn ich das für mehrere Schnittstellen gleichzeitig machen möchte.
1 Hauptprogramm ist klar, darüber findet die Interaktion mit dem User statt
aber wie mach ich das mit dann 7 Schnittstellen?
Möglichkeiten die ich zusammengegoogled habe, aber noch nicht mal sagen kann ob das auch so tut sind:
- Die Schnittstellen in jeweils eigenen Thread auslagern
- Schnittstellen ständig pollen (im Hauptprogramm, dann darf aber nichts blockierend sein)
- Schnittstellen in DLL auslagern
- Treiber schreiben
- fertige Hardware kaufen, die aus mehreren seriellen Telegrammen/Schnittstellen über die Firmware ein TCP/IP Telegramm macht ->LNet
- oder noch andere Möglichkeiten, die ich noch nicht kenne

In welche Richtung sollte ich mich da orientieren, damit das funzt, außer Arbeit nichts kostet und mir nicht ständig irgendwelche Daten der seriellen Telegramme verloren gehen.
Das ganze sollte von einem Anfänger auch beherschbar bleiben. Treiber für Win schreib ich dann mal wenn ich groß bin.
(von Threads, DLLs und Treibern hab ich bisher eigentlich nur eine wage Ahnung)

Danke schon mal für eure Antworten

Gruß
NoCee

[af0815]

Mal mit einem Programm und einer Seriellen beginnen. Das Programm kann ja auch 7 mal mit verschiedenen Comports aufgerufen werden.

Das ganze dann wenn nötig in Threads auslagern kann man immer noch.

[pluto]

7 Programme offenzu haben, wäre keine Schöne Lösung in diesen Fall. ich denke: Wenn Möglich sollte es EIN Programm sein, was 7 Thread nutzt.

Ob das geht weiß ich nicht, aber ich könnte es mir vorstellen.

[mse]

Da hier das Wort Lazarus nirgendwo vorkommt, wage ich darauf hinzuweisen, dass MSEgui Komponenten zur asynchronen RS232 Kommunikation mittels threads und zum Bau von seriellen Protokollen besitzt. Sie sitzen in der MSEide im tab 'Comm'.
Die Kommunikationsevents werden dabei automatisch mit dem Hauptthread synchronisiert.

Martin

[af0815]

Da hier das Wort Lazarus nirgendwo vorkommt,..

Es steht aber auch irgends das er die Entwicklungsumgebung wechseln will.

Langsam gehen mir die Querverweise auf eine andere Plattform auf die Nerven. Ich verweise auch nicht dauernd, wie gut das alles mit dem Visual Studio unter C# zu lösen wäre. Okay ich entwickle auch das Studio nicht.

Ontopic:
Der Vorschlag mit einer Seriellen und einem Programm deshalb, damit sich NoCee in die Materie einarbeiten kann. Wenn die Kommunikation mit einer Maschine funktioniert und auch optisch so okay ist, so kann man immer noch das auf mehrere Maschinen umbauen. Zumindest den Wunsch habe ich aus der Problemangabe herausgelesen (Orientierung und für Anfänger beherschbar).

[mse]

Falls NoCee die Fortsetzung nicht gesehen hat, die ist hier:
http://www.lazarusforum.de/viewtopic.php?f=53&t=5712

Vor allem:

die Frage war, ob ausser Synaser noch weitere Methoden zur asynchronen seriellen Kommunikation mit mehreren RS232 Ports zu empfehlen sind. Ich habe auf diesem Gebiet viel Erfahrung und könnte noch mehr dazu beitragen, wenn ihr etwas netter wärt.

Martin

[mschnell]

Ich habe auf diesem Gebiet viel Erfahrung und könnte noch mehr dazu beitragen, wenn ihr etwas netter wärt.

Kannst Du Unterschiede und Gemeinsamkeiten zwischen mse-Comm und AsyncPro erläutern ?

Wenn ich das richtig sehe ist bei beiden die Grund-Idee gemeinsam:
- eine Objekt pro serielle Schnittstelle zu instanziieren
- jede Instanz erzeugt sich einen oder mehrere Threads zur "blocking" Kommunikation mit dem Treiber des Serien-Ports
- die Schnittstelle der Instanz Richtung User findet im Kontext des Mainthreads (mit zwischengepufferten Daten) statt, so dass das Hauptprogramm sich um Threads nicht kümmern muss.

Bei AsyncPro kann man statt serieller Schnittstelle mit demselben User-Interface auch TCP-Ports behandeln. Das finde ich ziemlich genial ! Man könnte das vermutlich problemlos auch noch für Pipes erweitern !

Gibt es irgendein prinzipielles Problem, mse-Comm in einem Lazarus Projekt zu benutzen ?

Wäre es sinnvoll, mse-Com in ein Lazarus-Paket einzubetten, das sich (wie AnsycPro in Delphi) auch "grafisch platzieren" lässt ?

Gruß und Dank,
-Michael

[mse]

Gibt es irgendein prinzipielles Problem, mse-Comm in einem Lazarus Projekt zu benutzen ?
Wäre es sinnvoll, mse-Com in ein Lazarus-Paket einzubetten, das sich (wie AnsycPro in Delphi) auch "grafisch platzieren" lässt ?

Bitte eröffne einen neuen Thread im MSEide+MSEgui Forum.

[NoCee]

Hallo zusammen,
war leider eine ganze Zeit lang ziemlich ausgelastet und deswegen nicht da.
Auf alle Fälle mal dank für die Antworten.
Hat ja gleich eine nette Diskussion gegeben. Wenn auch nicht sonderlich ergiebig für mein Vorhaben.
Die Info von mse fand ich jetzt nicht unbedingt schlecht. War kurz, hat mich aber beim Besuch der Vorstellung des Projekts im Net richtig
Zeit gekostet. Hab ich nicht gekannt, und war dann halt neugierig. Die Info kam aber zu spät, ich hab mich eigentlich auf Lazarus eingeschossen.

Ich werd das jetzt in beschriebener Weise angehen. 1 Com ohne Threat, 1 Com in eigenem Threat und dann das mal 7.
Alleine das Protokoll zu implementieren beschäftigt mich warscheinlich sowieso ziemlich lang.

Ich hab jetzt noch was gelesen. Ein Softwarehaus das solche passenden Treiber verkauft, hat das in eine DLL gepackt.
Was ist einfacher, oder besser, DLL oder Threat?
(Aus der Sicht eines Laien betrachtet der beides nur vom Höhrensagen kennt)

Gruß
NoCee

[MAC]

hallo, du meinst wohl einen thread oder ??
wenn ja, das ist von "multi-threading" hergenommen also z.B: dual oder Quad-core Prozessoren zu nutzen.
Weiterer Vorteil, mehrere Dinge Gleichzeitig durchzuführen, Nachteil: synchronisation.
Eine Dll ist grundsätzlich was ganz anderes, es ist ein "Teil-Programm" welches selbsständig programmiert ist. Es ist sozusagen eine 2te Unit welche aber fertig Kompiliert ist so das du den Quellcode nicht mehr ändern, aber benutzen kannst...
Es kann sein das diese Dll Threads verwendet, muss aber nicht...
Also ich würde dafür nicht allzuviel Geld ausgeben (ist das eigentlich notwendig ? (Ich habe es ohne gepackt NXT und Computer zu verbinden und so den NXT fernzusteuern, hab dafür auch ne art "protokoll" geschrieben gibts hier irgendwo im forum ich müsste aber mal wieder die aktuellste version hochladen...))

[mse]

Ich werd das jetzt in beschriebener Weise angehen. 1 Com ohne Threat, 1 Com in eigenem Threat und dann das mal 7.
Alleine das Protokoll zu implementieren beschäftigt mich warscheinlich sowieso ziemlich lang.

Ich hab jetzt noch was gelesen. Ein Softwarehaus das solche passenden Treiber verkauft, hat das in eine DLL gepackt.
Was ist einfacher, oder besser, DLL oder Threat?
(Aus der Sicht eines Laien betrachtet der beides nur vom Höhrensagen kennt)

Threads: Falls du threads nur vom Höhrensagen kennst, solltest du für den Anfang wirklich entsprechende Komponenten verwenden welche einige Stolpersteine aus dem Weg räumen können. Einen diesbezüglichen Tip hast du ja bereits erhalten.

DLL: Die DLL, die du im Auge hast, macht genau das was du brauchst? Dann arbeitet sie möglicherweise ebenfalls mit threads.

Martin

[NoCee]

klar mein ich einen "thread" hab ich weiter oben ja auch so geschrieben.

Das Problem ist, daß die Partnergeräte ein gewisses Timing des Protokolls erwarten, also Verarbeitung aller Schnittstellen quasi gleichzeitig.
Da vermute ich, das da threads angesagt sind. In die Richtung werd ich das jetzt mal treiben.

Übrigens:
Die Softwarehäuser die das anbieten lassen sich das richtig gut zahlen, 500-1000€
Aber gut, wenn ich davon leben müßte, würde ich das vermutlich auch.

Danke für die Hilfe
Gruß
NoCee

[af0815]

Schau dir mal synaser an.

Lazarus Wiki: http://wiki.lazarus.freepascal.org/Hardware_Access/de
Synaser (Kurz)Doku: http://synapse.ararat.cz/doc/help/synaser.html

Ev. kannst du mit dem Minimalbeispiel schon was anfangen.

Vielleicht kannst du mal etwas erklärern zu dem festen, speziellen Protokoll. Ich habe da schon einiges in der Maschinenbau Branche erlebt

[mschnell]

Threads: Falls du threads nur vom Höhrensagen kennst, solltest du für den Anfang wirklich entsprechende Komponenten verwenden welche einige Stolpersteine aus dem Weg räumen können.

Ohne Threads ist die Aufgabe kaum zu lösen. Mit Threads ist es ziemlich anstrenegend, vor allem, wenn man keine Erfahrung mit Thread-Programmierung hat. Deshalb bin ich ja so begeistert von AsyncPro, das die ganze Thread-Komplexität intern macht und nach außen nur "normale" Main-Thread-Events generiert.

Ich mache solche Sachen immer mit mit AsyncPro (momentan gerade das katastrophale Protokoll, mit dem man sich mit einem GPRS-Modem im Multiplex-Modus unterhalten muss).

(Mein <hier verbotener> Tip ist also Asyc-Pro mit Turbo-Delphi, solange sich nicht jemand erbarmt und z.B. die mseCom nach Lazarus portiert.)

Wenn Du es aber selbst machen willst, würde ich es so anfangen (nicht trivial aber auch kein Hexenwerk):

Mache eine Komponente, die SynaSer verwendet und das Protokoll gradlinig abwickelt:
[senden -> [Blockieren bis Zeichen empfangen, Zeichen auswerten, ...] ...]
wenn sich dabei ein Ergebnis (oder eine nicht lokal behandelbare Fehlerbedingung) ergibt, dieses mit Application.QueuAsyncCall an den Mainthread weitergeben.

Diese Komponente für jede Schnittstelle in einem Thread instanziieren und laufen lassen.

Vorsicht beim Übergeben der Ergebnisse an den Mainthred !!! Diese kannst Du nicht direkt übergeben, weil der Thread sie sonst überschreiben kann, bevor der Mainthread sie behandelt hat (das kann theoretisch ewig dauern). Also Speicher allokieren in eine Queue schreiben und im Mainthread wieder abbauen. Dafür eignet sich TThreadList, weil die Zugriffe auf die Queue-Verwaltung ja "Threadsafe" sein müssen.

(Mit AsyncPro oder mseCom macht man das ganz anders, weil die Mainthread-Events als "run-to-completion"-Funktionen geschrieben werden müssen. Man spart sich die Thread-Kopmplexität, kann das Protokoll aber nicht "linear" durchprogrammieren.)

-Michael

[mse]

(Mit AsyncPro oder mseCom macht man das ganz anders, weil die Mainthread-Events als "run-to-completion"-Funktionen geschrieben werden müssen. Man spart sich die Thread-Kopmplexität, kann das Protokoll aber nicht "linear" durchprogrammieren.)

Bei msecomm gibt es die Möglichkeit "Protokollobjekte" (tcommevent Nachkommen) in die queue des commport Objektes einzuspeisen, welche dann das Protokoll in einem automatisch verwalteten separaten thread linear abarbeiten können. Dies bietet sich vor allem an, wenn der PC als master figuriert oder über einen RS485 bus mehrere Teilnehmer über einen gemeinsamen port angesprochen werden sollen. Für zeilenorientierte Protokolle mit "End of Record"-Zeichen Struktur gibt es spezialisierte Objekte, welche die Grundfunktionalität bereits beinhalten.

Martin