Das ist keine Frage zu irgendeinem Projekt oder so, nur rein aus intresse. Ich habe rein aus langeweile und zufall einen Artikel über FPGA Microcontroller gelesen. Dabei habe ich dann auch Bilder vom Code gesehen, z.b. sowas: http://sine.ni.com/cms/images/casestudies/image917368718485822167.png http://www.ni.com/cms/images/devzone/tut/Code_MatrixVector_20140810022410.png Das einzige was ich über FPGA gehört habe, das es scheinbar "unglaublich schwer" sein soll, und vielen geraten wird, die Finger davon zu lassen, da man lange zum erfolg braucht usw usw. Wenn ich das aber so von weitem anschau, vorallem den Code, sieht mir das irgendwie verwand aus mit Siemens S7 SPS-Codes: https://www.dmcinfo.com/Portals/0/Blog%20Pictures/Siemens%20Function%20Block%20Call.JPG Dort werden ja auch Funktionen in Blöcke gepackt und dann die Blöcke als "Schaltzeichen" benutzt. Kann mir jemand sagen, ob hier tatsächlich zwischen SPS S7 und FPGA einige Ähnlichkeiten bestehen? Falls ja, würde es mich dann doch mal reizen ein Evaluation Board zu kaufen, den ich finde S7 eigentlich super-simpel und habe auch einige Jahre beruflich S7 an Produktionszellen eingesetzt, und wenn fpga ähnlich wäre, hätt ich bestimmt keine grosse mühe mich darin einzuarbeiten.
:
Verschoben durch Moderator
@ Johnny SGT (sgt_johnny) >Kann mir jemand sagen, ob hier tatsächlich zwischen SPS S7 und FPGA >einige Ähnlichkeiten bestehen? Ja, die gibt es. Beide verarbeiten Logikschaltungen bzw. Statemachines. Der Unterschied ist aber, daß FPGAs um Faktor 1000++ schneller sind bzw. sein können, wenn man weiß was man tut. >Falls ja, würde es mich dann doch mal reizen ein Evaluation Board zu >kaufen, den ich finde S7 eigentlich super-simpel und habe auch einige >Jahre beruflich S7 an Produktionszellen eingesetzt, und wenn fpga >ähnlich wäre, hätt ich bestimmt keine grosse mühe mich darin >einzuarbeiten. Jain. Da aber FPGA-Boards heute recht preiswert zu haben sind, probiers einfach aus.
Johnny S. schrieb: > Das einzige was ich über FPGA gehört habe, das es scheinbar "unglaublich > schwer" sein soll, und vielen geraten wird, die Finger davon zu lassen, > da man lange zum erfolg braucht usw usw. Das sagen die, die mit ihrem C-Wissen FPGAs "programmieren" wollen. Das geht schief, die kommen so nie auf einen grünen Zweig. > Funktionen in Blöcke gepackt und dann die Blöcke als > "Schaltzeichen" benutzt. Mit einem Schaltplan, der wie VHDL ja auch eine "Hardwarebeschreibung" ist, wird das selbe gemacht: Funktionsblöcke und Hierarchien aufgebaut und verdrahtet. > ich finde S7 eigentlich super-simpel ... und wenn fpga ähnlich wäre Auch dieser Ansatz ist falsch, auch wenn du sowas wie "Zustandsautomat" (=Merkerkette) schon von der SPS her kennst. VHDL ist eine Hardware-BESCHREIBUNGS-Sprache. Du musst dir also erst mal ein Bild von deiner Hardware machen (im Kopf oder auf einem Blatt Papier). Anstatt daraus nun einen Schaltplan zu malen, beschreibst du dieses "Bild" mit den Syntaxelementen von VHDL. Und siehst dir im RTL-Schaltplan ab&zu mal an, ob der Synthesizer deine Beschreibung verstanden hast. Das ist wie früher, als man jemandem einen Weg beschreiben musste: "fahr gerade aus bis zum blauen Haus, dort rechts und dann die dritte hoch bis zur Tankstelle...". Wenn derjenige diese Beschreibung nicht verstanden hat, fand er auch nicht zum Ziel, das du beschrieben hattest. > ob hier tatsächlich zwischen SPS S7 und FPGA einige Ähnlichkeiten > bestehen? Im Beitrag "Mit Logiflash Programme für FPGA erstellen. Geht das?" wollte auch einer sowas machen... > Falls ja, würde es mich dann doch mal reizen ein Evaluation Board zu > kaufen, Mach doch. Das ist gar nicht so teuer, und wenns nichts wird, kannst du es ohne großen Wertverlust weiterverticken... Noch was zum Thema "Schaltplan und FPGA": Beitrag "kruder Fehler bei FPGA-Programmierung (ISE WEBpack-Schematic)"
:
Bearbeitet durch Moderator
Falk B. schrieb: > Beide verarbeiten Logikschaltungen und beide sind eckig. Das ist die größte Gemeinsamkeit. Eigentlich auch so ziemlich die Einzige. Im Ernst, heute sind die Spassvögl unterwegs. Einen Zusammenhang zwischen dem Code von S7 und FPGAs zu sehen. Einfach Spitze.
Johnny S. schrieb: > Das einzige was ich über FPGA gehört habe, das es scheinbar "unglaublich > schwer" sein soll, und vielen geraten wird, die Finger davon zu lassen, > da man lange zum erfolg braucht usw usw. Keine Ahnung, welche Literaturquellen Du da zur Rate gezogen hast. FPGA sind nicht "unglaublich schwer", sondern sie sind "anders". Man muss sich von der streng sequenziellen Denkweise der Softwareentwicklung lösen, weil im FPGA die Dinge gleichzeitig geschehen. Das ist für Anfänger das größte Problem. Zudem muss man ein gewisses Verständnis für digitale Schaltungen haben. Die Begriffe Register, kombinatorische Logik, State-machine, Zähler, Pipeline, Fan-out, Setup/Hold-Zeit etc müssen einem geläufig sein, und es ist nicht verkehrt, wenn man weiß, auf welche Weise man digital mit Zahlen rechnet (Stichwort Addiererstrukturen). Bei FPGA programmierst Du keinen Algorithmus, sondern eine Struktur, und Du musst Dich massiv um einen Faktor kümmern, der bei Software keine Rolle spielt: Zeit. Wenn man unbedingt will, kann man gewisse Ähnlichkeiten zwischen SPS und FPGA finden. Bei beiden beschreibt man das Verhalten als eine Logische Verknüpfung zwischen Eingängen und Ausgängen. Aber in einer SPS sitzt ein stinknormaler Microcontroller, der diese Verknüpfungen schnell genug sequenziell auswertet. Auf einem FPGA wird hingegen eine echte Schaltungsstruktur erzeugt, so als würdest Du das ganze mit Logikgattern nachbauen.
Johnny S. schrieb: > Kann mir jemand sagen, ob hier tatsächlich zwischen SPS S7 und FPGA > einige Ähnlichkeiten bestehen? Ja. Der Unterschied ist, dass für die graphisch spezifizierte Schaltung die Verzögerung vom Eingang zum Ausgang beim FPGA nur wenige Takte beträgt und dass das FPGA mit jedem Takt (oder mit jedem x-ten) eine neue Eingabe akzeptiert. Die SPS auf Basis von CPUs rechnet für eine gegebene Eingabe die graphische Schaltung von vorn bis hinten sequentiell durch und akzeptiert in dieser Zeit keine neuen Eingaben. > Falls ja, würde es mich dann doch mal reizen ein Evaluation Board zu > kaufen, den ich finde S7 eigentlich super-simpel und habe auch einige > Jahre beruflich S7 an Produktionszellen eingesetzt, und wenn fpga > ähnlich wäre, hätt ich bestimmt keine grosse mühe mich darin > einzuarbeiten. Bei NI/Labview? und co. kannst Du vereinfacht/prinzipiell eine Funktionalität graphisch spezifizieren und dann entscheiden, wie dies realisiert werden soll (CPU, DSP, FPGA). Auch abstrahierte textuelle Beschreibungen für Funktionsblöcke sind möglich. Auf dieser Ebene arbeitest Du Dich nicht in FPGA ein, sondern in ein Produkt, das FPGAs benutzt und das hoffentlich so funktioniert, wie Du es möchtest. Die CPU in der SPS verarbeitet auch nicht die graphischen Bildchen. Genauso, wie Du weißt, wie man diese CPU benutzt, weißt Du, wie man FPGAs benutzt. Dh, je nach Sichtweise gar nicht oder eben ausreichend. CPU und FPGA haben Unterschiede, die manchmal Vorteil und manchmal Nachteil sind. Einen Unterschied habe ich weiter oben aufgeführt. Andere haben bereits einige erwähnt. Letztlich ist es immer das Selbe: Kosten vs. Performanz in Abhängigkeit von den Anforderungen. Edit: Es ist schwieriger und aufwändiger, mit FPGAs zum Ziel zu kommen. Diesen Zusatz0Aufwand leistet Du oder das Tool oder Ihr beide; und zwar fehlerfrei, sonst funktioniert es nicht. Dh, man kann mehr Fehler machen und die Methode auf Basis von FPGAs ist noch nicht so lang in Nutzung wie diejenige auf Basis von CPUs. Ihr beide (Du und das Tool) dürft Euch nicht missverstehen, sonst funktioniert es auch nicht.
:
Bearbeitet durch User
Johnny S. schrieb: > Kann mir jemand sagen, ob hier tatsächlich zwischen SPS S7 und FPGA > einige Ähnlichkeiten bestehen? Ja, beide funktionieren mit Strom... Vancouver schrieb: > Wenn man unbedingt will, kann man gewisse Ähnlichkeiten zwischen SPS und > FPGA finden. Bei beiden beschreibt man das Verhalten als eine Logische > Verknüpfung zwischen Eingängen und Ausgängen. Bei einer SPS wird gar nichts beschrieben. Bei einer SPS wird ein ganz normales Programm geschrieben. Ob Du in C schreibst:
1 | ventil = taster && !leckage; |
Oder ob Du in ST (SPS) schreibst:
1 | ventil := taster AND NOT leckage; |
Oder ob Du das in AWL zusammenhackst oder das mit lustigen Bildchen malst, macht keinen Unterschied. Der springenden Punkt ist, das ist alles nur ein sequentielles Programm. Auch wenn TIA oder andere SPS-Programmierumgebungen Dir mit den Kästchen suggerieren, da würden irgendwelche Signale geroutet oder eine (Hardware-)Struktur beschrieben; am Ende ist das alles nur ein ganz stinknormales, sequentielles Programm, das oben anfängt und unten aufhört. Beim einem FPGA werden dagegen tatsächlich Strukturen beschrieben und Signale geroutet. Da passiert überhaupt nichts sequentiell, sondern alles parallel. Das witzige daran ist eigentlich, dass beim FPGA die Entwicklungsleistung (zu einem gewissen Teil) darauf verwendet wird, mit den nicht-sequentiellen Hardware-Resourcen ein gewisses sequentielles Verhalten zu erreichen, und bei der SPS-Programmierung ein großer Teil der Entwicklungsleistung darauf verwendet wird, mit einem sequentiellen Programm, ein gewisses paralleles Verhalten zu erreichen. Historisch war der Fokus (und bei einigen Herstellern ist er noch immer) bei SPS auf eine Verwendbarkeit durch "Laien". D,h, ein Elektriker oder E-Konstrukteur der ein paar Schütze zusammenschalten konnte, soll das mit einer SPS machen können. Daher kommen die lustigen Bildchen in der SPS-Welt. Das ist aber definitiv am aussterben, da heutige Maschinen und Anlagen immer mehr aus "echter" Software bestehen die von Softwerkern erstellt wird, da immer mehr Daten verwaltet und mit externen Systemen kommuniziert wird, immer mehr Mechanik durch Software ersetzt wird, und das Know-How immer mehr in Prozessen und Algorithmen liegt anstatt in der Konstruktion.
Ich stimme zwar größtenteils den Ausführungen der Vorredner zu. Allerdings sind einige Formulierungen doch etwas zu weitreichend. Es gibt keinen Gegensatz zwischen FPGAs und SPS. Es sind auch FPGA-basierte SPS auf dem Markt erhältlich, ebenso auch FPGA-Zusatzmodule mit den in der industriellen Automatisierung üblichen Bauformen und Signalstandards. Das, was man bei SPS nicht aus den Augen lassen sollte, ist die Entstörung der Eingangssignale. Jede bessere SPS unterdrückt Glitches, entprellt Eingänge usw.; vielfach lassen sich die entsprechenden Totzeiten und/oder Filterbandbreiten in der SPS auch konfigurieren. Schließt man hingegen ein Eingangssignal ganz unbedacht über einfache Pegelwandler direkt an ein FPGA an, dürfte man hier sein blaues Wunder erleben. Allerdings kann man in einer Hardwarebeschreibung auch ganz wunderbar exakt auf den konkreten Anwendungsfall zugeschnittene Blöcke zum Einsynchronisieren und Filtern der Eingänge implementieren, sogar viel passgenauer als bei Standard-SPS. Die o.a. FPGA-Zusatzmodule sind z.B. auch für Siemens S7 erhältlich und bieten sich insbesondere dann an, wenn man sehr schnelle kombinatorische Logik benötigt, z.B. zum präzisen Stopppen von Antrieben durch Positionsmarken. Eine wissenschaftlich angehauchte, natürlich auch unter dem Gesichtspunkt der Werbung zu betrachtende, Publikation zu den FPGA-basierten SPS von Zander findet man hier: https://www.zander-aachen.de/files/Zander/Fachartikel/zx20_fachbeitrag.pdf Dort werden die Unterschiede zwischen klassischer SPS und FPGA-basierter durchaus brauchbar herausgearbeitet. Der letzte Schritt, nämlich dass sich eine normale Beschreibung in ST (ähnlich SCL bzw. Pascal) schmerzfrei in VHDL übersetzen ließe, dürfte jedoch nicht ganz so einfach sein. Es gibt ja auch schon viele andere Ansätze, normale "Software-Hochsprachen-Quelltexte" blind in Hardwarebeschreibungssprachen umzusetzen, was natürlich entweder auf Grund der inhärenten Nebenläufigkeit der generierten Hardwarebeschreibung zu Problemen führt oder letztendlich auf die Synthetisierung eines sequentiell arbeitenden Softcore hinausläuft. Man könnte zwar meinen, es ließe sich ohne Modifikationen eine Nebenläufigkeit z.B. auf OB-Ebene realisieren. Dabei muss man aber schon ganz genau hinschauen, wie verschiedene Ablaufstränge dann z.B. über Datenbausteine bzw. globale Variable miteinander kommunizieren. Und nein: globale Variable sind bei SPS nicht abgrundtief böse, wenn sie z.B. in Form von Bitfeldern oder Zustandswerten zur Kommunikation zwischen Zustandsautomaten verwendet werden. Ein wesentlicher Punkt, der die Umstellung klassischer SPS-Programme auf Hardwarebeschreibungen deutlich erleichtern kann, besteht darin, dass "ordentliche" SPS-Programme meist sehr flache Aufrufpfade von Funktionen und Funktionsblöcken haben, ganz im Gegensatz zu "üblichen" Microcontrollerprogrammen oder gar fetten graphischen (PC-)Programmen.
Zur FPGA-"Programmierung" gehört mehr als das Programm. Neben den Programmcode musst du -Timing und sonstige constraints vergeben (ucf xcf files editieren) -Zuordnung Signal/pin definieren (files wie oben) -progrmmierfile erzeugen (bitgen Optionen) -simulieren (testbench schreiben, tcl Syntax, etc) -debuggen (Logicanalyzer und sonstige debugtools) wie man das macht ist bspw im constraint guide beschrieben, der hat mehrere hundert Seiten. Das kanns du nicht mit Labview machen wie in deinen screenshots gezeugt. Labview setzt auf die FPGA-Hersteller -IDE auf, ersetzt sie aber nicht. und das erlernen der FPGA-Tools und FPGA-interna ist IMHO das Hauptproblem. die "VHDL-Programmierung" die man auch mehr schlecht als recht mi8t Blockdiagrammen machen kann ist Pillepalle dagegen. Weltbester FPGA-Pongo schrieb im Beitrag #4661596: > Im Ernst, heute sind die Spassvögl unterwegs. > Einen Zusammenhang zwischen dem Code von S7 und FPGAs zu sehen. Volle Zustimmung. Demnächst kommt noch einer: "Wozu Pilotenschule, wenn es doch den MS Flugsimulator gibt." Aber bei aller Häme, Fragen ist erlaubt.
S7 (oder ganz normkonform und allgemein AWL) ist im Prinzip nur ein verranzter Assembler: Sequentielle Anweisungen, Schritt für Schritt abgearbeitet. Das wird auch mit FUP/KOP nicht besser, denn auch daraus wird nur eine Anweisungsliste, die in der SPS dann Schritt für Schritt abgehakt wird. Lediglich durch die Arbeitszyklen sieht es von außen dann so aus, als ob es sich um eine logische Schaltung handelt. Man muss halt langsam genug hingucken, damit man diesen Eindruck gewinnt, weil dann die Zykluszeit nicht mehr auffällt. Ein FPGA ist eher mit Klapperschaltung zu vergleichen, also mit Schützen. Außer Signallaufzeiten und mechanischen Verzögerungen (Kontakte bewegen sich nunmal) gibts keine Zyklen o.ä. Im FPGA ist das genauso, im Prinzip gibts nur Signallaufzeiten. Man kann (muss aber nicht) damit dann natürlich wieder Schritt-Schaltungen aufbauen, die ihrerseits wieder irgendwelche Zyklen abarbeiten. Zum Beispiel könnte man eine Schritt-Schaltung aufbauen, die eine Anweisungsliste Schritt für Schritt abhakt...
Andreas S. schrieb: > Ein wesentlicher Punkt, der die Umstellung klassischer SPS-Programme auf > Hardwarebeschreibungen deutlich erleichtern kann, besteht darin, dass > "ordentliche" SPS-Programme meist sehr flache Aufrufpfade von Funktionen > und Funktionsblöcken haben Aus meinem Blickwinkel könnte ich auch sagen: "ordentliche" SPS-Programme sind oft unmodularer (und noch öfter leider unwartbarer) Spaghetticode, weil man mit dem festgefahrenen 60er-Jahre-Müll an OB/FB einfach nicht sauber und modular programmieren kann... SCNR
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.