OPC Zugriff auf S5

Hallo Leute,

ich bin grad dabei einen Zugriff über einen OPC Server (SIMATIC.NET) auf eine Siemens S5 herzustellen.
Außerdem muss ich da mit einem C# progrämmchen drauf zugreifen können.

Nun hat mir aber da jemand von FETCH und SEND was ins ohr geflüstert.

muss man da bei dem C# proggy was beachten, oder liegt das nur an der OPC Konfiguration. habe schon so ein c# proggy für eine S7, und wenn das nur am OPC Server liegt, dann muss ich das proggy nicht erweitern...

Grüße
David

david.ka schrieb:

Hallo Leute,

ich bin grad dabei einen Zugriff über einen OPC Server (SIMATIC.NET) auf eine Siemens S5 herzustellen.
Außerdem muss ich da mit einem C# progrämmchen drauf zugreifen können.

Nun hat mir aber da jemand von FETCH und SEND was ins ohr geflüstert.

muss man da bei dem C# proggy was beachten, oder liegt das nur an der OPC Konfiguration. habe schon so ein c# proggy für eine S7, und wenn das nur am OPC Server liegt, dann muss ich das proggy nicht erweitern...

Grüße
David

Zum Vergrößern anklicken....

Hast doch damals den OPC Client für C# von mir bekommen. Den solltest du natürlich auch für einen S5 OPC Server verwenden können. Das ist ja relativ egal! Zur S5 Kommunikation in Richtung OPC Server kann ich dir nicht viel sagen, zu alt für mich!

david.ka schrieb:

Hallo Leute,

ich bin grad dabei einen Zugriff über einen OPC Server (SIMATIC.NET) auf eine Siemens S5 herzustellen.
Außerdem muss ich da mit einem C# progrämmchen drauf zugreifen können.

Nun hat mir aber da jemand von FETCH und SEND was ins ohr geflüstert.

muss man da bei dem C# proggy was beachten, oder liegt das nur an der OPC Konfiguration. habe schon so ein c# proggy für eine S7, und wenn das nur am OPC Server liegt, dann muss ich das proggy nicht erweitern...

Grüße
David

Zum Vergrößern anklicken....

Hallo,
Wie die Daten vom OPC-Server von der SPS geholt werden (FetchWrite oder SEND/RECEIVE) betrifft nur den OPCServer und die SPS. Dein OPC-Client (C#-Prog) erhält die Daten vom OPC-Server, genau wie bei allen anderen OPC-Servern.

Du musst allerdings wissen, welches Protokoll die SPS zur Datenübertragung verwendet, um den OPC-Server richtig zu konfigurieren.
Ich nehme mal an, wenn die S5 einen Ethernet-CP 1430 hat, dass entweder FetchWrite über ISO-On-TCP (RFC1006) verwendet wird, oder bei einem älteren CP FetchWrite nur über das ISO-Protokoll ([SIZE=-1]ISO 8073)[/SIZE].

Das heißt:
1. Der OPC-Server muss richtig auf die SPS-Datenübertragung konfiguriert werden, dazu muss man aber genau wissen welches Protokoll die SPS verwendet.

2. Das OPC-Client Programm funktioniert wie immer, egal welches Protokoll der OPC-Server mit der SPS abhandelt. Der Sinn von OPC besteht ja gerade darin, eine einheitliche Schnittstelle für den SPS-Zugriff zu schaffen ohne etwas über duie unterliegenden Protokollschichten zu wissen. Nur derjenige der den OPC-Server konfiguriert muss das wissen.

Gruss
bimota

Guten Morgen

Beachte aber das es etwas schwer ist einzelne bits abzufragen bzw zu schreiben.

wir hatten das vor einiger zeit mal getestet aber die s5 hatte zu viele einschränkungen was uns die verbindung zu einen OPC client unmöglich machte .

client konnte nur mit bits arbeiten s5 wollte aber mit bytes arbeiten

mfg

locke

Hallo,

kpeter schrieb:

client konnte nur mit bits arbeiten s5 wollte aber mit bytes arbeiten

Zum Vergrößern anklicken....

Umkehrschluss ist also Client konnte keine Bytes verarbeiten ??? Eigentlich recht ungewöhnlich, da hätte ich vielleicht mal einen anderen Client versucht.

Gruss
Question_mark

Question_mark schrieb:

Hallo,
Umkehrschluss ist also Client konnte keine Bytes verarbeiten ??? Eigentlich recht ungewöhnlich, da hätte ich vielleicht mal einen anderen Client versucht.

Gruss
Question_mark

Zum Vergrößern anklicken....

Stimmt, komischer Client. Der ist dann doch nicht von mir.

wenn du eine laufmeldung abfragen willst für was dann bytes einlesen. einfache ersparniss von übertragungen.

oder nimmst du für jedes bit das du brauchst ein byte

Hallo,

kpeter schrieb:

einfache ersparniss von übertragungen.
oder nimmst du für jedes bit das du brauchst ein byte

Zum Vergrößern anklicken....

Bei z.B. IsoOnTCP ist die Mindestlänge der Nutzdaten 46 Bytes (physikalisch bedingt, da sonst ein Netzwerkadapter im Ethernet nicht funktionieren kann).
Daher ist es für die Netzbelastung völlig irrelevant, ob ich ein Bit, ein Byte oder 46 Bytes übertrage. Den Rest füllt das Protokoll sowieso auf 46 Bytes (von Dir unbemerkt) mit dem Wert "0" auf. Bei anderen Protokollen verhält es sich eigentlich nicht wesentlich anders, der Protokolloverhead bestimmt im wesentlichen die Belastung, ob nun Profibus, Ethernet oder was auch immer. Es geht also im wesentlichen darum, mir nicht die einzelnen Bits stückchenweise aus der SPS herauszupopeln. Wichtig ist eigentlich um einen schnellen, effektiven Datentransfer zu erreichen, die Daten z.B. in der SPS gepackt bereitzustellen (also ein DB- oder Merkerbereich) und in einem "Rutsch" zu übertragen. Befreit euch mal von dem Gedanken, irgendein Protokoll würde nur ein einzelnes Bit übertragen.

Gruss
Question_mark