Beiträge

Ich habe mich bisher nicht mit der Network Lib beschäftigt, und auch die Beschreibung von IP_Control und IP_Control_2 sagt mir relativ wenig.

Der Name hört sich allerdings an wie die Steuerung eine TCP-Verbindung. Es gibt von Siemens ein paar (Know-How-geschützte) Bausteine zum Arbeiten mit der integrierten PN-Schnittstelle:

• FB65 TCON: Verbindungsaufbau
• FB66 TDISCON: Verbindungsabbau
• FB63 TSEND: Daten senden
• FB64 TRCV: Daten empfangen

Ausserdem gibt es zur leichteren Handhabung noch ein paar zusätzliche Bausteine (ohne Know-How-Schutz) bzw. Tools zur Einstellung der Kommunikations-Paramater:

• FC97 SET_TCP_ENDPOINTx: Einstellen der Verbindungsparameter vom S7-Programm aus (siehe hier: http://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo&objId=32048373&load=treecontent&lang=de&siteid=cseus&aktprim=0&objaction=csview&extranet=standard&viewreg=WW)
• Open Communication Wizard bEinstellen der Verbindungsparameter über ein Windows-Programm (siehe hier: http://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo&objid=25209116&nodeid4=20229805&switchLang;25209116;1.x=34&switchLang;25209116;1.y=4&lang=de&siteid=cseus&aktprim=4&objaction=csopen&extranet=standard&viewreg=WW)

Ich hoffe ich konnt helfen...
skotti

Thanks for sharing your knowledge with me.
I have been trying to set up de CTRL_PID controller on the position control of 1 cilinder.
At first i hade troubles with the speed of the position feedback. The sample time of the analog input card was >100ms. No go.
I have bought a new analog input card with 2,5ms interval. Cpu cycle time around 6ms.
The cilinder needs to travel 200mm in 1,5sec i know the system is to sloo to make a exact position control. (cilinders travels at 0,13mm/s).
I 'am using the PID function as P controller. I and D are zero. If i try to ad the I or D i get a really unstable oscilating system.... (P=4,I=0,D=0).

I will try your idea of using the sramp function to control the setpoint. Does this mean i need the PID controller to be aggrasive to react fast at small setpoint changes doesnt it?

If you use only a PID control (input: diff between actual and target position) you will have an extreme raising output when the axis starts. I use this method sometimes to move hydraulic axes, but those axes don't move very fast. The advantage is that I can limit the output to a desired speed value. So the axis will move with a constant speed towards the target position. When it reaches the target area the PID comes into action. And you need an acceleration ramp for the target speed within your drive, this limits the jump when the axis starts (I usually use servo drives, they provide ramps for accel and deccel of the command speed). As already told before: This is used for slow axes with slow to medium speed and high accuracy of reaching the target pos.

The idea I have described previously was to use SRAMP to create a target position ramp. The diff between the SRAMP-output and the actual position is the input for the PID control. SRAMP generates acceleration and deceleration ramps (the ramp has the shape on an trapeze).
In this case there should be no accel/deccel ramps active in your drive / analogues output / amplifier card, so that the motor speed can follow the PID output without any delay.

This is how the position control of a servo drive works. But servo drives usually have no other work to do beside, so they have a quick response time (cycle times normally are less than 1ms).

So dont't expect a high performance positioning control when using a PLC with 6ms cycle time and a 2,5ms response from the analogue input (dont't forget the response time of the hydraulic control). If your hardware is limited to those values mentioned above you should use an external positioning control.

[X : REAL; (* desired value *) Y : REAL; (* actual value *) V : REAL; (* actual velocity *)]

Ansonsten wäre es noch wünschenswert, wenn die Ein- und Ausgänge mit Kommentaren versehen wären:

   X : REAL;            (* desired value *)
   Y : REAL;            (* actual value *)
   V : REAL;            (* actual velocity *)

Dem möchte ich definitiv zustimmen:

Kommentare (in englisch) wären hilfreich! Man müsste dann nicht mehr für jeden Baustein in die Dokumentation schauen.

MfG
skotti

Soll das Panel selbsttätig den Zustand abfragen und anzeigen?
Oder kann die SPS das erledigen und den Status in einem Datenbaustein zur Anzeige ablegen?

MfG
skotti

A couple of years ago I have programmed a position control using the functions "SRAMP" (calculates the ramp command position with acceleration and deceleration) and a PID control for the analogue output.

But I had a linear axis (asynchronous motor with frequency converter and an ENDAT encoder feedback). The speed was 220mm/s (with workpiece) up to 300mm/s (empty) and acceleration 300mm/s.
I'm afraid that for such a dynamic hydraulic axis you need a fast CPU and fast analogue inputs to avoid overshoot at the final position of the axis.

Regards,
skotti

Hallo gravieren.

Entschuldige die späte Antwort. Leider lese ich nur sehr unregelmäßig hier.

Thema Über-/Unterlauf:
Ich bin eigentlich von anderen Geber-Typen gewohnt, daß man an sie einen Referenz-Offset schreiben kann und die anschließend ausgegebenen Positionswerte dann schon korrigiert sind. Bei SSI-Gebern scheint so etwas aber nicht vorgesehen zu sein (das Protokoll sieht keinen Rückkanal vor). SSI-Geber melden also immer nur ihre aktuelle Position relativ zu einem Werksseitig eingestellten Referenzpunkt an die Steuerung. Offsets müssen daher in der Steuerung verrechnet werden.

Bei einem linearen Geber ist das kein Problem, da der Nullpunkt in einem Bereich liegt, der physikalisch nicht erreicht wird. Auch das andere Ende des Messbereichs stellt kein Problem dar, da bei der vorgegebenen Auflösung der Positions-Daten am Messbereichs-Ende noch kein Überlauf stattgefunden hat.

Bei rotativen Gebern sieht die Sache allerdings etwas anders aus. Hier kann selbstverständlich ein Über-/Unterlauf stattfinden. Und dies kann im ungünstigsten Fall je nach Einbaulage mitten im gewünschten Messbereich stattfinden.

Thema Gebertausch:
Natürlich muß vorausgesetzt werden, daß bei einem Tausch des Gebers dieser gegen den gleichen Typ ausgetauscht wird. Sollte dies aus irgendwelchen Gründen nicht möglich sein, ist es IMHO vertretbar daß im SPS-Programm angepasst werden muß.

Thema Diagnose:
Diese Art der Anzeige von Geberwerten habe ich mir schon länger angewöhnt. Aber ein Diagnose-Bild bringt mich kaum weiter bei der Lösung des Problems wie die Werte in der SPS korrekt verarbeitet werden.


Nochmal kurz meine Problembeschreibung:
Wird ein rotativer Geber an einer Linearachse so eingebaut, daß der Geber-Nullpunkt ausserhalb des mechanischen Verfahrbereichs liegt, gibt es kein Problem. Einfach einen Offset addieren/subtrahieren und gut is.
Liegt der Nullpunkt aber im Verfahrbereich so muß ich einen Über-/Unterlauf erkennen und von dort weiterzählen.

Wie schon gesagt: Die Lösung des Problems ist definitiv möglich (bei anderen Absolutwert-Geber-Typen funktionierts ja), nur ich finde irgendwie nicht den Weg dorthin. :-)

MfG
Skotti

Aktuelle_Position_mm :=  Offset_mm  + ( Inkremente * mm_pro_Inkremente)

Der SSI-Geber hat eine Auflösung von 24 Bit. Von der SM338 erhalte ich also einen Zahl im Bereich von 0 bis 2^24-1. Wird die 0 unterschritten so geht die Zählung schlagartig bei 16777215 weiter abwärts.

Die Lösung ist wahrscheinlich einfach, aber irgendwie habe ich da gerade eine Denkblockade.  :)

Gruß,
Stefan

Hallo liebe OSCAT-Gemeinde.

Ich arbeite gerade an einer Anlage mit Multiturn-SSI-Absolutwertgebern die an eine Siemens SM 338 POS-INPUT (6ES7 338-4BC01-0AB0) angeschlossen sind.

SSI-Geber liefern meines Wissens immer nur ihre Absolut-Position relativ zu einem fiktiven Nullpunkt. Das heißt den Nullpunkt-Abgleich muß ich in meinem Anwender-Programm herstellen. Ist das korrekt?

Die Geber in meiner Anlage sind soweit gut eingebaut, als daß auf dem gesamten Verfahrbereich kein Überlauf bei der 4096sten Umdrehung auftritt. Ich frage mich aber trotzdem: Was Wäre Wenn?...

Ich möchte gerne einen Baustein schreiben, der einen SSI-Geber auswertet inkl. Vorwahl der Auflösung (Inkremente/Millimeter) und Nullpunkt-Offset (Millimeter). Stand schonmal jemand vor dem gleichen Problem, hat es gelöst und würde sein Programm mit mir teilen? Oder können wir vielleicht zusammen eine Lösung erarbeiten?


Danke,
Stefan

Hallo Michael.

Schau mal hier rein: http://www.oscat.de/community/index.php/topic,133.0.html
Und bringe das Thema nochmal 'On Top'.  :)

Thx,
Stefan

Ich habe EMC bisher noch gar nicht eingesetzt und kenne ehrlich gesagt auch keine Preise dafür. Wenn die Preispolitik aber ähnlich ist wie bei den restlichen Siemens-Produkten muss es wohl ziemlich teuer sein.
Wie schon gesagt: Ich habe mal etwas auf Basis des Bausteins SRAMP geschrieben, ist aber (bis jetzt) noch keine vernüftige Lösung.

Danke für die Beta.
Gibt es irgendwo einen kurzen Text wo man nachlesen kann was sich geändert hat?

Skotti

Also ein paar Bausteine für einen Sollwertgenerator und Lageregelung wären toll. Ich habe kürzlich auf Basis des Bausteins SRAMP einen einfachen Sollwertgenerator in Step7 programmiert, aber Sonderfälle (wie z.B. Positionierabbruch, Soll-Geschwindigkeits-/Beschleunigungsänderung während der Positionierung, etc.) nicht zu Ende programmiert. Im Netz ist aber leider auch nichts passables zu finden.

Daher ruht meine Hoffnung auf dieser Community, einen kostengünstigen (kostenlosen) Ersatz für "Easy Motion Control" zu erstellen. Gerne bin ich bereit dabei zu helfen, allerdings sind meine Programmierkenntnisse auf Step7 KOP/AWL/SCL und ein wenig Codesys ST beschränkt.

Skotti

Add 1) I think that within a single PLC cycle time is frozen, therefore there is no reason to read system time more than once.
         Therefore tx shoul be stored at a central location (DB or M) and normal functions should only read this.
         Cyclic initialization of tx should occur at the beginning of each cycle only once.
         This is especially stands for STIME, since in a normal control program it might be called many many times.
Add 3) It might be necessary to update tx within a PLC cycle in some cases - although I do not see a reason now.

It is necessary, because some functions could be started in different OBs (for example OB35 etc.). Or the OB1 cycle is interrupted by another OB and therefore the OB1 cycle time is increased.

Skotti