Universalsoftware - Problem mit variabler Steuerungskonfiguration

[SoftwarePinguin]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,
vorab möchte ich anmerken das ich kein studierter Programmierer bin und meine Erfahrungen sie auf eine einzige Software beschränken.
Somit fehlt mir etwas die Erfahrung was unterschiedliche herrangehensweisen an Probleme betrifft.
Ich entwickle seit mehreren Jahren eine Software die stetig erweitert wird.

Der große Aufwand ist das diese Software für unterschiedliche Maschinentypen laufen soll.
Bisher wurde jede Maschine einzeln am Laptop konfiguriert und installiert.

Zukünftig soll dies aber direkt am Touchpanel von statten gehen und die SPS nicht mehr angefasst werden müssen.

Die Hardware stammt von Eaton, verschiedene Touch Panels wie z.b. XV100 oder XVS460.
Als I/O System steht eine XION Station zur verfügung die per Profibus an das Panel verbunden ist auf dem auch die Soft-SPS läuft.

Mein Problem ist nun folgendes:
Die Station muss in verschiedenen Maschinen aus verschiedenen Modulen bestehen.
kurz gesagt gibt es eine maximale Anforderung an die Ein und Ausgänge aber nicht jede Maschine brauch alle Module.
Diese sollen dann natürlich aus kostengründen und Platzgründen auch nicht eingebaut werden.

Meine Frage:
Ist es möglich hier eine sich selbst anpassende Steuerungskonfiguration zu entwickeln?
ich habe mich hier schon umgesehen aber konnte nichts passendes finden.
Das Problem ist eben wenn in der Codesys Steuerungskonfiguration ein Modul eingesetzt ist aber es ist tatsächlich nicht vorhanden im Aufbau dann meldet das I7O System zu recht einen Fehler.

Gibt es hier eine Idee oder einen Lösungsansatz der mir helfen kann oder komme ich nicht umhin für verschiedene Maschinen die Konfiguration anzupassen?


Vielen Dank für eure unterstützung.
Grüße
der Pinguin

 

[Blockmove]

Wir haben vor zig Jahren mal versucht sowas für einfache Anlagen auf Siemens-Basis zu entwickeln.
Hat auch funktioniert ... aber der Aufwand zum Konfigurieren war nicht geringer als das Zusammenkopieren der entsprechenden Module.
Wir haben es dann bleiben lassen.

Gruß
Dieter

 

[SoftwarePinguin]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
ja... so wie sich das gerade rauskristallisiert scheint der Aufwand enorm.
allerdings ist dies unbedingt nötig um eine inbetriebnahme ohne Laptop durchführen zu können und wäre auch für Softwareupdates eine große erleichterung.
Hast du einen tip wie ich vorgehen kann, so eine ungefähre richtung?

vielen dank

 

[Cassandra]

Hallo SoftwarePinguin,

da hast du keine einfache Aufgabe. Umgehe doch das Problem, indem du eine Software erstellst, die sich selbst weiter programmiert. Dann kannst du deinen Laptop getrost ausmustern.
Der mechanischen Fraktion kannst du ausrichten, dass sie alles so planen soll, dass man für die Montage auch kein Werkzeug mehr benötigt.

LG Cassandra

 

[SoftwarePinguin]

*smile*
ja, das wäre eine tolle Idee.
die Mechaniker belächeln mich sowieso immer mit den Worten: du mit deinem besseren Taschenrechner...

Abseits dieser Gedanken beherrbergt das Thema für mich jedoch auch einigen praktischen Nutzen.
Zum einen könnte jeder in der Firma ohne kenntnisse eine Maschine in Betrieb nehmen da sämtliche Konfigurationen schon automatisiert ablaufen bis auf die Steuerungskonfiguration.
Weiterhin kann ich mir aufgrund der verschiedenen Standorte auch einige Codesys Lizenzen für die Laptops spaaren...
Der wichtigste Punkt für mich ist jedoch das wir regelmäßig die Steuerungen Updaten.
Dies funktioniert mittels Stapelverarbeitung und USB Stick aktuell.
Der Nachteil ist das ich für jede Maschine die Konfiguration erstellen muss, und das Projekt dann auf den Stick kopieren was ein enormer Aufwand ist.
immerhin reden wir hier von ca 100 Maschinen pro Jahr.
Würde sich die Software dazu überreden lassen die Hrdware in betimmten Grenzen zumindest selbständig zu erkennen könnte man das alles stark vereinfachen.

Denkbar wäre auch das im live Betrieb die Steuerungskonfiguration verändert wird über das HMI allerdings fehlen mir hiezu jegliche Ideen.
Ich denke gerade über eine Installation per cmdfile nach was allerdings die Hauptprobleme nicht ändert... nur die Inbetriebnahme wird trivialisiert...

So long,
über jegliche Anregung freue ich mich.

Grüße,
der Pinguin

 

[Matze001]

Zuviel Werbung?
-> Hier kostenlos registrieren

<spass>

Installier doch auf jedem Panel die Codesys Entwicklungsumgebung, dann hast du was dein Chef will *renn*

</spass>

Ich kenne diese Möglichkeit des variablen Ausbaus nur von Siemens ET200s. Und selbst da soll es nicht ganz so trivial sein. Darf man fragen was diese Maschinen machen, vielleicht gibt es einen sinnvolleren Ansatz?

Grüße

Marcel

 

[Thomas_v2.1]

Wenn das mit den Programmupdate über USB-Stick generell funktioniert, wäre es evtl. möglich auf der SPS eine Textdatei abzulegen welche Programmvariante hier läuft.
Das Updateskript überprüft dann den Inhalt, und wählt dann die entsprechende Programmversion zum Update aus.

Für die Erstinstallation könnte man eine Art Bootloader schreiben. D.h wenn das Updateprogramm keine Konfigurationsdatei findet, lädt es ein Minimalprogramm, bestehend aus einer Minimalvisualisierung und einem Programm über das die Anlagenkonfiguration erstellt werden kann. Beim nächsten Update wird dann das zu dieser Konfiguration zugehörige Programm geladen.

 

[SoftwarePinguin]

Diese Maschinen sind Sondermaschinen im Nahrungsmittelbereich.
Dadurch das es eben X Varianten gibt unterscheidet sich der Steuerungsaufbau natürlich auch je nach Ausführung und Type der Maschine und Kundenwünschen.

@Thomas
Der gedanke klingt interessant.
Du meinst man fertigt praktisch für jeden Steuerungsaufbau ein Projekt und bringt dies dann alle auf die Steuerung wo dann anhand einer Textdatei oder eben cfg das korrekte projekt gewählt und ausgeführt wird?
Wie könnte sowas in der Praxis aussehen?

Danke für die Anregungen
Grüße,
der Pinguin

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Thomas
Der gedanke klingt interessant.
Du meinst man fertigt praktisch für jeden Steuerungsaufbau ein Projekt und bringt dies dann alle auf die Steuerung wo dann anhand einer Textdatei oder eben cfg das korrekte projekt gewählt und ausgeführt wird?
Wie könnte sowas in der Praxis aussehen?

War nur so eine Idee, weil du schreibst dass das Update über USB-Stick schonmal funktioniert.

Bei Codesys müsste man dann zumindest für jede mögliche Hardware-Konfiguration ein separates Projekt erstellen. Hängt von der Anzahl der möglichen Konfigurationen ab ob das praktikabel ist.
Ob das Programm hingegen soweit universell gestaltet werden kann müsste man prüfen.

Bei C hat man über den Präprozessor und entsprechende defines viele Möglichkeiten um ein Programm für eine bestimmte Hardware zu konfigurieren, sowas fehlt bei Codesys.
Man kann sich natürlich auch ein eigenes PC-Programm schreiben, das einem aus einem Basisprogramm ein für die Hardware angepasstes Programm zusammenstellt. Das wird aber wirklich aufwändig zu programmieren und auch zu warten.

 

[Blockmove]

Bei der Anzahl von Maschinen würde ich mich mal mit Eaton und 3S zusammensetzen.
Die Update-Problematik läßt sich sicherlich in den Griff bekommen.
Die Anlagenkonfiguration ist ein anderes Thema ... Aber ich denke, dass du hier mit einem entsprechenden Softwaremanagement besser bedient bist.
Evtl kann man hier mit Softwaremodulen, die abhängig von der Konfig zusammenkopiert werden.
Sowas lässt sich auch automatisieren.

Gruß
Dieter

 

[PN/DP]

vorab möchte ich anmerken das ich kein studierter Programmierer bin und meine Erfahrungen sie auf eine einzige Software beschränken.
[...]
Ich entwickle seit mehreren Jahren eine Software die stetig erweitert wird.

Der wichtigste Punkt für mich ist jedoch das wir regelmäßig die Steuerungen Updaten.

Warum regelmäßig updaten? Taugt Eure Software immer noch nichts? Reift die erst bei Euren Kunden?
Was sind das für Maschinen?

Was ist, wenn einige Eurer Kunden die "unnötigen" Updates nicht haben wollen, weil Eure Maschine vielleicht eines Tages mal zufriedenstellend funktioniert und die Kunden kein Risiko für neue Bugs oder verändertes/unberechenbares Maschinenverhalten eingehen wollen?
Dann müsst Ihr ja doch wieder pro Maschine ein eigenes Projekt haben, damit Ihr für den Servicefall wisst welcher Softwarestand auf der Maschine drauf ist.

Bezahlen Eure Kunden womöglich unterschiedliche Preise, je nachdem, welche Software-Module sie bestellt haben? Wie wollt Ihr sicherstellen, daß der Kunde die nicht bestellten aber in der Software vorhandenen Module ohne Bezahlen selber aktiviert?

Was kann im schlimmsten Fall passieren wenn die Maschine sich zur Unzeit einfach "umkonfiguriert" oder wegen Hardware-Defekten die Maschine ihre tatsächliche Konfiguration nicht korrekt erkennt?

Ich halte von solchen Ideen wie 1-Universalprogramm-für-unterschiedliche-Maschinen nichts. Das verkompliziert nur die Programme, bringt aber nicht wirklich was. Ich halte jeden Aufwand, ein solches Programm zu entwickeln, für vertane Mühe.

Harald

 

[SoftwarePinguin]

Zuviel Werbung?
-> Hier kostenlos registrieren

der punkt ist das wir im Bereich Nahrungsmittelmaschinen einer der wenigen Hersteller sind mit einem solchen System.
Daher kann man sich wenig abschauen und auf bewährtes zurückgreifen.
Weiterhin ist es eben so das immer mal wieder Kundenwünsche auftreten welche wir bemüht sind umzusetzen und auch anderen Kunden zur Verfügung stellen.
Und nein, in der Zwischenzeit ist es keine Bananen Software mehr die beim Kunden reift. ;-)

Tatsächlich ist es so das in der Dokumentation jeder einzelnen Maschine der Softwarestand der Maschine geführt wird um dies eben nachvollziehen zu können.
Kunden die keine alten Bugs haben oder keine neuen features haben wollen bekommen natürlich auch kein Update.

Es ist eben eine recht Aufwändige Geschichte wenn man sich selbst hinstellt und den Kunden Premiumware anbietet im Sondermaschinenbau.
Hinzu kommt eben noch die Typenvielfalt und die Tatsache das ich nicht jeden Tag von früh bis spät am programmieren bin.
Diese Software umfasst ca 80 verschiedene Maschinentypen und das ist noch untertrieben.

Alleine die Tatsache das 2 Verschiedene Frequenzumrichter zur Wahl stehen verschiedener Hersteller und das für jeden Typen macht die vielzahl deutlicher. Ein FU wird über Modbus, der andere über Profibus gesteuert...
Zufrieden bin ich mit alle dem auch nicht aber ich bin nicht der Geschäftsführer und muss sehen das ich aus dem möglichen das beste raushole.

Ich hoffe das meine Intention, die vereinfachung etwas an Hintergrund gefunden hat.

Grüße
der Pinguin

 

[Blockmove]

Hast du dir eigentlich schon mal ENI (Versionsverwaltung für Codesys) angeschaut.
Könnte dir das Leben vielleicht leichter machen.

Gruß
Dieter

 

[PN/DP]

Ich schreib mal drüber [OFF TOPIC], weil meine Meinung Dich mit Deiner Frage nicht weiterbringt.

Du versuchst also ein Universalprogramm zu schreiben, für "ca 80 verschiedene Maschinentypen" die womöglich nicht mehr gemeinsam haben, als daß vielleicht die gleiche CPU eingebaut ist?

Prahlst Du uns hier die Hucke voll? Das klingt mir ein bißchen so wie das 300-Teile-Heimwerker-Set: 1 Hammer und 299 verschiedene Nägel Sind Deine Maschinen vielleicht Waagen oder Printer?

Deine verschwommenen Andeutungen Eurer "Premiumware im Sondermaschinenbau" bestärken mich eher erst recht in meiner Auffassung, daß Dein Plan des Universalprogramms, was sich auch noch "selbst konfiguriert", unrealisierbar und/oder unsinnig ist. Eure Konkurrenz-Hersteller haben das vielleicht schon erkannt und Ihr seid deshalb die Einzigen und Letzten mit einer solchen "Idee"? Ich kann mir auch nicht vorstellen, daß Dein Universalprogramm - sollte es jemals realisiert sein - tatsächlich irgendwas einspart. Wie groß ist denn der einsparbare Teil am "enormen" Aufwand beim Erzeugen der Update-Sticks tatsächlich? 5 Minuten pro Maschine? Verbraucht der Inbetriebnehmer "ohne Kenntnisse" dann nicht vielleicht mehr Zeit damit, die Maschine zu konfigurieren, Seriennummern einzugeben, angepasste Rezepturen zu sichern und wiederherzustellen, in der Firma anzurufen bei jeglichem Problemchen ...
Wenn Eure Maschinen "Premiumware" sind, warum muß dann die Hardwarekonfig unbedingt aufs Nötigste abgespeckt werden, kann die Steuerung dann nicht immer die gleichen Hardwaremodule haben, auch wenn nicht immer alle gebraucht werden (von dem Frequenzumrichter mal abgesehen, dessen Typ Euch Eure Kunden wohl vorschreiben können)?

PS:
Maschinen in meinen Lebensmittelfabriken benötigen nach der IBN keine "regelmäßigen" Updates - Sie tun einfach ihren Job wie bei der Abnahme (sie sind höchstens mal kaputt).

Harald

 

[wonderfulworld]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,
also mit Elau/Epas (basiert auch auf Codesys) geht soetwas. Da kann man aus dem Programm die Steuerungskonfiguration ändern und die Steuerung auch wieder reseten. Das macht manachmal auch Sinn, ich hatte da Fälle, wo ein Kunde zwei Module mit unterschiedlich vielen IOs wollte, da ging soetwas. Auch weiß ich von einer Versuchsmaschine bei uns in der Firma die komplett am HMI konfiguriert werden konnte. Aber bei 80 verschiedenen Maschinentypen glaub ich, dass soetwas nicht sinnvoll ist. Da ist es vielleicht besser, wenn man sich aus gut gepflegten Vorlagen die Maschine zusammenkopiert eventuell lässt man sich dabei von einem Tool unterstützen, wie zum Beispiel das hier.
Die Idee alle 80 Varianten mit einem Programm zu erschlagen hört sich für mich nach etwas furchtbar schwer wartbares an. Damit treibst du wahrscheinlich die Pest mit der Cholera aus.
Gruß wonderfulworld

PS:
Unsere Sondermaschinen benötigen nach der IBN auch keine Updates. Es sei den, der Kunde besteht darauf, dass die nicht dokumentierten Features Bugs sind.

 

[SoftwarePinguin]

Hallo zusammen,
erstmal Danke für die Anrtegungen mit Elau. Das schaue ich mir mal an auch wenn es mir aktuell kein Begriff ist.

Um die Gemüter mal etwas zu beruhigen und ungerechtfertigte Vorwürfe aus der Welt zu räumen:
Unsere Maschinen sind nicht vergleichbar mit Standart Industrie Maschinen.
Normal macht eine Maschine vom Tag ihrer Inbetriebnahme bis zum Tage ihres Todes immer das selbe.
Beispielsweise eine Abfüllanlage füllt immer in die selben Behälter das selbe Produkt in der selben Menge.
Hier mag es ok sein eine Software zu programmieren und diese das ganze Maschinenleben nicht mehr anzupassen.

Unsere Maschinen sind im Großteil Koch/Kühl Maschinen bei denen 99 Programme vom Kunden konfiguriert werden können.
Jedes dieser Rezepte besteht aus bis zu 10 schritten wobei jeder Schritt aus 23 Parametern besteht.
Somit ist schonmal das erste Problem der starken Anpassungsmöglichkeiten klar.

Was die Zahl der Maschinentypen betrifft:
Unterteilt wird in 3 Gruppen.
1. Gruppe: Eismaschinen diese gibt es in 6 Füllmengen wobei 2 technische Konfigurationen möglich sind. verschiedene Antriebe je nach Füllmenge blähen das schon auf...
Keilriemenantrieb konstruktionsbedingt muss der Motor links rum laufen, Getriebe motor rechts rum...
und das ist nur der Anfang^^
2. Gruppe: Koch/Kühlkessel mit rundem Kessel und hohen Temperaturen durch geschlossenen Kühlkreislauf. ebenfalls 6 Füllgrößen, verschiedene Konstruktionen im Glykolkreislauf, teils mit elektrischem Deckelantrieb oder Zusatzventilen zur Wasserbefüllung etc pp. Es gibt einen Antrieb von oben oder von unten, Maschinenausführungen mit zusätzlichem Mixer stehen dabei auch noch in der Konfiguration.
Auch hier sieht man das die vielfalt echt böse zum programmieren ist.
3. Gruppe: Koch/Kühlkessel mit eckigem Kessel für Temperaturen bis 100°C. Kreislauf offen. hier schlägt es dem Fass den Boden ins Gesicht. Es können Maschinen von 40L bis 600L angeboten werden, 1-3 wannen pro Maschine. Jede Wanne bekommt je nach Füllmenge 1-3 Mixer, dazu 1-3 Heizstufen. Antriebe über Dahlandermotoren oder FU kommen hier noch dazu.

Somit sind die 80 verschiedenen Typen schnell erklärt.
Klar. Die Typen sind nicht Grundlegend komplett anders aber die Unterschiede sind teils enorm.

Der nächste Punkt ist das die Maschinen nicht die oft angenommenen Dimensionen haben. Es sind keine Fabrikmaschinen sondern Maschinen die in kleinen Produktionsstätten stehen.
Die Bediener sind auch nicht imer Genies und dazu kommt noch das man auch mal dinge programmiert die man total logisch findet aber die beim Kunden eben floppen.

Ich hoffe hiermit konnte ich etwas klärung schaffen und die vermutung ich würde aufschneiden aus der Welt schaffen denn ich mag nicht als "Schwaller" dastehen.
Altenativ biete ich auch gerne eine Werksbesichtigung an.

Ich hoffe dennoch auf Hilfe bei der umsetzung dieses Zieles betreffs der Konfiguration denn der Rest steht ja mittlerweile.
Und das war teilweise üble fummelarbeit bis alles gepasst hat. daher auch die enorme Entwicklungszeit.

Grüße und Danke schonmal
der Pinguin

 

[bits'bytes]

Hallo,
leider kann auch ich dir nicht sagen wie das bei deiner SPS zu bewerkstelligen ist, da ich das System nicht kenne.

Vielleicht kannst du ja das eine oder andere von dem Folgenden bei dir finden und für deine Umsetzung verwenden....

Bei B&R würde ich folgende Vorgangsweise wählen...

a) bestimmte I/O Module von aktiver Überwachung auf 'Abfrage' stellen. Dann würde bei gestecktem Modul einfach ein Status = 1 sein, bei nicht gestecktem Modul = 0, es wird keinen IO-Fehler geben. Dies aber nur falls unbedingt notwendig (Modulüberwachung ausgeschaltet)

b) Konzept bei B&R: eine Software - x beliebig viele Hardware Konfigurationen.

Jede Konfiguration wäre ein Maschinen - Typ. Man kann im Programm dann auch solche Compiler-defines verwenden wie z.B

#ifdef MACHINE_TYP1 

#elseif MACHINE_TYP2

....
#endif

oder

#ifdef ANTIREB_AGGR1_SERVO 

   action_Aggregat1_Servo                       // Programmteil für Servo-Ansteuerung

#elseif ANTRIEB_AGGR1_SCHRITTMOTOR

   action_Aggregat1_Stepper                      // Programmteil für Schrittmotor Ansteuerung

#endif

usw...

In jeder Konfiguration kannst du beliebige #defines hinterlegen (z.B. Aggregate welche mal vorhanden sind und dann wieder nicht).


Vielleicht hast du diese Möglichkeiten in deinem System in ähnlicher Form ? .....


bg
bb

 

[Fanta-Er]

Zuviel Werbung?
-> Hier kostenlos registrieren

mein vorschlag:
deine programme würd ich in drei gruppen aufteilen.
maximal aufbau mit strukturen aufbauen.
visu mit fast allen möglichen konfigurationen beinhaltet und den bild-/modulaufruf von der sps aus steuern
die ein/ausgänge indirekt in die datenbereiche umladen.
ein xml oder csv datei erstellen, welche OG, UG, Module und sonstiges als information enthält.
datei mit excel oder html erstelln (hier können grenzen für die einzelnen werte programmiert werden)
hardwarekonfig IMMER selbst erstellen (diagnose und zugriffsfehler sowie subrotinen durch fehlende module werden reduziert)
prg einspielen, datei einlesen und loskochen.

vorteile:
nach daten-/hardwarecrash wiederherstellung schnell und einfach (datei und bestehendes prg vorhanden)
konfiguration von projektleiter (jeh nach excel oder html cheat) möglich
Zeitaufwand für dich etwa 30min-1h + einspielen(hardwarekonfig)
nachteil:
das programm wird keiner mehr verstehen da alles indirekt und nur noch durch bedingte aufrufe geschieht
erstellen des ersten masterprogramme kostet zeit und eine lange ib phase (alle fehler und kofigurationen)
EA check unparametrieren der servos wirst immernoch machen müssen
mein vorschlag...

 

[wonderfulworld]

Vielleicht noch ein Tipp so am Rande, vielleicht ist es ja einfacher anstatt aus dem ganzen ein Programm einfach drei Programme zu machen. Für jede Gruppe eins. 3 Programme pflegen ist immer noch besser wie 80, aber man vermeidet ein absoluten Monsterbaustein.
Die Idee mit der CSV-Datei finde ich eigentlich auch ziemlich gut und würde das eventuell in deinem Fall auch so machen. Allerdings hört sich das Projekt was du da vor hast nach sehr viel Arbeit an. Ich würde mal tippen (so ganz aus der ferne), dass du da bestimmt 1 Mannjahr brauchst bis da alles läuft. Hast du den überhaupt soviel Zeit?
Gruß Wonderfulworld

 

[Werner29]

In CODESYS V3 gibt es genau dafür bei fast allen Feldbussen die optionalen Geräte. Beim Start wird geprüft, ob das Slavegerät vorhanden ist. Ist es da, dann werden die IOs ausgetauscht. Wenn nicht, dann läuft der Rest ganz normal weiter.
Bei Ethercat gibt es zusätzlich noch die Sterntopologie mit z.B. der EK1122 von Beckhoff. Damit können ganz Teile vom Bus abgekoppelt werden.

Es gibt auch die Möglichkeit im Code abzufragen, welches Gerät vorhanden ist.

Aber wie gesagt: das ist CODESYS V3.