SIemens S7 1500 2 ns Bitbearbeitungszeit

Dirk F schrieb:
> Die müsste ja mindestens mit 1 GHz getaktet sein, oder ?
Kein Problem. Nimm einfach einen ARM-Prozessor für 10€.
Dort gibts solche CPU-Boards ab 39,95: https://www.toradex.com/products

Also noch viel Luft nach oben bis zur 10k€-SPS.

Dirk F schrieb:
> Aber ich sehe bei der Siemens S7-1500 eine Bitbearbeitungszeit von 2 ns.

Das steht dort nicht.

"2ns bit performance", könnte man als 2ns Bitleistung übersetzen.

> Was ist denn da für eine MCU drin ?
> Die müsste ja mindestens mit 1 GHz getaktet sein, oder ?

Nö. Das ist so oder so nichtssagendes Marketinggeschätz. Auch die 
schnellste SPS hat mit Zeiten im 2ns Bereich nix zu tun. Damit meine ich 
den Hauptprozessor, nicht irgendwelche exotischen Interface- oder 
Spezialmodule. Ein 1G Ethernetport mit optischer Schnittstelle muss 1,25 
Gbit/s brutto verarbeiten. Klingt viel, ist es aber nicht wirklich 
heutzutage, zumal diese Geschwindigkeit nur von einem kleinen Stück 
Hardware beherrscht werden muss. In Richtung CPU geht es dann meist mit 
32 Bit Parallelbus, ggf. sogar DMA, das sind dann nur noch 125MB/s 
bzw. 31,25 MTransfers/s bei 32 Bit Busbreite. Das reißt heute keinen 
mehr vom Hocker.

Um einen Schalter in 2nS überhaupt nur zu sehen, darf die Zuleitung zum 
Eingang nicht länger als 30cm sein. Die SPS könnte damit Signale bis 500 
Mhz abtasten. Also Druckfehler oder typisches Marketinggeschwätz von 
Siemens. Lichtgeschwindigkeit ist 299792458 m/sec.

Dirk F schrieb:
> Was ist denn da für eine MCU drin ?

Das sind proprietäre ASICs. Die für normale Entwickler zugängliche 
Programmiersprache AWL und das zugehörige Registermodell stellen somit 
eine Teilmenge des Funktionsumfanges der CPU dar.

> Die müsste ja mindestens mit 1 GHz getaktet sein, oder ?

Vermutlich. Es gibt ja auch etliche ARM-basierten Prozessoren mit 
Taktfrequenzen in diesem Bereich.

Um auf eine "Bitbearbeitungszeit" (=Ausführungsdauer einfacher Befehle 
mit reinen Registerzugriffen) von 2 ns zu kommen, wird sicherlich wie 
bei jedem anderen Prozessor der letzten dreißig Jahre auf Pipelining 
usw. zugegriffen.

Lothar M. schrieb:
> Kein Problem. Nimm einfach einen ARM-Prozessor für 10€.

Das sind aber Anwendungsprozessoren. Die können nicht konsistent mit 500 
MHz Pins samplen. Allein schon der Zugriff auf die IO-Register dauert 
Dutzende bis Hunderte Takte. Mit DMA kann man vielleicht so schnell 
samplen, aber nicht verarbeiten/reagieren. 2ns werden also höchstens bei 
internen Verarbeitungen erreicht, und das auch nicht garantiert immer. 
Man müsste also eher bei Cortex-R schauen, und da ist die Auswahl schon 
knapper (und teurer!).

Niklas G. schrieb:
> Das sind aber Anwendungsprozessoren. Die können nicht konsistent mit 500
> MHz Pins samplen. Allein schon der Zugriff auf die IO-Register dauert
> Dutzende bis Hunderte Takte. Mit DMA kann man vielleicht so schnell
> samplen, aber nicht verarbeiten/reagieren.

Hast Du Dich überhaupt schon einmal mit der Funktionsweise "richtiger" 
SPS befasst? Das (oder die) Prozessabbild(er) wird/werden nur zu festen 
Zeiten aktualisiert, d.h. die Zustände aller IO-Module in das RAM 
geklimpert bzw. ausgegeben. Und anschließend erfolgen die Zugriffe nur 
auf diesem Abbild. Ich gehe ganz schwer davon aus, dass bei den ASICs in 
den Siemens-SPS das Aktualisieren des Prozessabbildes für lokale 
Module(!) nahezu komplett in Hardware realisiert sein wird.

> 2ns werden also höchstens bei
> internen Verarbeitungen erreicht, und das auch nicht garantiert immer.

Genau. Die Angabe bezieht sich wohl auf reine Registeroperationen 
("Bitbefehle"). Im Gegensatz zu normalen Anwendungungsprozessoren muss 
aber nicht bei jeder Bitverarbeitung umfangreich maskiert werden.

> Man müsste also eher bei Cortex-R schauen, und da ist die Auswahl schon
> knapper (und teurer!).

Auch Cortex-R-Prozessoren sind nicht auf Einzelbitverarbeitung 
optimiert.

Niklas G. schrieb:
> Das sind aber Anwendungsprozessoren. Die können nicht konsistent mit 500
> MHz Pins samplen
Es geht auch nicht um einen Eingang, sondern um ein Bit. Das ist eine 
logische Informationseinheit (löse mal ein paar Kreuzworträtsel, da wird 
das ab&zu gefragt) im Prozessor. Der Prozessor braucht für die 
Verarbeitung eines Bits überhaupt keine EA. Und deshalb ist es auch 
völlig irrelevant, wie schnell die Eingänge eingelesen werden können.

Andreas S. schrieb:
> Hast Du Dich überhaupt schon einmal mit der Funktionsweise "richtiger"
> SPS befasst?

Nö, das kommt in meiner Profession (Informatik) absolut nicht vor.

Andreas S. schrieb:
> Ich gehe ganz schwer davon aus, dass bei den ASICs in den Siemens-SPS
> das Aktualisieren des Prozessabbildes für lokale Module(!) nahezu
> komplett in Hardware realisiert sein wird.

Aha, aber bei den gezeigten Cortex-A wohl nicht.

Andreas S. schrieb:
> Die Angabe bezieht sich wohl auf reine Registeroperationen
> ("Bitbefehle").

Wenn das so ist, macht es Sinn. Das kann ein Cortex-A im Durchschnitt 
(!) auch, aber eben nicht garantiert.

Andreas S. schrieb:
> Auch Cortex-R-Prozessoren sind nicht auf Einzelbitverarbeitung optimiert

Aber darauf, Befehle mit vorhersehbarer Latenz auszuführen.

Lothar M. schrieb:
> löse mal ein paar Kreuzworträtsel

Wenn ich in Rente bin.

Lothar M. schrieb:
> Und deshalb ist es auch völlig irrelevant, wie schnell die Eingänge
> eingelesen werden können.

Die Informationen müssen ja schon irgendwo her kommen, oder soll die 
Maschine lediglich simuliert werden?

Niklas G. schrieb:
> Die Informationen müssen ja schon irgendwo her kommen
Wer sagt das? Für so eine 
Marketingangabe/Werbeaussage/Idealzustand/Traumwert/usw. reicht es aus, 
anzunehmen, die Daten wären schon vorhanden.

> oder soll die Maschine lediglich simuliert werden?
Wenn dadurch eine Bitverarbeitungszeit von 2ns erreicht wird, dann darf 
man auch das annehmen.

> Lothar M. schrieb:
>> löse mal ein paar Kreuzworträtsel
> Wenn ich in Rente bin.
Immerhin ein Lichtschimmer am Ende des Tunnels.

Niklas G. schrieb:
> Aha, aber bei den gezeigten Cortex-A wohl nicht.

Es geht hier aber ganz konkret um die in Siemens S7-1500 enthaltenen 
Prozessoren/ASICs.

Andreas S. schrieb:
> Niklas G. schrieb:
>
>> Aha, aber bei den gezeigten Cortex-A wohl nicht.
>
> Es geht hier aber ganz konkret um die in Siemens S7-1500 enthaltenen
> Prozessoren/ASICs.

Ich habe aber ganz konkret auf Lothars Anmerkungen geantwortet, dass das 
so mit dem Cortex-A ginge.

Andreas S. schrieb:
> Dirk F schrieb:
>> Was ist denn da für eine MCU drin ?
>
> Das sind proprietäre ASICs. Die für normale Entwickler zugängliche
> Programmiersprache AWL und das zugehörige Registermodell stellen somit
> eine Teilmenge des Funktionsumfanges der CPU dar.

Jain. AWL wird normalerweise auf der CPU interpretiert ( war schon immer 
so ) Inzwischen verwendet Siemens aber auch Compiler die AWL, KOP, FUP, 
ST (sowas wie Pascal) und neuerdings manchmal sogar C direkt in den 
passenden Maschinencode für die SPS übersetzen. Die 2ns beziehen sich 
auf compilierten Code.

>> Die müsste ja mindestens mit 1 GHz getaktet sein, oder ?

Ja sind sie auch. Der Inhalt des Gehäuses besteht zu 70% aus Kühlkörper, 
zusätzlich fungiert die Montageschiene als Wärmeableiter.

> Vermutlich. Es gibt ja auch etliche ARM-basierten Prozessoren mit
> Taktfrequenzen in diesem Bereich.

Bei der ist aber kein ARM drinnen :-) Siemens verwendet alle möglichen 
Architekturen in Ihren PLCs. Gerade in den kleineren auch gerne aus dem 
Automotive Bereich.

Niklas G. schrieb:
> Ich habe aber ganz konkret auf Lothars Anmerkungen geantwortet, dass das
> so mit dem Cortex-A ginge.
Ich habe nirgends behauptet, dass da drin ein Cortex A werkelt. Ich habe 
lediglich behauptet, dass schon eine 10€ CPU im GHz-Bereich solche 
logischen Elementarfunktionen im ns-Bereich abhandeln kann. Und dann auf 
die Deduktionsfähigkeit vertraut, dass eine tausendmal teurere Steuerung 
das sicher noch besser und schneller hinbekommt.

Hat offenbar nicht bei jedem geklappt. Pech.


Also nochmal die kurze Variante:
Dirk F schrieb:
> ich sehe bei der Siemens S7-1500 eine Bitbearbeitungszeit von 2 ns.
Ja, der aktuelle Stand der Technik gibt das her.

Andreas M. schrieb:
> Bei der ist aber kein ARM drinnen :-)

Genau das hatte ich ja auch geschrieben. Da aber ein typischer 
SPS-Prozessor ganz grob ähnliche Anforderungen wie ein aktueller ARM 
hat, dürften hierfür ähnliche Halbleiterprozesse eingesetzt werden. 
Somit lassen sich dann auch ähnliche Taktfrequenzen erreichen.

Lothar M. schrieb:
> Hat offenbar nicht bei jedem geklappt. Pech

Das hab ich alles schon genau so verstanden. Ich weiß überhaupt nicht, 
wie man darauf kommt, dass ich behauptet hätte, SPS würden Cortex-A 
nutzen oder was eine SPS kann oder nicht kann.

Ich wollte lediglich klar stellen, dass der Cortex-A (der sich NICHT in 
einer SPS befindet!!!) externe Pinsignale eben nicht mit 2ns Latenz 
bearbeiten kann, man also eben nicht mit einem Cortex-A so eine 
Verarbeitungszeit erreichen kann. Also nur der Cortex-A auf einem 
gängigen Board. Nicht in einer nichtexistenten SPS. Wenn der Cortex-A 
das nicht kann, folgt daraus nicht, dass die SPS das kann.

Ob die SPS das tatsächlich doch kann oder die 2ns nur intern sind, weiß 
ich nicht.

Der Preis ist übrigens ziemlich losgelöst von der Leistung. So ein 
ARM-Anwendungsprozessor ist um viele Größenordnungen komplexer und 
leistungsfähiger als ein ähnlich teurer Mikrocontroller, das kommt also 
nur von der Massenfertigung.

Nur weil ein massengefertigter 10€-Prozessor etwas kann heißt das nicht, 
dass ein für SPS gebauter Spezialprozessor das auch für 10€ kann.

Andreas S. schrieb:
> Da aber ein typischer
> SPS-Prozessor ganz grob ähnliche Anforderungen

Heute wird in SPSen eigentlich nur noch Stangenware eingesetzt. Das 
höchste der Gefühle ist es einen Standard CPU Chiplet zu nehmen und den 
eventuell noch mit einem extra Chiplet für die Kommunikation im selben 
Package zu kombinieren. Meist ist aber der Kommunikationsprozessor 
extern per PCIe angebunden.

Die ganz alten Simotion Controller D435 (Die es jetzt nicht mehr gibt, 
also nicht die D435-2) hatten z.B. ne Pentium III CPU + eine Siemens 
Profinet Baugruppe. Der Pentium wurden mit einem speziellen RT Linux 
betrieben, da konnte/musste man sogar Bios-Updates einspielen :-)

Niklas G. schrieb:
> Ob die SPS das tatsächlich doch kann oder die 2ns nur intern sind, weiß
> ich nicht.

Wie schon mehrfach in dem Thread beschrieben geht es hier rein um die 
Zeit die die SPS benötigt um zwei im RAM liegende Variablen miteinander 
Bit zu verküpfen. Und genau das beschreibt die Siemens Angabe.

IOs sind bei solchen SPS fast immer remote, also über Netzwerk 
angeschlossen, Aktualisierungszeit typischerweise 1-2ms.

Dirk F schrieb:
> Was ist denn da für eine MCU drin ?
> Die müsste ja mindestens mit 1 GHz getaktet sein, oder ?

Ich lese das als 500MHz (=1/2ns).

Zum Vergleich: Ein Teensy 4.0 oder 4.1 hat einen 600 MHz µC drauf.

Jim M. schrieb:
> Ich lese das als 500MHz (=1/2ns).
Das 1GHz bzw. die 600MHz sind auch nur die Taktfrequenz zur 
schnellstmöglichen Ausführung eines NOPs.

Lothar M. schrieb:
> Das 1GHz bzw. die 600MHz sind auch nur die Taktfrequenz zur
> schnellstmöglichen Ausführung eines NOPs.

Das ist die Kernkompetenz einer SPS, besonders von Siemens! ;-)

Die Aussage ist, wie schon mehrfach festgestellt, wertloses 
Marketinggeschwätz. Ob eine SPS damit schnell ist oder nicht, 
entscheiden viele andere Komponenten, sei es das Betriebssystem, der 
Compiler und last but not least das Anwenderprogramm! Auch moderne PCs 
kann man MÜHELOS mit Müll in die Knie zwingen, das ist kinderleicht. 
Alles nix Neues.

MCUA schrieb:
> später dann TriCore (was definitiv gelogen ist, denn es sind keine 3
> Kerne))

Aktuelle TriCore haben bis zu 6 Kerne, und das sind echte 
Prozessorkerne, jeweils mit eigenen Speicherblöcken (SRAM+Flash) und 
Caches ausgestattet. Unter "ferner liefen" kommt noch ein 
8051-LowPower-Prozessor dazu. Die Flash-Zugriffe erfolgen über 6 weitere 
Spezial-Prozessorkerne, welche man zum Flashen (z.B. Bootloader) mit 
Befehlen füttern muss.

Das sind richtig komplexe Schlachtschiffe, so ein popeliger STM32H7 o.ä. 
ist nichts dagegen. Die Komplexität dürfte sogar einen Cortex-A8 
übertreffen, so ein TI AM335x ist einfacher Bare Metal zu programmieren. 
Auch die Toolchains sind nicht ohne, da wünscht man sich die wunderschön 
einfach elegante STM32CubeIDE zurück.

MCUA schrieb im Beitrag

MCUA schrieb:
> (später dann TriCore (

Wo hast du die Info her?
Nie einen Tricore in einer 300 oder 400er gesehen.

MCUA schrieb:
> Die Zykluszeit ist (wie schon genannt) auch grottenschlecht, Bereich ms
> nicht ns.

Du hast Null Ahnung laberst aber einen Haufen Blödsinn. Die Trägheit 
einer Ventilinsel oder eines Temperatursensors ist Faktor 100 größer als 
1ms Zykluszeit. Warum also den Bus (das Netzwerk) sinnlos mit Daten 
auslasten. Da packt man lieber 256 Remote I/Os bei 4ms oder ähnlich 
dran. (Das sind dann schon 50% bei 100 MBit/s) Die 400er CPUs können 
sogar noch mehr. Schließlich soll über die selbe Leitung ja auch noch IP 
Telefone am Ende der Halle und die Arbeiter PCs gehen.

Eine 1517/1518 schafft deterministisch 250µs Zykluszeit in der 
Applikation mit einer Abweichnung von max 1µs (eher besser) über die 
gesamte Anlagenausdehnung, das können viele 100m Kabel sein.

Dieter schrieb:
> http://s7detali.narod.ru/S7_317/S7_317.html
>
> Ist das eine 300er oder eine andere Geräteklasse?

Ja, das ist eine (alte) 300er. Die hat noch nicht mal nen Ertec drinnen. 
(Hat nur einen Port) Die 300er sind aber schon länger am Auslaufen. 
Wobei sich die Modelle einer Baureihe massiv unterscheiden können. Die 
letzten zwei Ziffern sind ein Indikator für die Performance.

Dieter schrieb:
> 2ns pro bit sind 65MHz fuer 1 byte. Nichts weltbewegendes. Das Oszi mit
> 1GS hat demnach 0,125ns oder 125ps pro bit.

So betrachtet könnt ein Marketeer die CPU meines Laptops mit 100 
Femtosekunden pro Bit anbieten. ;-)

(prx) A. K. schrieb:
> So betrachtet könnt ein Marketeer die CPU meines Laptops mit 100
> Femtosekunden pro Bit anbieten. ;-)

Hat das was mit Feminismus und #metoo zu tun?

Für dich: 0,1 ps. Jetzt komm aber nicht mit Autos. ;-)

MCUA schrieb:
> ...und wer verkauft das?
> TriCore ist raus gekommen 1997, 1 Kern, RISC-CPU mit DSP-Befehlen,
> Periferie, sollte ca 80MHz.
> Holz-Elektronik hat damit geprahlt wie sonst was.
> Spätestens 1999 wird das den Markt völlig umkrempeln, sagten die.
> Geliefert haben Sie: Nichts.
> Für GeneralPurpose ist TriCore eher nicht existent.

Der allererste TriCore den es gab, war tatsächlich mal für 
Industriezwecke angedacht und hatte sogar eine MMU und es gab ein 
portiertes Linux dafür.
Inzwischen automotive only und eher als größere uC Architektur 
angedacht.