AVR wie Siemens Programmieren geht das?

[GBZ-Oholiker (Gast)]

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

[Oliver J. (skriptkiddy)]

Schau mal microSPS an.
http://www.microsps.com/
Was anderes in der Art ist mir nicht bekannt.

Gruß
Skriptkiddy

[hein blöd (Gast)]

Hey,

das Programm hat einen code generator:

http://www.hpinfotech.ro/index.html

Vielleicht kommst Du damit weiter.

All the best

...

[Peter D. (peda)]

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

[Grain (Gast)]

"westhues ladder logic" ?

[weinbauer (Gast)]

nimm nen cpld, da gibts prima Werkzeuge für die graphische 
Programmierung

[Raik C. (raik_c)]

moin,

Flowcode für AVR

raik

[Landstreicher (Gast)]

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...

[Grrrr (Gast)]

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?

[Helmut (Gast)]

@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

[MaWin (Gast)]

Beitrag "SPS Betriebssytem"
http://www.muff-electronic.ch/
http://www.microsps.com/

Konverter von KOP und FUP in AWL wird's ja wohl geben.

[Lukas K. (carrotindustries)]

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

lcdptr = &LCDM1;
*(lcdptr+(unsigned char)((seg>>8) & 0xff)) |= (unsigned char)(seg&0xff);

ähnlich effektiv in irgendeiner SPS-Sprache oder Flowcode.
Anderes Beispiel mit Bitophorror:

PORTB = (((blinksrc & (1<<S_FAST))>>S_FAST)<<PB2)|(PORTB & ~(1<<PB2));

So etwas kann man IMHO nicht ohne weiteres Graphisch ähnlich effizient 
umsetzen.

[Helmut (Gast)]

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

[Lukas K. (carrotindustries)]

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.

[Helmut (Gast)]

Jo, stimmt.

[MaWin (Gast)]

> 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]   ??

[Grrrr (Gast)]

@ 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?

[Lukas K. (carrotindustries)]

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?

[Helmut (Gast)]

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!

[MaWin (Gast)]

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

[Tim T. (tim_taylor)]

Helmut schrieb:

> Diese simple Frage wird nicht beantwortet, sondern es nur Kommentare
> abgegeben!

Tja, das ist der Fluch der Foren...

[Lukas K. (carrotindustries)]

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.

[Icke (Gast)]

Also bei den meisten Steuerungen die ich bisher Programmieren musste war 
sowas völlig egal.

[Peter D. (peda)]

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

[Axel D. (axel_jeromin)]

Hier hat mal jemand was für AWL gemacht.


Axel

[Grrrr (Gast)]

Peter Dannegger schrieb:
> Schaltplaneingabe

Danke, Peter.