Hallo zusammen,
@Superkater
...Sicher kann man einen ungenauen Gleichlauf mit EPOS und DCC machen...
1. Wenn beim EPOS das Telegramm 110 oder 111 aufegschlten wird, kann man KEINE stetige Sollwertübernahme durchführen. Bitte nichts behaupten, wenn man sich nicht genau informiert.
2. Wenn man in der CU320-2 1500 DCC Blöcke programmiert und zyklisch laufen lassen wollte, kann man keine Achse projektieren.
zur Eingangsaussage: Was verstehst Du unter einem ungenauen Gleichlauf?
Von einigen Jahren bei der SPS/Drives in Nürnberg war (ich glaube von B&R) ein Gleichlaufmodell. Dort wurden kleine Jägermeisterfläschchen die auf Antriebsscheiben befestigt waren, über Synchronmotoren rotiert. Bei ca. 3000 min-1 (=18°/ms) wurden die rotierenden Scheiben zusammengefahren, ohne dass sich die Fläschchen berührten.
Das habe ich mit dem S120 und dem EPos Gleichlauf ausprobiert. Dazu nimmt man ein Stroboskop und macht zwei Markierungen an der Motorwelle (die Jägermeisterfläschchen wären blos schnell leer gewesen und dann hätte ich keinen Bock mehr zum Arbeiten gehabt). Selbst bei 6000rpm habe ich keine Abweichung erkannt, obwohl ich noch extra Achsen simuliert mitgerechnet habe um die Rechenzeit an die Auslastungsgrenze zu treiben (außerdem kann man ja auch alles mittracen).
Aber kauf ruhig die T-CPU, da hat SIEMENS bestimmt nichts dagegen.
zu 1.) Ich habe die EPos- Eigenschaften beschrieben und nicht den Telegrammaufbau. Mit Tel 111 (nicht mit 110) wird sowohl Parameter p2649, wie auch p2653 versorgt. Damit lassen sich z.B. Anwendungen realisieren, wo man fliegend zwischen Einrichten und Positionieren umschalten kann. Z.B. kann man Produkte unbekannter Länge (z.B. Holz) in der Betriebsart Einrichten transportieren, mit einem Sensor wird z.B. die Holzkante erkannt (bei Bedarf wird noch die Achse fliegend referenziert) und anschließend absolut positioniert.
zu 2.) Mit der alten CU habe ich schon 700 Bausteine und drei Achsen am laufen gehabt. Angeblich geht mit der neuen über das Doppelte (das habe ich aber auch nur mal bei einem Messebesuch erfahren und - muss ich zugeben - nicht ausgetestet). Da in einem Wickler sicherlich auch einige Bausteine laufen wie Durchmesserrechner, Komforthochlaufgeber, PID- Regler, ... benötigen die sicherlich mehr Speicherplatz als einfache Logikglieder. Wenn ein die Berechnug für einen fliegenden Rollenwechse dabei ist sicherlich noch mehr. Da ein Wickler meist auf einem VECTOR- Antrieb läuft (der ohnehin mehr Rechenzeitbedarf hat), hat sich der Verfasser evtl. einfach mal auf die sichere Seite gelegt? Am besten mal ausprobieren - wenn man eine Wicklerfunktion auf seine eigene Ansprüche schreibt, kommt man sicherlich mit weniger Bausteinen aus, als bei einer Applikation, die sämtliche Wicklerbetriebs-/regelungsarten abdeckt.
@Markus - Meinung zu DCC:
selbst bei einfachen sachen wie einer flankeauswertung muss man akribisch auf die ablauffolge achten.
meiner meinung wäre eine hochsprache da wesentlich effektiver, und von leuten die quasi die firmwarefunktionalität eines FU ändern darf man auch erwarten dass sie diese ausreichend beherrschen.
Das kommt auf die Anwendung an. Wenn ich Regelungsstrukturen aufbaue, dann bietet sich DCC/CFC an.
Wenn es darum geht SPS- Logik nachzubauen (weil ich z.B. in meiner Anwendung nur ein HMI und den Drive habe), wirds mit DCC unübersichtlicher. Bei Schrittkettenprogrammierung und Fallunterscheidungen nimmt man lieber eine Hochsprache (auch nicht KOP/FUP - da habe ich auch schon geflucht). Dazu verkauft Dir SIEMENS bestimmt gerne eine SPS.
Mit dem OB61 hat man heute die Möglichkeit synchronisiert zum Kommunikationsbus und somit zu Antrieb (der sich bei Taktsynchornität darauf synchronisiert) zu arbeiten.
Viele Grüße
Zako
