-> Hier kostenlos registrieren
Hallo,
ich habe eine Reihe von ähnlichen Maschinen. Die Steuerungen sind so strukturiert, dass etwa 90% der FBs gleich sind. Die Unterschiede zwischen den Maschinen stecken in den restlichen 10 %. Bisher hat jede Maschine ihre eigene Solution. Es wird aber langsam sehr aufwendig die Änderungen an den gemeinsamen 90 % in die diversen Einzel-Solutions zu übertragen. Besonders ungünstig ist folgendes Szenario:
Änderung an Maschine A. Projektdatei von A wird auf dem Server abgelegt. Bevor sich eine Gelegenheit ergibt, die Änderungen auf die Maschinen B und C zu übertragen, haben B und C bereits ihre eigenen Änderungen entwickelt. Dann sitzt man mit dem Projektvergleichstool und vergleicht A mit B und C, B mit C und A, C mit A und B. Dabei muss man jedes Mal prüfen, ob die Änderungen den maschinenspezifischen Teil betreffen (kein Problem) oder den allgemeinen Teil (übertragen, aufspielen, testen, freigeben). Das Skaliert sehr schlecht!
Mein erster Ansatz war es, die gemeinsamen FBs in eine Library zu packen, welche dann in die einzelnen Projekte eingebunden wird. Nachteil ist aber, dass bei Änderungen an der Library kein Onlinechange mehr möglich ist. Das würde die Entwicklungsarbeit sehr behindern.
Ich könnte mir Folgendes vorstellen:
Eine Solution mit mehreren Projekten. Ein Projekt pro Maschine, dass die Hardware und die Maschinenspezifischen FBs enthält. Ein Projekt mit den allgemeinen FBs. Alles in einer Solution. Das Szenario sähe jetzt so aus: Änderung an Maschine A, Vergleich mit der letzten Version auf dem Server. Im Projektvergleich sieht man direkt, ob sich die Änderungen auf das maschinenspezifische Projekt beschränken (-> einfach einchecken), oder ob allgemeine Programmteile betroffen sind (-> erstmal Nebenversion, einchecken nach Test auf den anderen Maschinen). Man musste nur noch einen Projektvergleich machen und könnte sich darauf verlassen, dass der allgemeine Teil wirklich immer gleich ist.
Problem: FBs aus anderen Projekten können nicht genutzt werden. Was im Allgemeinen auch irgendwie sinnvoll ist ;-)
Mit dem Beckhoff Variantenmanagement habe ich schon etwas herumexperimentiert, bin damit aber noch nicht richtig warm geworden. Das führt bei mir zu eher unübersichtlichen Konstrukten. Kann aber auch sein, dass ich das System ungeschickt benutze.
Wie handhabt ihr das? Da es immer viele Wege zum Ziel gibt, schreibe ich mal noch ein paar Worte zu meinen Randbedingungen und Überlegungen:
Lieben Gruß
alb
ich habe eine Reihe von ähnlichen Maschinen. Die Steuerungen sind so strukturiert, dass etwa 90% der FBs gleich sind. Die Unterschiede zwischen den Maschinen stecken in den restlichen 10 %. Bisher hat jede Maschine ihre eigene Solution. Es wird aber langsam sehr aufwendig die Änderungen an den gemeinsamen 90 % in die diversen Einzel-Solutions zu übertragen. Besonders ungünstig ist folgendes Szenario:
Änderung an Maschine A. Projektdatei von A wird auf dem Server abgelegt. Bevor sich eine Gelegenheit ergibt, die Änderungen auf die Maschinen B und C zu übertragen, haben B und C bereits ihre eigenen Änderungen entwickelt. Dann sitzt man mit dem Projektvergleichstool und vergleicht A mit B und C, B mit C und A, C mit A und B. Dabei muss man jedes Mal prüfen, ob die Änderungen den maschinenspezifischen Teil betreffen (kein Problem) oder den allgemeinen Teil (übertragen, aufspielen, testen, freigeben). Das Skaliert sehr schlecht!
Mein erster Ansatz war es, die gemeinsamen FBs in eine Library zu packen, welche dann in die einzelnen Projekte eingebunden wird. Nachteil ist aber, dass bei Änderungen an der Library kein Onlinechange mehr möglich ist. Das würde die Entwicklungsarbeit sehr behindern.
Ich könnte mir Folgendes vorstellen:
Eine Solution mit mehreren Projekten. Ein Projekt pro Maschine, dass die Hardware und die Maschinenspezifischen FBs enthält. Ein Projekt mit den allgemeinen FBs. Alles in einer Solution. Das Szenario sähe jetzt so aus: Änderung an Maschine A, Vergleich mit der letzten Version auf dem Server. Im Projektvergleich sieht man direkt, ob sich die Änderungen auf das maschinenspezifische Projekt beschränken (-> einfach einchecken), oder ob allgemeine Programmteile betroffen sind (-> erstmal Nebenversion, einchecken nach Test auf den anderen Maschinen). Man musste nur noch einen Projektvergleich machen und könnte sich darauf verlassen, dass der allgemeine Teil wirklich immer gleich ist.
Problem: FBs aus anderen Projekten können nicht genutzt werden. Was im Allgemeinen auch irgendwie sinnvoll ist ;-)
Mit dem Beckhoff Variantenmanagement habe ich schon etwas herumexperimentiert, bin damit aber noch nicht richtig warm geworden. Das führt bei mir zu eher unübersichtlichen Konstrukten. Kann aber auch sein, dass ich das System ungeschickt benutze.
Wie handhabt ihr das? Da es immer viele Wege zum Ziel gibt, schreibe ich mal noch ein paar Worte zu meinen Randbedingungen und Überlegungen:
- Versionsverwaltung mit Git.
- Es sind Entwicklungsmaschinen, an denen häufiger Anpassungen vorgenommen werden. Know-How-Protection und Zugriffsschutz spielen keine große Rolle.
- Entwicklung und Tests meist lokal an den Maschinen während Wartungs- und Stillstandszeiten.
- Es sollte möglichst einfach und übersichtlich funktionieren. Besonders wichtig wäre mir, dass es für den Entwickler immer offensichtlich ist, ob er einen maschinenspezifischem FB oder an einem allgemeinen FB vor sich hat.
- Bisher werden Änderungen an den gemeinsamen Programmteilen bei Gelegenheit auf die anderen Maschinen übertragen, getestet und dann freigegeben.
Lieben Gruß
alb
(1-mal am Ende von X) <> (n-mal in X) insbesondere für n >> 1
