Mit welcher Sprache??

A

Anonymous

Guest
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen
Mal eine ganz allgemeine Frage an Leute mit Erfahrung.
Ich bin zur Zeit selber noch in Ausbildung(Techniker), und dort gibts nur Antworten vom Grünen Tisch.
In welcher Sprache wird überlicherweise geschrieben, AWL , FUB oder (ich komm nicht auf den Namen) aehnlich Basic.
Ich könnte mir vorstellen das FUB bei einfachen Sachen benutzt wird, so das auch Facharbeiter warten koennen.
AWL wenn es Zeitkritisch wird und "BASIC" wenn es komplex wird.
Haette ich gern mal ne Meinung zu gehoert.
Schon mal Danke! :?: :?:
 
Die Sprachen FUP und KOP sollten Leuten mit einem bestimmten Vorwissen den Zugang zu SPS erleichtern.
FUP bildet in etwa logische Elemente nach, wie sie in ICs der TTL und CMOS Logikfamlien verwendet werden.
KOP bildet Schützsteuerungen nach.
Mit "BASIC" meinst Du sicher "structured text" (strukturierter Text?, ST). Dieser Sprache bildet algorithmische Abläufe besoders gut nach. Sie ist höheren Programmiersprachen, vor allem PASCAL, ähnlich.
AWL ist am nächsten an der Maschinensprache der CPU. Daher kann man die kürzesten Programme in AWL schreiben. Zeitverhalten ist dabei selten ausschlaggebend. Die meisten Programme, die ich gesehen habe, waren entweder in AWL oder einer Mischung von FUP und AWL geschrieben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi

na ob FUP und KOP den Zugang zur SPS erleichtern lass ich mal so stehn.
KOP mußte Siemens oder auch andere Hersteller machen damit Sie Ihre Steuerungen zB. in die USA verkaufen können. Dort programmiert man "nur" in KOP. Früher bei der S5 habe ich eigentlich nur in AWL meine Programme geschrieben. Das lag aber nicht daran das ich damit am nächsten an der Maschinensprache der CPU bin sonder weil man in FUP und KOP bei der S5 nicht alles machen konnte wie jetzt bei S7-Steuerungen.
AWL war damals die Sprache womit man alles programmieren konnte.

Heute programmiere ich in allen Sprachen.
Es ist eigentlich egal ob FUP,KOP,AWL. Nur im Online-Status finde ich persönlich FUP oder KOP angenehmer für die Augen als AWL.

Mit freundlichen Gruß
Christian
 
Also ich bin der Meinung das AWL immer noch das Maß aller Dinge ist.
FUP und KOP sind beim beobachten zwar sehr angenehm, dass stimmt aber in KOP und FUP ist immer noch nicht alles möglich bzw. sehr sehr sehr sehr sehr viel umständlicher . Da bleibt einem ja eigentlich nur AWL übrig.
Man kann auch die Ansicht wechseln wenn man möchte, von FUP nach KOP oder nach AWL. Wenn man sein Programm von AWL nach KOP oder FUP umschalten möchte, muss man sich allerdings wieder an bestimmte Regeln halten, was wiederum die Flexibilität einschränkt. Die meisten Probleme beim umschalten sind von Siemens Hausgemacht, warum die sich da so anstellen weiß ich nicht. Es gab mal für S5 ein Software die war toll, man konnte sein Programm in AWL schreiben und hat gleichzeitig in KOP das Ergebnis gesehen. Das hat in 95% der Fälle geklappt, ganz ohne Bildbaustein und NOP 0.
Die Hochsprachen, ob als Strukturierter Text oder als Graph oder HiGraph haben auch ihre Macken und sind mit überhaupt nicht so toll wie Siemens immer behauptet. Wenn man weiß was man will kann man sein Problem oft besser in AWL lösen als z.B. in Graph.
Was ich allerdings nur jedem raten kann, wenn er in AWL schreibt ist auf jeden fall Kommentare zu schreiben. Das ist sehr wichtig wenn auch noch nach sechs Wochen oder mehr sein eigenes Programm verstehen will. In der Praxis macht das allerdings kaum jemand, weshalb mindestens 90% aller Programme von Anfang an versaut sind.
 
Graph

Hallo casius,

trotz aller Macken ziehe ich bei einer Schrittkette Graph vor. Wer natürlich nur eine Linearkette mit 5 Schritten hat da isses egal. Aber haste schon mal in ne handgetippelte Schrittkette mit Alternativverzeigungen nachträglich Schritte und Absprünge eingefügt? Scheint nich so. Sonst hätteste ne andere Meinung.

MfG
André Räppel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi Casius

mit der Beschriftung oder Beschreibung der Programme hast du recht.
Das gilt aber für jede Programmiersprache.
Das Tool Graph von Siemens ist meiner Meinung nach einer der besten Tools die es gibt.
Klar der Standart FB frißt zwar etwas Speicher aber bei der Projektierung und bei der Fehlersuche ist Graph7 für Schrittketten einfach unschlagbar.
Außerdem ist die Bearbeitung in Graph schneller als in AWL.
Das liegt daran das in Graph nur der Schritt bearbeitet wird der aktuell ist und alle anderen Schritte übersprungen werden.
Von SCL und Higraph bin ich nicht so ein großer Fan aber das liegt bestimmt daran das ich diese Sprachen nicht sehr oft einsetze und mir dort die Erfahrung fehlt.

Mfg

Christian Werner

PS. Eigentlich ist es egal welche Sprache nur die Funktion ist wichtig.
Und ob jemand 4 Anweisungen oder 5,6 Anweisungen für sein Problem braucht spielt meiner Meinung nach keine Rolle.
 
8) Ich hab ja auch geschrieben, wenn man weiß was man tut ist es schneller in AWL eine Schrittkette zu schreiben, wenn man nicht so viel Erfahrung hat sollte man in der Tat besser mit Graph arbeiten.
Alternativschritte oder Schritte nachträglich einzufügen ist kein Problem, vorausgesetzt man arbeitet nicht immer noch mit Merkern und so einem Zeug. Die übersicht zu behalten ist auch kein Problem, vorausgesetzt man schreibt Kommentare, und die Kleinigkeit, dass immer nur ein Schritt aktiv ist, ist auch kein Problem. So und damit jetzt auch keiner meint ich würde immer nur Schrittketten mit fünf oder weniger Schritten schreiben, muss ich ebenfalls enttäuschen im Schnitt hat eine Schrittkette bei mir etwa 50 bis 100 Schritte, wobei 999 Schritte möglich sind.
Der große Nachteil von Graph7 ist der, dass man gezwungen wird absolut zu arbeiten, da bricht Siemens mit dem eigenen guten Vorsätzen, die ich sonst an der S7 so schätze. Sicher es ist möglich Lokalvariablen selbst zu definieren, aber derart umständlich, dass man es gleich bleiben lassen kann. Außerdem kann man die Fortschaltbedingungen nur in KOP oder FUP programmieren, bei Graph5 ging das auch in AWL, warum dass abgeschafft wurde kann ich auch nicht nachvollziehen.
Ich muss allerdings jetzt zugeben, dass ich mir Graph7 schon vor einer ganzen Weile angesehen habe und dann die Sache wegen der Nachteile verworfen habe. Es ist also durchaus möglich, dass Siemens inzwischen Verbesserungen vorgenommen hat, von denen ich nichts weiß.
 
Eine Bitte...

Hallo Casius!

Nachdem zu sicherlich bei vielen Lesern dieses Forums Interesse geweckt hast, folgende Bitte:

Könntest Du vielleicht einmal ein oder zwei Schritte Deiner Schrittkette (in AWL) exemplarisch darstellen, mit Weiterschaltbedingungen und so. Wäre nett, wenn Du - rein allgemein natürlich - einmal ein paar Prinzipien verraten würdest.... :roll:

Vielen Dank
Uwe
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi Casius,

so so wenn man nicht soviel Ahnung hat sollte man mit Graph7 arbeiten.
Das ist wirklich seit langem der größte Quatsch den ich hier gelesen habe.
Auf eine kleine Probe von Dir hier in AWL bin ich echt gespannt.
Ich weiß ja nicht wie lange Du schon mit der Programmierung von SPS-Steuerungen zu tun hast, aber ich mache das schon über 12 Jahre.
Früher zu S5 Zeiten habe ich sowas wie Schrittketten auch nur in AWL gemacht und kleine Schrittkette so 20 Schritte mache ich auch heute noch in AWL.
Aber wer nicht den Vorteil von Graph7 bei großen Ablaufsteuerungen erkennt der hat so glaube ich nicht aufgepasst oder macht sich selbst
gerne das Leben schwer.

netten Gruß

Christian Werner
 
Graph

Hallo casius,

da muss ich ausnahmsweise mal Christian rechtgeben ;-) Sorry, aber du scheinst keine Ahnung von Graph zu haben. Weisst du dass man seine "Automatikaktion" direkt im jeweiligen schritt zuweisen kann? ZB N "m_Greifer_1_oeffnen" und das auch in mehreren Schritten ohne dass man ne klassische Doppelzuweisung hat. Dass man per interner Flanke ohne besonderen Aufwand hochzählen kann. Dass man Interlocks programmieren kann und die Fehlersuche einfach genial wird. Bei der herkömmlichen Schrittkettenprogrammierung muss ich den Baustein öffnen und suchen wo die Kette grad steht. Bei Graph mach ich den Baustein auf, gehe in Status und sehe es gleich. Die Instandhaltung wirds dir auch danken wenn du Graph einsetzt. Aber so weit denkst du wahrscheinlich nich. Die etwa 600¤ sparst du an der falschen Stelle. Zuguterletzt noch ein Beispiel: Ich habe nen Baustein für Graph programmiert der automatisch die Info generiert ob Weiterschaltbedingungen erfüllt sind -> Endlich im Schrittbetrieb nicht mehr unkontrolliert rumdrücken sondern warten bis die Weiterschaltbereitschaft angezeigt wird.

http://www.sps-concept.de/download/print/T_READY.pdf

MfG
André Räppel
 
Tag die Herren,
meine Vorlieben sind immer noch:
KOP fuer die ganze Logik - denn hier kann der Elektriker selber Fehler suchen bzw. ist es bei der Inbetriebnahme einfach besser.
Alles andere in C (bietet zwar fast keiner an, aber immer noch mein Favorit) oder ST.
Da ich diese Vorlieben bei sonst keinem gefunden hab, mag es vielleicht an der Weiblichkeit liegen, die in dieser Branche nur sehr schwach besetzt ist !

Gruß,
Sonja
 
Zuviel Werbung?
-> Hier kostenlos registrieren
lazyiguana schrieb:
Da ich diese Vorlieben bei sonst keinem gefunden hab, mag es vielleicht an der Weiblichkeit liegen, die in dieser Branche nur sehr schwach besetzt ist !
Sonja
Na, ja oder eben daran, dass es fast keiner anbietet. STEP7 hat ja schon etliche(s) (Unarten) von C übernommen...
Wenn du SPS in C programmierst, würde es mich interessieren, wie der Zugriff auf einzelne Bits erfolgt. In Standard C bedeutet wird das immer recht umständlich mit ausmaskieren erledigt:
Code:
MW=MW &^0x40
Wenn der Ausdruck länger wird, finde ich es schwer, die Übersicht über die Rangfolge der Operatoren zu behalten und setze lieber überflüssige Klammern.
Keil hat beim Compiler für den 8051-Mikrocontroller (der kann Maschinenbefehle für einzelne Bits) einen besonderen Datentyp BIT eingeführt.
Da kann man dann wieder schreiben:
Code:
#define blink P0.4
blink^=blink;	// invertiert das Bit
blink=0;		// setzt dieses Bit auf 0
blink=1;		// setzt dieses Bit auf 1
blink=C & ~ACC.7	
[/quote]
Poste doch mal ein Beispiel!
 
Hallo,

hier ein Beispiel fuer das Ansprechen von Bits

#define BGT_SENDFLG (bgt_next_flg & 0x04) // if ...
#define S_BGT_SENDFLG bgt_next_flg |= 0x04 // SET
#define R_BGT_SENDFLG bgt_next_flg &= ~0x04 // RESET

// CODE
if (BGT_SENDFLG)
{
// tu dies und das

}




d.h. fuer jedes ansprechbare Bit wird ein Name vergeben + das Kuerzel fuer Abfrage ob es gesetzt ist bzw. setzen / reset.
Das ist zwar ziemlich ein Tipperei am Anfang, nur man arbeitet dann mit Namen und kann an 1 Stelle mal die ganzen Bits bei Bedarf verdrehen bzw. sieht ob noch was frei ist.
Weiters sei noch gesagt, dass ich C sicher nicht ausnuetze. Man koennte ja optimieren bis zum geht nicht mehr, nur mich ist wichtiger, dass ich in 1-2 Jahren das Programm auch noch lesen & verstehen kann. (nur zur Info: seit 2 Jahren programmiere ich mit Keil fuer einen 8051, davor ca. 3 Jahre B&R Automation Studio (das hat C), zwischendurch Siemens, Crouzet und vor vielen Jahren hat es mal mit Assembler, AWL bzw. Structured Text angefangen)
Gruß,
Sonja
 
:D
Hallo Leute, die Diskussion hier hat offensichtlich viel Interesse geweckt, ich möchte deshalb ein paar Anregungen zu dem Thema geben wie ein ordentliches Programm auszusehen hat. Ich hoffe Ihr seht das als freie Meinungsäußerung und nehmt das nicht so persönlich, wie es hier einige Leute machen. Ich habe nie behauptet den Stein der Weisen gefunden zu haben.

Meiner Meinung nach machen zwei Dinge ein gutes Programm aus:
1. Eine gute Kommentierung, die auch einem völlig fremden ermöglichen das Programm zu verstehen.
2. Seine Struktur
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie man sein Programm kommentieren sollte:

8) Ich finde es immer wieder überraschend, warum so viele Programmierer keine Kommentare zu ihren Bausteinen schreiben. Dabei kann man gerade dort oft mit einem einzigen Wort Klarheit schaffen, worum es im Baustein geht. Dadurch kann man auch noch nach Jahren einfach wieder ins Programm finden. Ich finde das ist ein ordentliches Aufwands/Ergebnis Verhältnis, das sich lohnt.

8) Noch viel überraschender finde ich, dass so viele Leute den Unterschied zwischen Symbol und Kommentar nicht begreifen wollen und sich so viel unnötige Arbeit machen. Da werden dann ganz tolle Symbole kreiert wie z.B.

FL_POS_RB011_EIN

Was hält eigentlich diese Leute davon ab, statt dieser tollen Abkürzung als Symbol, im Kommentar zu schreiben:

Flanke_Positiv_Rollenbahn011_ein

Ich finde das Erstaunlich, vor allen Dingen dann, wenn von vornherein feststeht, dass dieses Programm später übersetzt werden muss. Hätten Sie den Kommentar dahin geschrieben wo er hingehört, müsste niemand wie ein Irrer die Symbol übersetzen, einfach eine Übersetzungsdatei generieren, ab zum Übersetzungsbüro und dann wieder einlesen ist offensichtlich viel zu einfach.

8) Die Netzwerküberschrift wird auch häufig weggelassen. Warum eigentlich? Auch hier kann man wieder mit wenig Aufwand viel Erreichen. Wenn man das Programm nur grob verstehen möchte um eine kleine Änderung vorzunehmen ist dieser kleine Helfer doch wunderbar.

8) Den Netzwerkkommentar blenden sogar viele Programmierer einfach aus. Was ich völlig unverständlich finde. Gerade hier kann man sehr Sinnvolle Sachen rein schreiben, ich persönlich schreibe hier oft rein, was der Kunde so von mir verlangt hatte. Da stehen dann so Sachen drin wie:

Herr K. von Firma X, möchte das ich nicht auf dem Endschalter warte, sondern gleich mit dem Servo weiterfahren um Taktzeit zu sparen. Herr K. ist sich der Risiken bewusst und übernimmt die Verantwortung. Y-Hausen am XX.YY.ZZ

Das mag zwar kein Rechtlich geltender Beweis sein, hat aber schon oft meinen Hintern gerettet.

8) Der Zeilenkommentar, wenigstens der wird manchmal genutzt, oft genug aber selbst der nicht. Das finde ich auch immer wieder richtig toll. Liebe Mitprogrammierer, wenigstens diesen Kommentar sollte man ordentlich führen. Man sollte doch auch noch nach einem Jahr oder so in der Lage sein, sein eigenes Programm zu verstehen.

:!: Eine gute Kommentierung des Programms ist das A und O eines guten Programmierstiles. Sicherlich ist es auch mit Arbeit und Zeit verbunden, aber der Aufwand lohnt sich im jeden fall, ohne wenn und aber. Man kann eigentlich nicht zu viele Kommentare schreiben, je mehr desto besser, eine „Überdokumentation“ gibt es meiner Meinung nach nicht.
 
Wie man sein Programm strukturieren sollte:

Wenn man sein Programm gut Kommentiert hat kann eigentlich fast nichts mehr schief gehen, außer man programmiert immer noch S5 in eine S7.

Viele meiner Kollegen haben immer noch ein Problem damit sich an die S7 zu gewöhnen, dabei kann man sich die Sache jetzt viel einfacher machen.

8) Das wichtigste ist, dass man in sich geschlossene Bausteine schreibt, vom Merker sollte man sich also verabschieden, von ein paar Ausnahmen mal abgesehen. Sicherlich ist auch das mit etwas Arbeit verbunden, aber auch hier lohnt sich der Aufwand. Die Bausteine lassen sich mehrfach verwenden, es ist möglich sehr flexible Standartbaustein zu schreiben die sich einfach anpassen lassen und bei Programmänderungen kann man sich über die Folgen sicher sein.

8) Das hat auch zur folge, dass man sehr gelassen auf Verschiebungen im E/A Bereich reagieren kann, da Absolute Adressen nur an wenigen stellen im Programm vorhanden sind. Und mal ehrlich, die Sache mit der Funktion „Umverdrahten“ hat noch nie perfekt Funktionier, kleine Fehler bei der Bedienung haben oft fatale folgen.

8) Den Sinn und Zweck von Datenbausteinen hat offensichtlich auch kaum jemand begriffen. Wie sonst kann man es sonst erklären, das Variablen immer noch im Merkerbreich wild durcheinander hinterlegt werden. Dabei kann man es sich mit einem DB sehr übersichtlich und einfach machen. Am besten, in dem man den Datenbaustein strukturiert und Kommentiert.
Ich habe allerdings auch schon einen völlig verhunzten DB gesehen, da hat der liebe Kollege einfach einen Array angelegt und seine Daten dann einfach nach belieben rein geschrieben. Wer soll das eigentlich später nachvollziehen?

8) Was ich auch immer wieder finde sind selbst geschriebene Bausteine für Standartfunktionen, wie z.B. das Einlesen von Analogwerten. Da werden dann sehr kunstvoll die Bit’s hin und her geschoben und am Ende kommt doch nichts Vernünftiges dabei raus. Warum nutzen den niemand die Standartbausteine aus der Bausteinbibliothek?

:?: Zum Schluss noch ein andere Sache die ich immer wieder sehe, die passt zwar nicht zum Thema Struktur, ist aber sehr wichtig.
Warum wird eigentlich immer noch so viel sinnlos online rumprobiert? Dabei entstehen nur wild irgendwelche Programmstände, später hat man dann vier, fünf oder mehr Programmstände, bei jedem passen dann ein paar Bausteine und keiner passt so richtig. Wenn dann die CPU abkackt oder die Batterie schlapp macht ist das Geschrei immer groß und keiner will es gewesen sein.
 
:D Nun zum Thema Graph7.
Wenn ich mich recht entsinne, habe ich geschrieben, dass ich mich nur kurz mit Graph7 auseinandergesetzt habe. Ich bin durchaus lernfähig und währe sehr Dankbar, wenn mir jemand zeigen könnte wie man vernünftig mit Graph7 umgeht. Ich weiß auch nicht immer alles.

Ich sehe dabei folgende Nachteile von Graph7:

1. Die Transistionen lassen sich nur in KOP oder FUP programmieren, ich bevorzuge allerdings AWL, daran wird wohn niemand etwas ändern können, ich sehe es aber trotzdem als ernormen Nachteil.
2. Es reicht oft nicht die Ausgänge in der Schrittkette direkt zu setzen und fertig. Wenn ich jetzt einen Zylinder im speziellen betrachte stellt sich mir folgendes Problem. Ich möchte den Zylinder abschalten wenn er seine Endlage erreicht hat. Wie soll ich das mit Graph7 vernünftig lösen? Meiner Meinung nach muss sich so etwas im Baustein selbst lösen lassen, ohne einen zweiten Baustein und das klappt mit Graph7 nicht, ich weiß jedenfalls nicht wie.
3. Die Überwachungszeit lässt sich nur auf eine Transistion beziehen, ich weiß dann immer noch nicht warum der Baustein nicht weitermacht, welche Bedingung nicht erfüllt wird. Wenn ich jetzt wieder einen Zylinder betrachte, muss jede Endlage einzeln überwacht werden um eine vernünftige Fehleranalyse möglich zu machen. Sicherlich gibt es die Möglichkeit mit „ProAgent“ da etwas zu machen, aber dann laufen die Kosten völlig weg. Auch dieses Problem ließe sich lösen, wenn eine vernünftige Nachbearbeitung der Signale in Graph7 möglich währe, dass ist es aber nach meinem Wissensstand nicht möglich. Es bliebe nur wieder die Möglichkeit einen zusätzlichen Baustein zu schreiben.
:shock:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
casius schrieb:
Meiner Meinung nach machen zwei Dinge ein gutes Programm aus:
1. Eine gute Kommentierung, die auch einem völlig fremden ermöglichen das Programm zu verstehen.
2. Seine Struktur

3. Seine Funktionalität

Dabei meine ich nicht das die Anlage im normalen Automatikbetrieb das macht was es soll. Das ist eh minimum. Gute Programme erkennt man auch daran das bei "abnormalen" Zuständen entweder die Steuerung selbst richtig handelt oder das Bedienungspersonal rasch und logisch reagieren kann. Wie oft sehe ich z.B. folgendes:

Ein Lichtschranken wird versehentlich belegt. Maschine fährt einen "Schwachsinn". Irgendwann kommt dann eine Störung. Personal eilt herbei. "Automatik aus". Das der Handbetrieb nicht mehr funktioniert ist bekannt und wird gar nicht mehr versucht. Hauptschalter Aus. Ein paar Sekunden warten. Hauptschalter Ein. Alle möglichen "Grundstellungen fahren" (natürlich händisch). Alle möglichen Merker zurücksetzen. Die erste Charge dann noch im Handbetrieb fahren und dann nach 20min Produktionsunterbrechung wieder "Automatik ein".

Auf meine Frage warum man sich mit dem Zufrieden gibt heist es "Das war schon immer so" oder "das geht nicht anders" oder "Maschine wurde so geliefert, hat viel Geld gekostet, das hat schon seine Ordnung"
Da frage ich mich schon warum ich mich manchmal so plage, wenn man anscheinend mit weniger Aufwand mehr Geld verdienen kann...... :cry:
 
8)
Stimmt leider, die Methode Hauptschalter aus bei Störung findet man immer noch viel zu oft. (Meistens bei den Programmen die ohne Kommentare und mit Merkern geschrieben sind)

:D
Aber auch hier sehe ich meine Aussage nur bestätigt, wenn man eine vernünftige Struktur hat kann man auf solche Anlagenzustände reagieren, macht man die Sache nur irgendwie fertig, klappt es meist nicht.

:cry:
In den Meisten fällen wird bei solchen Programmen die Fehlerüberwachung nur durch einen einzigen Timer realisiert, solange die Maschine von einem Schritt zum anderen läuft wird der Timer immer wieder rückgesetzt, wenn er dann doch abgelaufen ist, geht eine rote Lampe an und fertig. Manchmal wird dann auch noch versucht anhand der Sensoren eine Fehlermeldung zu generieren, aber da wird nie etwas vernünftiges angezeigt. Solche Programme kenne ich zur genüge.

:D
Ich persönlich treibe da sehr viel mehr Aufwand, für jede Endlage gibt es eine separate Störmeldung, mit einem separaten IEC Timer. Klappt eigentlich wunderbar, bloß der Bediener muss dann noch mit der Störmeldung etwas anfangen können und sich zu helfen wissen. Es ist immer dumm wenn man sich viel mühe gegeben hat und der Typ dann doch zu primitiv ist.
 
Hi

Ihr hab ja recht schlechte Programme gibt es sehr viele und schlechte Programmierer noch viel mehr.
Wie Smoe schon geschrieben hat der Automatikbetrieb ist bei einem Programm/Anlage eigentlich der einfache Teil.

Die Methode Hauptschalter aus bei Störungen liegt aber bestimmt nicht am Programm sondern mehr an dem Bediener der wenig Ahnung hat.
Dann noch eine Frage an Casius!!
Programm mit Merker schreiben ist das für Dich ein schlechtes Programm???
Wo liegt eigentlich Dein Schwerpunkt in der Automobilindustrie???

mfg

Christian Werner
 
Zurück
Oben