Gast
#1838140
Hallo, gibt es eine möglichkeit um einen AVR wie Siemens mit Logiksymbolen zu Programmieren ohne das man eine Programmiersprache wie C, C++, Basic usw. können muss? mfg. GBZ-Oholiker
Schau mal microSPS an. http://www.microsps.com/ Was anderes in der Art ist mir nicht bekannt. Gruß Skriptkiddy
Gast
#1838149
Hey, das Programm hat einen code generator: http://www.hpinfotech.ro/index.html Vielleicht kommst Du damit weiter. All the best ...
GBZ-Oholiker schrieb: > gibt es eine möglichkeit um einen AVR wie Siemens mit Logiksymbolen zu > Programmieren ohne das man eine Programmiersprache wie C, C++, Basic > usw. können muss? Warscheinlich schon, wenn es einem nichts ausmacht, die Möglichkeiten eines MC nichtmal zu 5% ausnutzen zu können. Peter
Gast
#1838197
"westhues ladder logic" ?
Gast
#1838203
nimm nen cpld, da gibts prima Werkzeuge für die graphische Programmierung
moin, Flowcode für AVR raik
Gast
#1838260
hein blöd schrieb: > Hey, > > das Programm hat einen code generator: > > http://www.hpinfotech.ro/index.html > > Vielleicht kommst Du damit weiter. > > All the best Nee, das ist 'nur' ein Codewizard für die Initialisierungsroutinen der MCU-Peripherie. Deinen Anwendercode musste noch schön selber schreiben...
Gast
#1838263
Peter Dannegger schrieb: > Warscheinlich schon, wenn es einem nichts ausmacht, die Möglichkeiten > eines MC nichtmal zu 5% ausnutzen zu können. Magst Du das bitte näher begründen, Peter?
Gast
#1838272
@GBZ-Oholiker Wie Siemens S5 oder S7? Schau mal auf Muff-electronic.ch Dafür habe ich ein Hutschienenlayout gemacht. Optokoppler-In, ULN2003-Out, RS232-Programmierinterface, LCD und I2C-Anschluß. Gruß Helmut
Gast
#1838278
Beitrag "SPS Betriebssytem" http://www.muff-electronic.ch/ http://www.microsps.com/ Konverter von KOP und FUP in AWL wird's ja wohl geben.
Grrrr schrieb: > Peter Dannegger schrieb: >> Warscheinlich schon, wenn es einem nichts ausmacht, die Möglichkeiten >> eines MC nichtmal zu 5% ausnutzen zu können. > > Magst Du das bitte näher begründen, Peter? Ich bin zwar nich Peter, aber ich versuch's dennoch mal :) Schreibe mal
1 | |
2 | |
ähnlich effektiv in irgendeiner SPS-Sprache oder Flowcode. Anderes Beispiel mit Bitophorror:
1 | |
So etwas kann man IMHO nicht ohne weiteres Graphisch ähnlich effizient umsetzen.
Gast
#1838315
Ja, ich gebe dir Recht und wahrscheinlich meint Peter es auch. Nur der Eine oder Andere versteht die Sprache nicht und kann es visuell so einfacher umsetzten, sprich verstehen. Warum kann man dann nicht einfach nur 5 % ausnutzen, dabei aber 100% Nutzen haben? Auf die Speicher oder Ausnützung der Möglichkeiten kommt es nicht immer an. Ich würde da keine Unterschiede in der Bewertung der Ansprüche machen wollen, das Ergebniss zählt. Gruß Helmut
Wer seinen AVR als SPS-Atrappe als Steuerung für's Aquarium/Gewächshaus/Heizung/Wasauchimmer einsetzten will kann mit einer graphischen Programmierung durchaus gut bedient sein. Doch wenn es ein bisschen auf Geschwindigkeit ankommt, dann wird's problematisch.
Gast
#1838318
Jo, stimmt.
Gast
#1838319
> PORTB = (((blinksrc & (1<<S_FAST))>>S_FAST)<<PB2)|(PORTB & ~(1<<PB2));
blinksrc: BYTE;
blink AT blinksrc: ARRAY [0..7] OF BOOL;
A1.2 = blink[S_FAST] ??
Gast
#1838321
@ Luk4s K. Bei aller Wertschätzung Deines Beitrages hast Du eine Frage beantwortet, die so garnicht gestellt wurde. Genauer betrachtet hast Du nur eine neue Frage gestellt. Aber formuliere ich sie so um, das sie eine Antwort ist, dann lautet sie: Du kannst obige Ausdrücke nicht graphisch effizient umsetzen. Abgesehen davon, was denn "graphisch effizient" sein soll, kranken Deine Beispiele daran, das sie vernachlässigen, das die Bitschieberei hier letztlich nur der Bitauswahl dient, was man in SPS eigentlich durch Benennung macht; man hat es also garnicht nötig die Bitschieberei explizit hinzuschreiben. Sowohl der erste und der zweite Ausdruck würden dann schliesslich die Oder-Verknüpfung von 8 Bit parallel bzw. das kopieren/weiterleiten eines Bits sein.´Viele Werte darin sind ohnehin nur Konstanten. (1<<S_FAST), (1<<PB2), etc. Die Frage hat aber sowieso anders gelautet. Nämlich: Warum kann man die Möglichkeiten einer CPU mit so einer graphischen Beschreibungssprache nur zu 5% oder weniger nutzen?
MaWin schrieb: >> PORTB = (((blinksrc & (1<<S_FAST))>>S_FAST)<<PB2)|(PORTB & ~(1<<PB2)); > > blinksrc: BYTE; > blink AT blinksrc: ARRAY [0..7] OF BOOL; > > A1.2 = blink[S_FAST] ?? Wie meinen? Die Bitop hat die Aufgabe das Bit S_FAST aus blinksrc nach PB2 in PORTB zu kopieren. Grrrr schrieb: > Warum kann man die > Möglichkeiten einer CPU mit so einer graphischen Beschreibungssprache > nur zu 5% oder weniger nutzen? Ich habe dies so aufgefasst, dass eine graphische Beschreibungssprache weniger effizienten Assemblercode als ein C-Compiler; sicher lassen sich meine Beispiele auch mit SPSen realisieren, nur was macht der Compiler draus?
Gast
#1838330
Nein, keiner hat in diesem Fall Recht, sondern will Recht haben! die Frage war: gibt es eine Möglichkeit um einen AVR wie Siemens mit Logiksymbolen zu Programmieren ohne das man eine Programmiersprache wie C, C++, Basic usw. können muss? Diese simple Frage wird nicht beantwortet, sondern es nur Kommentare abgegeben!
Gast
#1838331
Und genau das tut diese (Siemens STEP 7) SCP Anweisung, man muß bei SPS nicht irgendwelche blödsinnige Bitfummelei machen, bloss um ein einzelnen Ausgangsleitung beeinflussen zu können, und man muß nicht irgendwelche undurchsichtigen Bitfummeleien machen, um auf eine simple gespeicherte BITfolge zugreifen zu können. Es ist so einfach: A1.2 = blink[index] Vergiss deine C-Programmierung obfuscation
Gast
#1838332
Helmut schrieb: > Diese simple Frage wird nicht beantwortet, sondern es nur Kommentare > abgegeben! Tja, das ist der Fluch der Foren...
Daran, dass das mit einer SPS nicht geht zweifele ich auch garnicht, ich zweifele nur daran, dass der Compiler daraus 14 Assemblerinstruktionen macht und damit das Programm ähnlich schnell wie ein in C geschriebenes abläuft.
Gast
#1838364
Also bei den meisten Steuerungen die ich bisher Programmieren musste war sowas völlig egal.
Grrrr schrieb: > Peter Dannegger schrieb: >> Warscheinlich schon, wenn es einem nichts ausmacht, die Möglichkeiten >> eines MC nichtmal zu 5% ausnutzen zu können. > > Magst Du das bitte näher begründen, Peter? Schaltplaneingabe ist eine parallele Darstellung. Ein MC kann aber nix parallel machen, sondern muß alles in Zeitscheiben einteilen und hintereinander machen. Und damit reduziert sich die Abarbeitungsgeschwindigkeit drastisch. Es ist etwas ähnlich zu einem RTOS, bloß hat ein RTOS noch viele Möglichkeiten, die Abarbeitung zu steuern (Prioritäten usw.). Eine weitere Sache ist, daß Peripherieeinheiten (Timer usw.) oft verschiedene Sachen kombinieren. Für ein Schaltplantool stelle ich mir das schwierig vor. D.h. ist im Schaltplan ein Timer z.B. mit PWM belegt, kann er nicht mehr als Input-Capture benutzt werden. In einem C-Programm geht das aber. Man kann also weder die CPU-Geschwindigkeit noch die Peripherie optimal ausnutzen. Daß sich viele Sachen (z.B. Protokolle) als Schaltplan nur sehr umständlich ausdrücken lassen, kommt noch hinzu. Peter
Hier hat mal jemand was für AWL gemacht. Axel
Gast
#1839150
Peter Dannegger schrieb: > Schaltplaneingabe Danke, Peter.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.