Raimund Nisiusschrieb: " [...]
Gibt's inzwischen auch kostenlos
Natürlich ist RT-Linux noch im Rennen. Ist aber schon ein anderes Kaliber. Würde ich einsetzen, wenn ich was mit VGA-Grafik, TCP/IP, USB usw. zu tun hätte. Ich warte immer noch auf ein kleines Board für Linux und für
100 Delays!!. Und die braucht man schon bei kleinen Industriemaschinchen locker. Einfach verstehbare Beispiele gef=E4llig?:
-Dr=FCcke Stempel 200ms
-Schwei=DFe f=FCr 800ms
-Warte, bis abgek=FChlt 2500 ms
-Wenn Greifer sich ber=FChren, erst 50ms sp=E4ter abschalten, um Druck aufzubauen.
-Nach Eintreffen des Endcoderimpulses 400=B5s warten, damit Maschinenvibration kein Rollback mehr verursacht. Bei 20 Encodern sind das schon 40 Delays, denn ein Encoder hat zwei Ausg=E4nge.=20 Druckventil =F6ffen, warte 100 ms, bis Druck aufgebaut.=20
-Tropfventil f=FCr 100 ms =F6ffnen, dann 300 ms warten, bis Tropfen = sicher abgefallen.=20 _K=FChlpumpenlaufzeit mindestens 100000 ms.
-Wenn Vorgang nach 10000 ms nicht fertig, dann Fehlermeldung. Aufrufbeispiel hierzu:=20 SchlittenFehler =3D Delay (SchlittenStart, 10000)
Ist doch leicht zu verstehen, wenn die Funktion vern=FCnftig aufgebaut ist, oder? ;-)
Ich hoffe, das konnte aufkl=E4ren.=20
Ist nat=FCrlich klar.
Aber zun=E4chst einmal herzlichen Dank, dass Du Dir so viel M=FChe = gemacht hast, das Thema so detailliert darzustellen und zu erkl=E4ren, so dass es problemlos verstehbar war. :-)
Aber wie geht es jetzt weiter? Wo kommt das RTOS ins Spiel? Bisher haben wir eine Textdatei. W=E4re das ein normales C-Programm, w=FCrde ich es jetzt in den Compiler werfen. Mit Deinem Programm geht das nat=FCrlich nicht, weil er es nicht verstehen wird. Ist das RTOS also eine include Datei, welche die in Deinem Programm mit "OS" gekennzeichneten Befehle verarbeiten kann? Oder ist es wie der Compiler ein Textprozessor, der eine Codeumformung vornimmt. Wenn ja, was kommt aus dem RTOS raus? C-Code?, den der Compiler versteht? Wie ist der Weg von dieser Textdatei zum ausf=FChrbaren Programm?
In meiner Entwicklungsumgebung (MPLAB von Microchip) ist ein sogenannter RTOS Viewer enthalten, zu dem es noch keine Dokumentation gibt. Ich kann dort verschiedene RTOS ausw=E4hlen, von denen er mir sagt, dass er sie nicht findet. Logisch! Einige Google Links unter dem Stichwort "RTOS Viewer" werfen mich auch gleich prompt darauf zur=FCck. Hier beispielsweise einige Screenshots:
Wie sieht es eigentlich mit dem Debuggen aus? Ich k=F6nnte mir vorstellen, dass der letztendlich irgendwann erzeugte Assemblercode schon ziemlich weit vom urspr=FCnglichen Code entfernt ist, jedenfalls viel weiter als der C-code, der durch den Compilerlauf zum Assemblercode wurde. Letzteren kann ich zur Not noch nachvollziehen, zumal mir der Debugger genau anzeigt, welche Assemblerzeilen aus jeder einzelnen C-Code Anweisung entstanden sind und ich sowohl Einzelschritte im C-Code als auch im Assemblercode machen kann. Aber wie sieht das beim RTOS aus?=20
Wenn ich das Ganze jetzt richtig verstehe, stellt das RTOS schon einen gr=F6=DFeren Gef=E4hrdungsfaktor f=FCr die Lauff=E4higkeit des Programms = dar, als ein Compiler. W=E4hrend ein schlechter Compiler in aller Regel h=F6chstens ineffizient ist, k=F6nnte ein schlecht programmiertes RTOS schon eine gr=F6=DFeres Risiko f=FCr die gesteuerte Hardware darstellen = und man braucht da schon noch etwas mehr Vertrauen, um es einzusetzen. Zumindest mehr, als wenn man von Assembler auf C wechselt, welches ich jetzt mal als recht geringes Risiko einordnen w=FCrde. Sehe ich das richtig?
Dieses Durchsteigen zu erleichtern ist ja genau das, worum es mir in diesem Thread-Ast die ganze Zeit geht.
Das w=E4re nat=FCrlich die w=FCnschenswerte und optimale Schreibweise. Bisher hat der Thread diese ja noch nicht hervorgebracht.
Aber mal sehen, wie sich der andere Thread-Ast mit der L=F6sung dieser =46rage =FCber ein RTOS entwickelt.
Was Dirk verdeutlichen wollte war, wie so ein RTOS aussehen kann. Der englischsprachige Wikipedia-Artikel bietet da einiges an Informationen zu:
Du wirfst da nichts "rein" und es kommt nichts "raus". Ein RTOS ist auch nichts anderes als ein OS, mit besonderen Eigenschaften. Windows ist auch ein OS, was hauptsächlich in C geschrieben ist. Beim Booten wird die main-Funktion davon gestartet (ich vereinfache den Ablauf hier ein wenig), die z.B. einen Scheduler einrichtet. Der könnte z.B. so aussehen, daß alle
20ms ein Interrupt aufgerufen wird und den jeweils nächsten Prozess in einer Liste abarbeitet. Im Detail könnte das so aussehen, daß beim Betreten des Interrupts die Registerliste und Rücksprungadresse in einer Struktur des zuletzt gestarteten Prozesses gespeichert wird, und dann die Daten aus dem nächsten Prozess auf den Stack geschoben werden. Ein return-from-interrupt springt dann zurück zur letzten Unterbrechung des nächsten Prozesses. Dadurch entsteht der Eindruck, mehrere Programme laufen parallel, tatsächlich werden die aber nur in Zeitscheiben von 20ms hintereinander ausgeführt.Das kann man jetzt noch beliebig verfeinern, z.B. einen Prozess im Scheduling überspringen, wenn das OS weiß, daß der z.B. gerade einen blockierenden Call ausführt, z.B. auf Flankenänderung an einem Pin wartet, der mit einem anderen Interrupt abgefangen werden könnte, ein Flag setzen könnte und der Scheduler dann den Prozess beim nächsten mal wieder aktiviert, wenn das Flag gesetzt ist.
Was ich eben beschrieben habe, nennt man preemtives Multitasking. Kooperatives Multitasking wäre, wenn der Scheduler einen Prozess aufruft und dieser explizit per Funktionsaufruf die Kontrolle an den Scheduler zurückgibt, sodaß der den nächsten Prozess aufrufen kann.
Willst du nun ein Programm im OS ausführen, dann compilierst du es wie gewohnt, hängst aber noch einen passenden Header davor (ich vereinfache hier wieder ein wenig), sodaß es das OS als Programm erkennen kann und solche Dinge wie Adressrelozierung durchführen kann, was durch eine Liste aller anzupassenden absoluten Stellen im Programm geschieht, die beim Laden des Programms abgearbeitet werden. Im OS läuft dann einfach ein weiterer Prozess, der den Auftrag bekommt, ein Programm zu laden und zu starten. Der sucht also dann eine freie Stelle im Speicher (der vom OS verwaltet wird), lädt das Programm dorthin, reloziert es und fügt es in die Scheduler-Liste ein.
Keine Ahnung, ob das so bei Microchip RTOS funktioniert. Man könnte sich auch vereinfachte Konzepte vorstellen, z.B. das OS mit den zu startenden Programmen fest verlinken und die Scheduler-Liste zur Compilierzeit definieren, sodaß man keinen Loader-Prozess und keine Relozierung braucht, sondern wieder alles als eine Datei flashen kann.
In eine einzige Datei flashen geht aber auch mit dem vollen Konzept, wenn man ein Dateisystem im OS und auf dem Flash aufbaut und sowas wie eine autoexec.bat beim Starten vom OS ausgeführt wird. Unter Linux gibt es da nette Tools, um z.B. eine Datei als Dateisystem zu mounten, sodaß man auf dem Entwicklungsrechner einfach alles da mit Bordmitteln reinkopieren kann, anschließend die Datei unmounted und flashen kann. Für WindowsCE gibt es meines Wissens diese große Orthogonalität beim Entwicklungsbetriebssystem wie Vista oder XP nicht, sondern viele von Microsoft selbstgestricke kleine Programme in Visual Studio, die dasselbe machen und ein komplettes Image mit OS und Anwendungsdateien als eine Datei zusammenbauen können.
-- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
Aufbauend auf den Antworten aus meinem letzten Posting, könntest du eine Art von autoexec.bat schreiben, die das Programm zweimal aufruft, jeweils mit anderen Parametern für die Ports, die als Parameter dann in der main-Funktion ankommen.
Bei Embedded Systemen könnte ich mir aber vorstellen, daß die Prozesse eher in eine Datei gelinkt sind. Vielleicht bieten die auch Threads an. Dann einfach zweimal deinen Thread starten, mit jeweils anderen Aufrufparametern. Jeder Thread bekommt dabei seinen eigenen Stack, sodaß du nur nicht auf globale Variablen zugreifen darfst (es sei denn, du synchronisierst die passend oder es sind sogenannte thread local Variablen). Sähe also so aus:
typedef struct { int keyPin; int ledPin; int delay; } ThreadInfo;
void meinThread(void* parameter) { ThreadInfo* info = (ThreadInfo*) parameter; while (1) { setLedPin(info->ledPin, 0); while (getKeyPortPin(info->keyPin)); while (!getKeyPortPin(info->keyPin)); setLedPin(info->ledPin, 1); delay(info->delay); } }
void main() { ThreadInfo info1 = { KEY1, LED1, DELAY1 }; ThreadInfo info2 = { KEY2, LED2, DELAY2 }; startRTOS(); startThread(meinThread, &info1); startThread(meinThread, &info2); }
setLedPin muss natürlich synchroisiert sein:
void setLedPin(int pin, int on) { lock(); if (on) { PORTA |= 1 Schnittstellenverkehr zwischen den Controller ergibt. Vereinfachtes
Wenn du nicht kostenreduziert für die Massenproduktion was entwickeln musst, ist bei den heutigen Preisen von Microcontrollern die Auslagerung von Threads in eigene Microcontroller die einfachste und sicherste Lösung.
Muss man allerdings abwägen: Wenn du solche Steuerungsaufgaben öfter hast, dann kann es sich lohnen, eine Softwareumgebung zu entwickeln, die das auch mit einem Chip lösen kann, da du dann langfristig gesehen Arbeit beim Layout und der Kommunikation zwischen den Chips sparst. Du brauchst nur noch die entsprechenden Komponenten aus deiner Softwareumgebung zusammenzulinken und entsprechend zu konfigurieren und fertig ist dein neues System (ähnlich dem datenflussbasierten Ansatz).
-- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
...
OK. Zu jedem Stück Hardware eine Verwaltung sowie hier und da Interaktion zwischen diesen.
Du willst ein RTOS nutzen. Alleine schon, weil Dein industrieller Auftraggeber nicht so lange warten will, bis Du quasi eines selber gestrickt hast.
-- Gruß, Raimund Mein Pfotoalbum Mail ohne Anhang an wird gelesen. Im Impressum der Homepage findet sich immer eine länger gültige Adresse.
Genau das war mein Ziel. Parallelität brauchte ich nur, damit delays in der Statemaschine DOS nicht völlig blockierten. Gelegentlich erforderte ein Zustand harte Echtzeit für ein paar Sekunden. Dafür habe ich dann einfach alle anderen Interrupts blockiert...
Dann wäre sowas wie ein SPS-Compiler sicher das richtige! Bin schonmal über sowas gestolpert.
- Henry
-- www.ehydra.dyndns.info
Habe schon 2 mal einem SPS-Programmierer zugeschaut. Auch bei dem, der meinte das wäre jetzt viiiiiiel komfortabler als früher, hat es mich gegruselt. Oder kannte der bloß die "Hochsprache" nicht richtig?
-- Gruß, Raimund Mein Pfotoalbum Mail ohne Anhang an wird gelesen. Im Impressum der Homepage findet sich immer eine länger gültige Adresse.
Ist nicht mein Metier. Wir haben allerdings vor 25 Jahren unsere SPS in Form von Fernmelderelais selber entwickeln müssen bzw. nachvollzogen was denn so eine Fernmelde-Vermittlungsstelle wie macht. Das hat astrein funktioniert. Oder hast du einen anderen Eindruck vom Telefonsystem?
Du wirst halt tagelang googeln müssen. In der Zeit kannst du es aber vermutlich auch selber schreiben. Zumal dann die Dokulesephase wegfällt.
- Henry
-- www.ehydra.dyndns.info
Paul Rosenschrieb: "
Das RTOS selbst wird Dir als Library zur Verfügung gestellt. Wenn Du picoos nutzt, dann bekommst Du es im Quellcode und kannst Dir selbst davon eine Lib erstellen. Es ist recht sinnvoll sich davon eine Debug-Version zu erstellen, um auch mal in die RTOS-Funktionen hinein zu debuggen und zu sehen, was da passiert. Ist ja kein Voodoo-Zauber und hilft sicher den Gefährdungsfaktor besser abzuschätzen. Bei kommerziell vertriebenen RTOS kann man dann die Sourcen auch für viel Geld dazukaufen. Dazu gibt es dann einen Header, den Du in Deinen Quellcode einbindest, so dass Du die Funktionen nutzen kannst. Evtl. bekommst Du noch ein oder zwei C-Dateien, um spezielle Anpassungen vornehmen zu können (z.B. UART für Profiling und Analyse). Die RTOS selbst sind in C geschrieben und Prozessor unabhängig und nur ein oder zwei kleine Dateien in Assembler für den Prozessor spezifischen Teil (z.B. Context-switching). Aber probier es doch einfach mal aus! Lade Dir von
Wie das alles mit den PICs funktioniert kann ich Dir nicht sagen, da Microchip bei mir verspielt hat. Ich habe vor glaube 10 Jahren mal den PIC16C62 auf einer ISA-Karte eingesetzt. Leider war mein Chef (damals war ich noch angestellt) zu geizig einen Emulator und einen Compiler zu besorgen. Das Ding hatte keinen Flash und die EPROM-Version gab es nicht in SMD. Für einen Adapter (SMD -> DIP) gab es keinen Platz und so wurden nach jeder Fehlerkorrektur OTPs gebrannt. Nach zehnmaligen Auf- und Ablöten konnte man dann die ganze ISA-Karte wegwerfen. Von den ATMELs war ich damals auch nicht begeistert. Keinen kostenlosen C-Compiler und bei jeder neuen Generation mußte man wieder teures Equipment kaufen. Also war Atmel für mich auch gestorben.
Ich habe dann auf den M16C gewechselt und damit war die Welt in Ordnung. Alle Tools kostenlos und mit dem KD30 ist das Debuggen ein Kinderspiel. Inzwischen hat sich aber bei Microchip und Atmel was getan. Ich weiß nicht, ob man immer noch teure Debugging-Tools kaufen muss aber zumindest gibt es für den Atmel einen gcc. Der AVR32 mit Ethernet und USB-OTG sieht ganz nett aus. Das ATEVK1100 ist aber auch nicht gerade günstig. Da gefällt mir
Ein schlechter Compiler kann Dich wochenlang schlaflose Nächte kosten. Wenn Du den Quellcode zum RTOS hast, dann kannst Du - wie bereits beschrieben - einfach hineindebuggen, als wäre es Dein eigener Code. Natürlich gibt es auch Fallen. So darf man in einer Interrupt-Routine z.B. kein OS_PendSemaphore() aufrufen, weil man in einer Interrupt-Routine nich auf einen anderen Task warten kann. Das RTOS merkt das aber, setzt eine Fehlernummer, und bricht ab (im Manual S.
288). Auch muss man sich bei mehreren Task Gedanken darüber machen, wie man den Watchdog aufbaut, so dass er nur auslöst, wenn sich nicht alle Task innerhalb einer gewissen Zeitspanne gemeldet haben. Möchte man Tasks priorisieren, dann muss man sich auch darüber Gedanken machen. Bei nicht priorisierten Task kann das Thema Dead-locking ein Problem werden. Bei priorisierten Tasks gibt es eine Priority-Inversion.Das war dann aber auch schon alles. Der Gewinn ist ungleich höher. Wenn du hundert Delays hast würde ich in jedem Fall ein OS einsetzen. Selbst wenn es nur einen Task geben wird. Das ständige hin- und hergespringe macht Dir sonst den ganzen Code kaputt. Nicht umsonst sind gotos verpönt. Der Code wird einfach schlecht lesbar. Ab einer gewissen Menge Code wird Übersichtlichkeit und Abstraktion immer wichtiger. Ich hatte schon das Vergnügen an Projekten mitarbeiten zu dürfen, wo ca. zweitausend Quellcode-Dateien zusammengelinkt wurden. Wenn dann die Produktion steht und der Produktionsleiter wissen will, zu welchem Datum dann die neue, fehlerbereinigte Version herauskommen wird, oder ob er 100 Produktionsarbeiter in Zwangsurlaub schicken soll, dann gibt das schon so ein flaues Gefühl im Magen.
Dirk
Ähm brauchst Du nun DOS oder Linux? Picoos gibt's m.W. auch für DOS. Falls Du DOSen Apps selbst entwickelst wird sich ein TCP/IP-Stack und eine Thread-Lib finden lassen und für Grafik hab ich früher mals was mit der Allegro-Grafik-Lib unter DOS gemacht. Auch ganz nett. DOS gibt's doch inzwischen irgendwo im Quellcode. Könnte man doch auf einen Controller portieren ;-)
Manchmal brauchts auch kleine Stückzahlen, da lohnt sich das selber designen nicht. Gibt's beim EEPC auch das A20-Gate?
Dirk
*Damals* nutzte ich DOS. Das Projekt wuchs mit den Anforderungen und die Netzwerkanbindung (Datensicherung abends) war schon der Diskette gewichen. Die Bedienoberfläche hatte ich schon mal für Linux übersetzt. Dann bekam der technische Vorstand plötzlich seinen 60. Geburtstag und neben manchen geplatzten Seifenblasen erlitt auch dieses Projekt seinen harten Design Freeze.
Nee, muß nicht sein. Z.Z. mache ich mehr mit .net rum. Keinerlei Speicherallozierungsfehler haben einen gewissen Charme wenn Echtzeit bedeutet, daß der Kaffee bis zur Antwort nicht kalt wird.
Bei embedded Kram halte ich mich nur auf dem Laufenden mit z.B. einem Rechteckgenerator oder Geschwindigkeitsmessung mit Überreichen der Daten an Seriell/USB.
Keine Ahnung.
-- Gruß, Raimund Mein Pfotoalbum Mail ohne Anhang an wird gelesen. Im Impressum der Homepage findet sich immer eine länger gültige Adresse.
Paul Rosen schrieb:
So ist das zumindest beim FreeRTOS
Wie schon gesagt: Wenn Du den Quellcode besitzt und dieser verständlich ist, kannst Du den genau so debuggen wie Deinen eigenen Code.
Wenn es fehlerhaft ist, kann es genauso Probleme machen wie ein fehlerhafter Compiler.
Das ist bei jedem zusätzlichen Code so.
-- GPG key: http://pgp.mit.edu:11371/pks/lookup?search=J%FCrgen+Appel&op=get
Wie ich schrieb, waren das "einfach verstehbare Beispiele".
Aber in der Tat: Der Hauptprozess ist vergleichbar weniger anspruchsvoll, was die Programmierkenntnisse angeht. Die Problematk liegt da eher in den Unsummen von Aktoren und Sensoren, die mechanisch voneinander abh=E4ngig sind. Ein falscher Befehl kann Verletzungen beim Bedienungpersonal und zudem sehr teuere Werkst=FCcke oder die Maschinenhardware selbst besch=E4digen. Die Verletzungen treffen mich zuerst, weil ich derjenige bin, der es in in Betrieb nehmen muss.=20
Zudem mu=DF man beim Programmieren die Endlichkeit der mechanischen Leistungsf=E4higkeit ausgleichen sowie aus Sicht des Bedieners die Vorg=E4nge m=F6glichst handhabbar machen. Die Programmierarbeit ist also nicht zu Ende, wenn die eigentliche Funktion gegeben ist, sondern man beobachtet weiter und =FCberlegt, wie man es ihm einfacher machen kann, indem man beispielsweise etwas an der Bedienoberfl=E4che =E4ndert oder = ihm ein Werkst=FCck anders herum vorh=E4lt. (Das waren jetzt wieder einfach = zu verstehende Beispiele.)
=46=FCr die Unterprozesse, welche der Hauptprozess "verwaltet", sind die Entwicklungen auch programmiertechnisch anspruchsvoll. Motore, die Raumkurven fahren, neue Messger=E4te/Sensooren f=FCr die Prozesse, Regeleinrichtungen etc. Durchaus muss man auch schon einmal mechanische Berechnungen anstellen, weil z.B. schwere Gegenst=E4nde nicht so weit ausgelegt werden d=FCrfen, wie leichte, weil sonst schlicht etwas abknickt. =20
Mein "Auftraggeber" ist die Firma, in der ich arbeite. Ich baue nur Spezialmaschinen f=FCr unsere Fertigung. Das "gestrikte" RTOS ist zumindest schon soweit fertig, dass es in zwei Maschinen l=E4uft. Im Moment denke ich nur noch =FCber ein paar kleine Optimierungen nach.=20
Und es geht tats=E4chlich dabei, wie in einem anderen Ast angesprochen, um das Ersetzen von sauteuren aber unflexiblen SPS gegen Microcontoller. Dabei soll zumindest der Hauptprozess weiterhin f=FCr Gesellen zugreifbar bleiben, damit diese Anpassungen z.B. bei einer erm=FCdeten Feder oder ge=E4nderter Viskosit=E4t eines Stoffes selbst vornehmen k=F6nnen, so dass ich nicht selbst dahinter her rennen muss.=20
Und alles was eine SPS bietet, gibt es eigentlich schon in C. Die Ausnahmen sind der "Timer" (ist das SPS Pendant zu "Delay") und einige Bausteine, die sich mit wenig Beiwerk aus den C Befehlen und Timern als Funktion oder Macro herstellen lassen. Das einzige, was f=FCr den Verwaltungsprozess fehlte und realtime-m=E4ssig Probleme machte, war der Timer. Alles andere f=FCr den Hauptprozess ist Geradeausprogrammierung.
Ich habe also eine Anleitung gemacht, wie die SPS Bausteine in C aussehen. z.B.
LD TasteRotieren=20 A Drucker=20 O Fahrweg3=20 =3D Merker20
hei=DFt in C:=20
Merker20 =3D=3D =20 TasteRotieren=20 & Drucker =20 "| Fahrweg3 =20 ;
Z=E4hler sind "For" Schleifen, CP (Compare) ist "if", Schieberegister sind "
Auch Dir herzlichen Dank f=FCr Deine ausf=FChrliche Erkl=E4rung. Ich = blicke aber nicht ganz durch: Warum nimmst Du bei "void* parameter" einen typlosen Zeiger. Zudem verstehe ich nicht, was da =FCbergeben werden soll. Denn die einzigen Aufrufe von "meinThread" sind diese:
Und dort erkenne ich keine Parameter, die "meinThread" =FCbergibt.
Dann gebe ich Dir Recht, kein weiteres System hinzu zu nehmen.
8-() Aber doch nicht im Quellcode? S.u.Ist das nicht eine Zuweisung?
und das ein Vergleich?
Ich bin zwar nicht Frank, aber das weiß ich auch. startThread ist eine Funktion, die das RTOS mitbringt. Das kann nicht wissen, welche Parameter die Threads brauchen werden. Insbesondere werden das nicht immer die selben Parameter sein. Darum weiß das RTOS nur, daß ein Pointer übergeben wird. Die Threads müssen die dann eben casten.
Die Argumente von startThread sind ein pointer auf eine Funktion und ein Pointer auf Daten.
Das RTOS sieht dann etwa so aus: void startThread( void (*aThread)(void *), void *parameter ) { /* Init */ (*aThread)(parameter); /*Threadfunktion wird ausgeführt*/ }
-- Gruß, Raimund Mein Pfotoalbum Mail ohne Anhang an wird gelesen. Im Impressum der Homepage findet sich immer eine länger gültige Adresse.
Nein. ;-) Aber das ist eben so, wenn man so viele Systeme hat. Die sind sich alle =E4hnlich. Darum kopiere ich mir in jedes leere Programm oben erstmal eine Mustersammlung des gerade ben=F6tigten Dialekts. Ansonsten habe ich das mal eben so reingetippt. Beim Programmieren achte ich nat=FCrlich mehr. Und da ich momentan Urlaub habe, habe ich die Anleitung auch nicht zur Hand.
Genau!
Die Antwort war hier versteckt:
abzusichern.
Ist also noch Komjunktiv. Ich bin mir noch nicht sicher.
Also: F=FCr einen SPS Timer braucht man=20
1) eine Nummer oder einen Namen. 2) einen Zeitangabe 3) einen Eingang, dem man einen Wert zuordnet, analog dazu, wie man es bei einem Merker oder einem Ausgang tut:z.B.=20 Merker =3D boolscher Ausdruck Ausgang =3D boolscher Ausdruck
Also analog beim Timer: TimerKlingel500 =3D boolscher Ausdruck=20
# Dabei ist Klingel der spezifizierende Name (statt einer Nummer) # 500 ist die Zeitangabe in ms. # Hinter "=3D" steht der zugewiesene Ausdruck, der irgendwann eine 0->1 =46lanke als Startsignal produziert. Im Beispiel eben die Taste.=20
Zu dieser Wunschvorstellung=20 TimerKlingel500 =3D boolscher Ausdruck=20 muss man jetzt einen #define Operator finden, der die drei Bestandteile wieder auseinander poult und zudem den Namen (hier: TimerKlingel) in einen Nummer umwandelt, so dass die TickerInterruptfunktion diese Nummer als Index benutzen kann. Dies ist mir aber nicht gelungen. Daf=FCr aber eine nicht un=E4hnliche Form, n=E4mlich:
TimerKlingel =3D 500 * (boolscher Ausdruck)
Denn der verwandelt sich durch #define TimerKlingel DelayCounter[0] zu DelayCounter[0] =3D 500 * (boolscher Ausdruck)
Ist der boolsche Ausdruck =3D 1 , dann ist DelayCounter [0] =3D 500 Ist der boolsche Ausdruck =3D 0 , dann ist DelayCounter [0] =3D 0 In dem Moment, wo der boolsche Ausdruck 1 wird, wird der DelayCounter zu 500, also auf den beabsichtigten Startwert gesetzt.=20
Das Detailproblem liegt noch darin, dass der DelayCounter nur in dem Moment der 0->1 Flanke geladen werden darf. Falls es mir nicht gelingt, dies per Define zu l=F6sen, werde ich in der Hauptschleife noch einen Loop f=FCr alle Timer bereitstellen m=FCssen, der dies erledigt = z.B. for (i =3D 0; i < DelayAnzahl; i++) { if (!XDelaycounterAlt[i] & XDelaycounter[i]) //Eingang von 0->1? {Delaycounter[i] =3D XDelaycounter[i];) =20 XDelaycounterAlt[index] =3D XDelaycounter[i]; }
Die Define Anweisung muss hierzu ge=E4ndert werden:=20 #define TimerKlingel XDelayCounter[0]
Man wei=DF ja vorher nicht, wo es einmal geh=E4uft haken wird. Das stellt sich erst mit den Jahren heraus. Darum ist Konfigurationsscript nicht. Besonders vor Ort ist auch nervig, im Lesefluss auf einmal aufs Konfigurationsscript verwiesen zu werden. Au=DFerdem lernen sie es so ja nie. Nat=FCrlich (zumindest vorl=E4ufig) keine =C4nderung ohne mein = letztes OK. Meist ist es ja nur ein numerischer Wert, der ge=E4ndert werden muss. Aber mit dem Debugger nachgucken, das Problem finden und im Programm lokalisieren sowie =C4nderungsvorschl=E4ge machen sollen sie schon.=20
An Subprozessoren darf jetzt zumindest noch niemand dran. Die sollten eigentlich nur durch Kenntnis der Schnittstellenbeschreibung zu bedienen sein. z.B. Gib dem Fahrweg 5 ein paar Schritte mehr, weil der Reifen abgenutzt ist. Oder eine kapazitive F=FCllstandsregelung (bestehend aus zwei eingepassten Blechen) muss nachkalibriert werden. Neues Fluid l=E4=DFt weniger Licht durch.=20
Ich habe hier einen Lehrling, der gerade ins vierte Lehrjahr gekommen ist. Kann gut auf der SPS und etwas Visual Basic. Der f=E4ngt jetzt schon durch Studium meiner Anleitung an, kleine Progr=E4mmchen zu schreiben und C dar=FCber hinaus zu entdecken. Und der hat drei Gesellen am Anfang ganz gut auf die Spr=FCnge geholfen. Ich sage dazu immer: Das Wissen, das man selbst weitervermitteln muss, sitzt am Besten. Deswegen schicke ich Fragende m=F6glichst zu einem Anderen, wenn der es auch beantworten kann. Witzig ist dabei, wenn ich den Befragten in einer ruhigen Minute dann auf einmal im Internet sehe.=20
100Aha, das erinnert mich irgendwie an den C64, der so Zeiger realisiert hat. keine Neumann Architektur.
Und dann hoffentlich nicht an leidgeplagte Kunden verkauft ;-)
Ich lerne neue Sprachen nur noch dann, wenn ich nicht mehr dran vorbeikomme ;-) Gibt es eigentlich sowas schon f=FCr =B5Cs?
noch
Hier:
Aber wenn das=20
=FCber den typlosen Parameter ganz oben an "meinthread" =FCbergeben wird, m=FCssten bei "DELAY" auch Namen statt Nummern auch gehen, oder?=20
dazugeh=F6riger
Danke
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.