# Daten auf RS232 Leitung beeinflussen



## Hansruedi (20 Dezember 2005)

Hallo

Ich habe eine Anwendung die 3964R verwendet realisiert. Nun muss ich den Nachweis erbringen, dass die Fehlerabhandlung im SPS-Programm gut ist bzw. sich nach den Vorgaben verhält.

Deshalb suche ich ein RS232 Analyzer oder Sniffer mit dem man Bytes oder Bits im übertragen Datenstrom gezielt manipulieren kann. Natürlich soll dieser möglichst günstig sein.

Wer weiss mehr zu diesem Thema?

Gruss Hansruedi


----------



## seeba (20 Dezember 2005)

Hansruedi schrieb:
			
		

> Hallo
> 
> Ich habe eine Anwendung die 3964R verwendet realisiert. Nun muss ich den Nachweis erbringen, dass die Fehlerabhandlung im SPS-Programm gut ist bzw. sich nach den Vorgaben verhält.
> 
> ...



Hmm einfach mit dem HyperTerminal etwas Mist hinschicken geht nicht?


----------



## Rainer Hönle (20 Dezember 2005)

http://www.hhdsoftware.com/sermon.html

Müsste mit der Professional-Version machbar sein.


----------



## Hansruedi (20 Dezember 2005)

Danke für den Tip, werde es ausprobieren

@seeba
Mit Hyperterm wir es sehr schwierig, da 3964R mit einem Byte-Handshake (STX 0x02 hin, DLE 0x10 her) arbeitet und dies in max. 550 ms ablaufen muss.

Gruss Hansruedi


----------



## Anonymous (20 Dezember 2005)

Hansruedi schrieb:
			
		

> Danke für den Tip, werde es ausprobieren
> 
> @seeba
> Mit Hyperterm wir es sehr schwierig, da 3964R mit einem Byte-Handshake (STX 0x02 hin, DLE 0x10 her) arbeitet und dies in max. 550 ms ablaufen muss.
> ...



Richtig!
Verwende doch einfach einen normalen Analyser zum Anzeigen der Daten und schreibe ein kleines Testprogramm, welches diesen "Mist" (z.B. Falsche Quittungszeichen, nicht quotierte DLE, falsche Prüfsummen) produziert und über die serielle Leitung mit deiner SPS verbunden ist. 

Es ist sowieso besser diesen Nachweis mit einem Testprogramm zu erbringen, da Du so selbst nachweisen kannst, dass Du alle Fehlermöglichkeiten getestet hast.


----------



## Rainer Hönle (21 Dezember 2005)

Hansruedi schrieb:
			
		

> Mit Hyperterm wir es sehr schwierig, da 3964R mit einem Byte-Handshake (STX 0x02 hin, DLE 0x10 her) arbeitet und dies in max. 550 ms ablaufen muss.


Die Quittungsverzugszeit (QVZ) 550 ms gelten bei 3964, 3964R arbeit mit einer QVZ von 2000 ms.


----------



## Hansruedi (21 Dezember 2005)

Anonymous schrieb:
			
		

> ...Verwende doch einfach einen normalen Analyser zum Anzeigen der Daten und schreibe ein kleines Testprogramm...



Super, genau so einen *normalen Anlayser* suche ich...

Wo kann ich ihn finden?

Gruss Hansruedi


----------



## Rainer Hönle (21 Dezember 2005)

Hansruedi schrieb:
			
		

> Super, genau so einen *normalen Anlayser* suche ich...
> 
> Wo kann ich ihn finden?


http://www.hhdsoftware.com/sermon.html 

Einfach die Lite-Version verwenden.


----------



## Anonymous (21 Dezember 2005)

Rainer Hönle schrieb:
			
		

> Hansruedi schrieb:
> 
> 
> 
> ...



Es gibt eine ganze Reihe von 3964R-Implementierungen (nicht nur in Siemens-Steuerungen...auch Bosch usw.).  Bei einigen können die Quittungs- und Zeichenverzugszeiten auch parametriert werden. Daher würde ich mich nicht auf eine feste Zeit festlegen!


----------



## Hansruedi (21 Dezember 2005)

*Anmerkung zur QVZ:*
Diese sollte so eingestellt werden, dass die Programmverarbeitung und die Laufzeit zwischen den Kommunikationspartner berücksichtigt wird. Wenn z.B. die Kommunikation erst bei 5. Versuch zustande kommt (z.B. QVZ = 1s -> Kommunikation findet erst nach ca. 5 s statt.) und der Partner muss aber innerhalb von 1s reagieren.
Deshalb kann man nicht generell sagen 550ms ist gut oder 2000ms ist besser.

Die Analyzer-SW habe ich ausprobiert (Lite geht nicht, die Kommunikation wird nicht durch den PC geschalten).
Aber... die Möglichkeit zum Daten beeinflussen habe ich nicht gefunden.
Hab ich da was übersehen?

Wer hat so was schon gemacht? ohne gross Windowsprogramme zu generieren?

Gruss Hansruedi


----------



## Rainer Hönle (21 Dezember 2005)

Hansruedi schrieb:
			
		

> *Anmerkung zur QVZ:*
> Diese sollte so eingestellt werden, dass die Programmverarbeitung und die Laufzeit zwischen den Kommunikationspartner berücksichtigt wird. Wenn z.B. die Kommunikation erst bei 5. Versuch zustande kommt (z.B. QVZ = 1s -> Kommunikation findet erst nach ca. 5 s statt.) und der Partner muss aber innerhalb von 1s reagieren.
> Deshalb kann man nicht generell sagen 550ms ist gut oder 2000ms ist besser.


Es geht nicht um gut oder nicht gut. Sondern wenn man mit Siemens zu tun hat zählt das, was Siemens als Standard definiert hat  :wink: . Und das sind die 550 ms bei 3964 und 2000 ms bei 3964R. Die Wiederholzahl bleibt davon unbeinflußt, ebenso die Zeichen- und Reaktionsverzugszeit.



> Die Analyzer-SW habe ich ausprobiert (Lite geht nicht, die Kommunikation wird nicht durch den PC geschalten).


Der Analyser sollte auf dem PC laufen, auf dem die zu prüfende Applikation läuft. Ansonsten ist die normale Version mit Nullmodemkabeln und zwei Schnittstellen notwendig. Was bedeutet "...wird nicht durch den PC geschalten" :?: 

Weitere Produkte gibt es noch unter
http://www.eltima.com/products/serial-port-monitor/
http://www.adontec.com/smon_e.htm
Erfahrungen liegen hier keine vor.


----------



## Hansruedi (21 Dezember 2005)

> ...Lite geht nicht, die Kommunikation wird nicht durch den PC geschalten.



Damit meinte ich, dass der Protocol Analyzer nicht bei der Lite-Version verfügbar ist.

Wenn man Bits oder Bytes beeinflussen möchte muss man die Daten an der einen COM emfangen, verfälschen und an der zweite COM weitergeben.

Dieser Vorgang hatte ich als "durch den PC geschalten" bezeichnet.

Gruss Hansruedi


----------



## Question_mark (21 Dezember 2005)

Hallo,


			
				hansruedi schrieb:
			
		

> Nun muss ich den Nachweis erbringen, dass die Fehlerabhandlung im SPS-Programm gut ist bzw. sich nach den Vorgaben verhält.


Dafür gibt es Analyzer von vielen Herstellern, mit denen Du diesen Nachweis problemlos erbringen kannst. Einfach mal googeln.


			
				hansruedi schrieb:
			
		

> im übertragen Datenstrom gezielt manipulieren kann


Dazu brauchst Du einen Manipulator. Den gibt es zur Zeit auf dem Markt noch nicht, da es bis heute meines Wissens noch keine sinnvolle Anwendung dafür gibt. 
Aber Du hast ja jetzt gezeigt, dass Bedarf dafür vorhanden ist, ich denke bald gibt es die ersten Programme um Bytes auf der seriellen Schnittstelle manipulieren zu können. Die können dann beliebig aus einem "ACK" ein "DLE" machen  :lol: 
Was willst Du denn jetzt wirklich, oder kennst Du nur nicht den Unterschied zwischen analysieren und manipulieren und hast Dich da etwas unglücklich ausgedrückt ?
An einigen Antworten auf Deine Frage sehe ich, dass einige mit Deiner Fragestellung nicht zurechtkommen. Ich übrigens auch nicht.

Gruß 
Question_mark


----------

