Wie CAN-Frames durch eigene Soft-SPS auswerten?

Sowas im Einzelbitverfahren loesen zu wollen ist unrealistisch. Und 
Delays gibt es eh nicht. Gab es noch nie. Dazu ist zu sagen, ein PC war 
noch nie eine Echtzeit Maschine. Ich wuerd da alles in Hardware 
auslagern. Eigentlich macht man die beschriebene Funktionalitaet mit 
Threads, ein PC ist dann aber trotz 3GHz schnell am Ende, denn ein 
Taskswitch ist ein Riesenaufwand.

Eine Zustandsmaschine ist da viel effizienter. Und weswegen muss das 
alles auf einem PC laufen ?

Rumpel, der Stilz ist grad nicht da. schrieb:
> Delays gibt es eh nicht. Gab es noch nie.

War auch nur beispielhaft für etwas, was etwas Zeit in Anspruch nehmen 
kann. Beispielsweise die Aktualisierung eines Anzeigeelementes auf der 
GUI.

Rumpel, der Stilz ist grad nicht da. schrieb:
> Eine Zustandsmaschine ist da viel effizienter. Und weswegen muss das
> alles auf einem PC laufen ?

Warum denn nicht? Das ganze läuft im universitären Umfeld aus 
Forschungsmaschine. Nebenbei gibt es einige Messaufgaben, 
Visualisierung, ggf. Ankopplung an andere Softwarekomponenten. Deshalb 
muss es ein PC sein. Es gibt ja auch z.B. die CoDeSys-Soft-SPS auf einem 
PC, EtherCAT Automatisierungen laufen fast ausschließlich auf IPCs. Der 
Einzige Unterschied ist, dass ich nicht die EN 61131-"Sprachen" 
verwende, sondern mir ein eigenes Programm baue, in dem die 
Automatisierung läuft.

Zur Echtzeit: Ist glaube nicht nicht wichtig für meine Anwendung.

Kurz noch zum strukturellem Aufbau des Automatisierungsteils:
1. Automatikprogramm wird mit automatik(0) gestartet.
   (0) ist der Startparameter für die Ablauffolge. 0 Ist dabei ein 
Sprungpunkt in einer switch-Anweisung
2. In 'case 0' steht z.B. Zylinder_vor. Ein Zylinderwarteflag wird 
gesetzt.
3. pdo_input meldet, dass der Zylinder vorne ist (Näherungsschalter) ==> 
wenn Zylinderwarteflag, dann task(1)
4. ......

Also, mit einem PC so etwas zu machen, ist vollkommen in Ordnung und 
auch kein Problem. Richtig, TwinCat von Beckhoff läuft auch auf allen 
möglichen Windows-Varianten, ob CE, XP, 7 usw. Allerdings eben immer 
relativ tief im System als Echtzeit-Task.

Aber egal, vermutlich liegt es an Deiner Programm-Struktur.

Du solltest vielleicht IO (Can), SPS-Funktionalität und Visualisierung 
voneinander trennen.

Keine Ahnung was für eine CAN-Karte Du hast und wieviel sie puffern 
kann. Aber vom Prinzip solltest Du das wie ein normales SPS-System 
aufbauen:

a.) Eine Task, höchste Priorität, macht nur IO (CAN) und baut aus den 
einzelnen Bit-Nachrichten ein "virtuelles" Prozessabbild zusammen und 
beantwortet aus diesem Prozessabbild auch CAN-Bus-Anfragen.

b.) Eine zweite Task, mittlere Priorität wird zyklisch aufgerufen, und 
darin programmierst Du die SPS-Funktionalität, genau so zyklisch wie 
sonst mit IEC61131-3, nur eben in C++ anstatt ST. (Eine Kopie des 
Input-Prozessabbildes am Zyklusbegin erstellen und Output-Prozessabbild 
am Zyklusende der IO-Task übergeben.)

c.) Eine dritte Task, normale Priorität, macht den ganzen 
Visualisierungskram, Diese Task kann dann beliebig komplexe Funktionen 
des Betriebssystem aufrufen und Datei-IO etc. machen.

Est leider ueblich im universitaeren Umfeld etwas selbst machen zu 
wollen, was man als zu teuer oder als nichtpassend betrachtet. Das 
ergebnis ist dann ein schlecht dokumentiertes unzuverlaessiges 
Gepfriemel. Wenn man noch einen Schritt weitergeht, dh etwas haebn will, 
das nicht funktioniert und viel gekostet hat, nimmt man National 
Instruments.

@Troll: Ganz ehrlich, Deine Antwort verstehe ich nicht. Es geht um eine 
relativ einfache Folgeautomatik mit vielen Digitalkanälen, so etwas 
wurde früher mit Schützsteuerungen realisiert und funktionierte super. 
Warum sollte man dafür 1000% überdimensionierte fertig-SPS'en einbauen, 
die alles verkomplizieren? Letztendlich ist die Schnittstelle vom 
PC-Programm zur Peripherie das CAN-Frame. Es ist simpel aufgebaut, und 
im vergleich zu anderen Feldbussen, wie z.B. Profibus, Profinet, 
EtherCAT, etc. kann man sehr einfach das Protokoll verstehen und die 
Frame-Inhalte interpretieren.

Wenn ich einen Kanal setzen möchte, sende ich einen Frame, die 
ankommenden Frames werden empfangen und ausgewertet. Es geht mir auch 
primär nicht darum, ob so was gut ist, oder nicht, sondern wie ich das 
Problem mit dem Multitasking/Multithreading löse.

Den Vorschlag von Automatisierer (Gast) finde ich schon gar nciht 
schlecht, allerdings möchte ich es nicht zyklisch machen, sondern rein 
Ereignisorientiert. Deshalb habe ich auch einen Thread, in dem eine 
CAN_Read-Funktion steht. Der Thread "steht" so lange, bis ein Frame 
kommt, was dann ausgewertet wird. Da es ein Thread ist, kann das 
restliche Programm weiterlaufen, wenn kein Frame kommt, und dieser eine 
Thread steht. Ich überlege ähnliches auch zu tun, wenn eine Bitänderung 
kommt. Ist soetwas denn völlig unüblich udn unrealistisch??

Zu ni: richtig, kostet viel, aber falsch: funktioniert sehr gut! 
Allerdings ohne Fertiglösungen wie LabVIEW, sondern frei programmiert in 
C. Das ganze dann integriert in mein Steuerprogramm. Unter Anderem 
deshalb übrigens auch komplett frei programmiert....

Hallo

> @Troll: Ganz ehrlich, Deine Antwort verstehe ich nicht.

Das ist nur einer, der Angst hat, das jemand mit open source SPSen das 
Geschäft kaputtmacht. ;O)

> Den Vorschlag von Automatisierer (Gast) finde ich schon gar nciht
> schlecht, allerdings möchte ich es nicht zyklisch machen, sondern rein
> Ereignisorientiert.

Der Vorschlag, von Automatisierer ist auch das einzig wahre. 
Ereignisorientiert ist aber seeehr aufwändig und kompliziert und dadurch 
bei größerem Umfang schnell langsam bzw. ohne garantierbare 
Maximalzeiten und Fehleranfällig.

anderer Troll schrieb:
> Ereignisorientiert ist aber seeehr aufwändig und kompliziert

ok, dann verstehen wir beide "ereignisorientiert" vielleicht etwas 
unterschiedlich. Ich meine damit, dass ich im Programm einen Thread 
laufen habe, der bei der Funktion canRead (Daten von der PCI-CAN-Karte 
abholen) stehen bleibt, bis ein Frame kommt, was dann auseinander 
gepflügt wird.

Da ich es noch nie zyklisch probiert habe, würde ich es mir sicherer und 
sparender vorstellen, es nicht zyklisch zu machen, denn wenn ein Eingang 
kommt, wird gepfüft (if), ob dieser Eingang jetzt gerade erwartet wird. 
Der Automatikzyklus geht dann durch einen Sprung in automatik(int 
teilschritt) weiter. Zyklisch müsste ich ja in jedem Durchlauf prüfen, 
ob der Eingang gerade erwartet wird, und dann trotzdem in meine 
automatik(int teilschritt)-Funktion springen.

Realisierst Du auch eine Folgeautomatik mit Sprüngen in eine Funktion, 
die meiner automatik(int teilschritt)-Funktion ähnelt mit Hilfe von 
switch-case? Habe das irgendwann mal übernommen und seit dem immer 
wieder in neuen Anlangen verwendet.

2 Vorbemerkungen:
a) da die c't von gestern es grade brachte: stell sicher dass es nicht 
nur auf WinXP läuft, das kriegt in nem Jahr absolut garkeine Patches 
mehr.
b) Der Hinweis auf ein bestehendes System ist gut, macht die Wartbarkeit 
durch andere leichter und dürfte viele deiner Probleme schon gelöst 
haben. Ein Betriebssystem mit Echtzeitfähigkeiten hat vermutlich auch 
Vorteile.

Leider habe ich bei deinen Erklärungen ein paar Probleme, man merkt dass 
du tief im System steckst, wir nur leider nicht ;) Ich habe auch ein 
bisschen den Eindruck, dass du zu sehr "in quelltext" denkst und dir 
über die große Struktur noch eher wenig Gedanken gemacht hast (sorry 
falls das nicht stimmt)
Mal ein Haufen fragen, die dir hoffentlich beim strukturieren helfen und 
uns dabei, das Problem zu verstehen.
hansi schrieb:
> Wenn nur
> eine Bitfunktion irgendwo in der pdo_input-Funktion ein Delay von <10ms
> auslöst, gibt es schon massive Heartbeat-Probleme.
Was bedeutet "Heartbeat-Probleme"? Erwarten andere Systemkomponenten 
Rückmeldungen? Wovon hängen diese ab?
Warum sollte in der input-Funktion ein Delay auftreten? Was macht die 
alles? Passt dein Problem überhaupt in einen Automaten "ordentlich"?

hansi schrieb:
> Da ich es noch nie zyklisch probiert habe, würde ich es mir sicherer und
> sparender vorstellen, es nicht zyklisch zu machen, denn wenn ein Eingang
> kommt, wird gepfüft (if), ob dieser Eingang jetzt gerade erwartet wird.
Und was wenn der nicht erwartet wird? Darf das nicht passieren -> 
Fehlerfall? Oder was passiert sonst mit der Information?

asdf schrieb:
> Leider habe ich bei deinen Erklärungen ein paar Probleme, man merkt dass
> du tief im System steckst, wir nur leider nicht ;)

das hatte ich schon vermutet. Ich werde in den nächsten Tagen das 
Prinzip mal skizzieren und meine "ereignisgesteuerte" SPS vorstellen.

asdf schrieb:
> Ich habe auch ein
> bisschen den Eindruck, dass du zu sehr "in quelltext" denkst und dir
> über die große Struktur noch eher wenig Gedanken gemacht hast (sorry
> falls das nicht stimmt)

ist schon richtig. Ich denke in diesem Fall wirklich verschärft in 
Ansi-C und überlege, wie ich es programmiere, welche Funktion was 
aufruft und wo deklariert ist. Ist so, so habe ich mit all dem 
angefangen und C gelernt.... Bin halt kein "typischer" SPSler ;-)

asdf schrieb:
> Was bedeutet "Heartbeat-Probleme"? Erwarten andere Systemkomponenten
> Rückmeldungen? Wovon hängen diese ab?
> Warum sollte in der input-Funktion ein Delay auftreten? Was macht die
> alles? Passt dein Problem überhaupt in einen Automaten "ordentlich"?

Mit Heartbeat meine ich den CAN-Heartbeat. Es gibt eine Komponente, die 
alle 100ms ein Bit toggelt, und ich passend zwischen den Eintreffen der 
Bits antworten muss. In Ruhe läuft das ganze. Mache ich z.B. den Firefox 
auf und scrolle ein wenig, läuft zwar das Programm noch, aber der 
CAN-Teilnehmer steigt aus, da das Heartbeat zu spät kam.
Ich müsste also irgendwie den Funktionen/Threads in meinem Programm eine 
höhere Priorität geben.....

asdf schrieb:
>> Da ich es noch nie zyklisch probiert habe, würde ich es mir sicherer und
>> sparender vorstellen, es nicht zyklisch zu machen, denn wenn ein Eingang
>> kommt, wird gepfüft (if), ob dieser Eingang jetzt gerade erwartet wird.
> Und was wenn der nicht erwartet wird? Darf das nicht passieren ->
> Fehlerfall? Oder was passiert sonst mit der Information?

Mit dieser Information passiert nichts. In diesem Beispiel setze ich ein 
Ventil, dadurch setzt sich ein Zylinder in Bewegung (die 
Zylinderbewegung kann z.B. 4 Sekunden dauern). D.h. das Programm wartet 
ab Schalten des Ventils auf Ankunft des Zylinders (Eingang). Das ist 
quasi nur dazu, damit nicht wilde Dinge passieren, wenn der Zylinder 
unerwartet vorne ist.

Ich habe jetzt eine grobe Übersicht meines Programmes aufgemalt.

Ich hoffe, es wird einigermaßen verständlich, wie ein automatischer 
Ablauf bei mir funktioniert. Ein Problem ist natürlich, wenn bit_changed 
oder ablauf aus irgendeinem Grund kurz haken sollte, steht auch die 
Auswerteschleife für ungelesene Frames.

Vielleicht werden die SPS-Experten dieses Vorgehen für Schrott, oder 
Müll halten, ich bin aber insgesamt relativ zufrieden und würde andere 
C-Programmierer mal um ihre Meinung bitten.

Natürlich stehen Teilabläuft mit Delay() in einem getrenntem Thread, 
damit Delay wartet, aber da es nur ein Thread ist, läuft der Rest 
weiter.

Der Haupt-Thread geht aber natürlich nicht weiter, wenn eine durch den 
Thread aufgerufene Funktion steht. Anders wäre es, wenn bit_changed auch 
ein Thread wäre, der idealerweise auch mehrfach zur gleichen Zeit 
aufgerufen werden kann.

position bei ablauf ist der "Fortschritt 'in %'" des Automatik-Ablaufes. 
Jeder Teilschritt ist im switch-case-Konstrukt als case dargestellt.