Parametrierfehler C313C für Flexibilität

Robot-Sun

Level-1
Beiträge
83
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

[verwendete Hardware C313C + DE/DA-Baugruppen]

ich wollte mal wissen, ob es üblich ist einen "Parametrierfehler" in kauf zu nehmen, um so eine universelle und wartbare Software zu erhalten.
Ich habe meine Ein-/Ausgangsbelegung so gewählt, dass ich je nach größe meiner Anlage DE/DA-Baugruppen weglassen kann. Und zwar immer von HW-Rack 11 aufsteigend bis minimal Rack 4.
Die Software ist für die maximale Anlagengröße ausgelegt und kann durch weglassen der Baugruppen sowie ein Configurations-DB eingerichtet werden. ( Das weglassen der Baugruppen möchte ich aber nicht immer mit dem löschen der Baugruppen in der HW-Config durchführen.)
In der Software werden nun evtl. fehlerhafte Anzeigen (im TP) die durch das Fehlen von DE oder DA baugruppen fehlen abgeschaltet. Beim Testen ging alles soweit glatt. Hauptschütz ging an, die SPS ging nicht in Stop.
Nun ist die Frage inwiefern diese Flexibilität zu Fehlern führen kann. Wie sieht es da mit der Softwaresicherheit aus?
Was kann den im schlimmsten Fall passieren?
Sollte man so programmieren?
(Es ist allerdings sehr aufwenidig und fast nicht wartbar, wenn ich zich verschiedene varianten der eigentlich doc gleichen Anlage erstelle)

Eine weitere Frage ist was passieren kann wenn mein Programm sehr DB-lastig ist. Also DB sind ja wohl remanent. Also was kann z.B. passieren beim Ausfall der Betriebsspannung. Welche Fehler sind euch denn da so bekannt?

MFG :eek:)
 
Nun ist die Frage inwiefern diese Flexibilität zu Fehlern führen kann. Wie sieht es da mit der Softwaresicherheit aus?
Wie reagierst Du auf Fehler, die durch den Ausfall einer existierenden Baugruppe auftreten?
Was kann den im schlimmsten Fall passieren?
Eine def. existierende Baugruppe wird ignoriert und die dort verbauten Endschalter/Sensoren können nicht das Programm in gewünschter weise beeinflussen und Du fährst die Maschiene zu Klump.
Sollte man so programmieren?
(Es ist allerdings sehr aufwenidig und fast nicht wartbar, wenn ich zich verschiedene varianten der eigentlich doc gleichen Anlage erstelle)
Warum nicht, wenn die Dokumentation/Einweisung des Kunden entsprechend ausfällt ists nicht verkehrt
Eine weitere Frage ist was passieren kann wenn mein Programm sehr DB-lastig ist. Also DB sind ja wohl remanent. Also was kann z.B. passieren beim Ausfall der Betriebsspannung. Welche Fehler sind euch denn da so bekannt?
Maximal könnten die DB-Werte auf Initialwert zurückgesetzt werden. War letztens hier bei 315/317 ern von " IBFS " aufgetreten einfach mal danach suchen.

Thomas
 
Die Software/Hardware die ich verwende ist schon vorhanden (seit Jahren) und wird

von mir weiterbearbeitet. Ziel ist für mich die Softwarestruktur und Hardware so

anzupassen, dass ich ohne große Mühen die Anlage erweitern bzw. Redzuzieren kann.

und dass am besten nur durch das austauschen eines Configurations-DBs.

Die ET200s ist mir nun nur mit 8DE Baugruppen (..) bekannt und nicht z.b.
mit 16DE oder 32DE. Die Anreihung von einigen ET200s würde relativ schnell das

bisherige Schaltschrankdesign zerstören. Der Kompakte Schaltschrankbau ist ein

vorzug unseres jetzigen Systems. Nach Möglichkeit werden dabei aber 16DE-Baugruppen

verwendet. (Es lässt sich so leichter verdrahten. Andere varianten wurden schon

probiert auch mit konfektionierten Kabeln)

Bei meiner Erprobung kam keine Erkennung "Baugruppe fehlt".


Projektiert sind:
OB80: Zykluszeit
OB82: Hardware
OB85: Baugruppe
OB87: Globaldaten

OB80
Wurde der OB 80 nicht programmiert, dann wechselt die CPU in den Betriebszustand

STOP.
Die anlage geht nicht in Stop sondern lösst Not-Aus aus + einen Softwarehalt

(setzend).

OB82:
keine Ahnung... noch nie live erlebt. Evtl. sind auch keine Diagnosefähigen

Baugruppen eingebaut. (Kommentar in der Software: "Beliebiger Fehler wird erkannt.")

OB85
Hinweis: Wenn der OB 85 nicht programmiert ist, dann wechselt die CPU in den

Betriebszustand STOP, wenn eines der genannten Ereignisse auftritt.
--> Es wird wohl garnicht reagiert.

Da auf dieser Baugruppe aber Daten gehen.
Wie Wegesenoren würde eine 0 oder 1 zu einem Stopp führen, weil diese als

Betriebsenden deklariert sind.
Das Programm ist im generellen so strukturiert das 0 oder 1 einen "Sonderzustand"

haben. Die normalen Betriebszustände sind moduliert. (z.B. PWM)
(Gilt für die betroffenen DE-Baugruppen)

Da-Baugruppe nur für Heben und Senken.

OB87
Die CPU geht nicht in den Betriebszustand STOP, wenn der OB 87 nicht programmiert

ist.
Die Kommunikation wird über FCs zu einer C312 durchgeführt.
Ich gehe davon aus, dass es mal anlaufprobleme gab und somit die C313C zu schnell

reagiert, weil die C312 noch nicht bereit war...
--------------------------------------------------------------------------------
Maximal könnten die DB-Werte auf Initialwert zurückgesetzt werden. War letztens hier

bei 315/317 ern von " IBFS " aufgetreten einfach mal danach suchen.
--> Werd ich dann mal gucken... Danke
--------------------------------------------------------------------------------


Fehlersicherheit
----------------
Ich nehme mal an, dass man mit einer F-CPU und normalen DE/DA Baugruppen keine

Kategorie 3/4 erreichen kann?
Als wie sicher gilt den der Rückverdrahtungsbus?



Vielen Dank schon mal für eure weiteren Beiträge :)
 
Zurück
Oben