Forum: Mikrocontroller und Digitale Elektronik Schrittkette

Markus O. schrieb:
> Act2;
Statement has no Effect

Ohne das jetzt im Detail verstanden zu haben, es geht doch nur darum 2 
"Aktoren" hin und her zu fahren, oder ???
Könnte wetten, das ganze ist mit maximal 6 Relais realisierbar. Wie kann 
man darum nur so ein verworrenes utopisches Geschwurbel veranstalten... 
:-)
TO ist hoffnungslos überqualifiziert...:-))

Markus O. schrieb:
> Wenn der Aktor1 (hier "Act1") nicht false ist, soll dieser schalten und
> erst wenn dieser wieder auf low ist, soll dieser auf false schalten und
> die Variable für Step 2 auf true gesetzt werden.
> Zwischen Step 1 und Step zwei soll noch ein Timer ablaufen.
> Der Timer soll starten wenn Aktor1 wieder auf low ist.

Kann man das nicht auch alles in normaler Umgangssprache formulieren?

Markus O. schrieb:
> Wenn der Aktor1 (hier "Act1") nicht false ist,

Wenn der Motor1 nicht aus ist

> soll dieser schalten

häää???

> und erst wenn dieser wieder auf low ist,

wenn dieser wieder aus ist?

> soll dieser auf false schalten

soll dieser abschalten

> und die Variable für Step 2 auf true gesetzt werden.

Hilfsrelais 1 anziehen

> Zwischen Step 1 und Step zwei soll noch ein Timer ablaufen.

korrigiere: das anzugsverzögerte Hilfsrelais 1 anziehen

> Der Timer soll starten wenn Aktor1 wieder auf low ist.

Jetzt hör aber auf..!:-)

Codeduplikate sind böse, weil sie schwerer zu warten sind und den 
Speicherbedarf erhöhen.

Durchnummerierte Variablen sind böse, denn sie führen u.A. oft zu 
Codeduplikaten, wie man auch hier sieht.

Lokale statische Variablen sind böse, da die Funktion jedes mal ein 
anderes Verhalten zeigt, zeigen kann. Das macht sie schlecht wieder 
verwendbar und schwerer zu debuggen. Führt u.A. zu Codeduplikaten.

Verschiedenartige Daten, welche zusammengehören stopft man in eine 
Struktur, oder bei dir/C++ in Klassen.

Gleichartige Daten(auch Strukturen) stopft man in Arrays.

Merksatz:
Jeder ist seines Glückes Schmied.

Markus O. schrieb:
> das Zeichnerisch
> darzustellen.

Man malt einen Pfeil von links nach rechts.
Einen Zeitpfeil.
Auf dem setzt man dann benannte Markierungen.

Bei zyklischen Prozessen, darf man auch einen Keis (mit Richtungspfeil) 
malen.

EAF schrieb:

> Codeduplikate sind böse, [...]
>
> Durchnummerierte Variablen sind böse, [...]
>
> Lokale statische Variablen sind böse, [...]

Missionieren ist böse.


Wenn Du nicht Moses bist, halte Dich mit dem Verkünden
von Geboten zurück.

Egon D. schrieb:
> Wenn Du nicht Moses bist, halte Dich mit dem Verkünden
> von Geboten zurück.
Du hast doch einen Schlag an der Kanne!

Wie soll denn eine "Anfänger" je sauber programmieren lernen, wenn ihm 
nie gesagt wird, was falsch und richtig ist.
Und wo die Probleme stecken.

Was ihm dann daraus macht:
> Jeder ist seines Glückes Schmied.

Egon D. schrieb:
> Missionieren ist böse.
Tipp: Halte dich an deine eigene Ansagen, dann wirkst du evtl. etwas 
glaubwürdiger.

EAF schrieb:

> Wie soll denn eine "Anfänger" je sauber programmieren
> lernen, wenn ihm nie gesagt wird, was falsch und richtig
> ist.

Er lernt es auf jeden Fall nicht dadurch, dass man ihn
mit "Regeln" bombardiert, die zwar in vielen Fällen
richtig, aber auch in vielen Fällen falsch sind.

Markus O. schrieb:

> Falk B. schrieb:
>> AHA!!!! Das ist schon ganz anders. Aber auch das kann
>> und sollte man in einem Zeitdiagramm darstellen.
>
> Weiß nicht so recht wie ich das umsetzten soll das
> Zeichnerisch darzustellen.

Man kann auch einen Automatengraphen zeichnen.

Falk B. schrieb:

> Bis du wirklich so unbedarft oder einfach nur faul?
> Mensch Meier, jeder 5. Klässler kann sowas!

Ich stelle mir ab und zu vor, wie die Weltgeschichte
verlaufen wäre, wenn Du mein Lehrausbilder gewesen
wärest.
Schätzungsweise wärst Du auf dem Heidefriedhof und
ich im Knast... :)

Egon D. schrieb:
> Ich stelle mir ab und zu vor, wie die Weltgeschichte
> verlaufen wäre, wenn Du mein Lehrausbilder gewesen
> wärest.
> Schätzungsweise wärst Du auf dem Heidefriedhof und
> ich im Knast... :)

Mit deiner fachlichen Kompetenz scheinst du ja nicht glänzen zu können.
Eher schon mit mieser Anmache und Priestertum.



Egon D. schrieb:
> aber auch in vielen Fällen falsch sind.
Oder kannst du das begründen, ohne dich auf Faulheit oder Dummheit 
berufen zu müssen?
Bedenke: Ich habe jede der "Regeln" (mehr oder weniger) begründet.
Das erwarte ich jetzt auch von dir, diese Ansage zu begründen.

Falk B. schrieb:

> Egon D. schrieb:
>> Ich stelle mir ab und zu vor, wie die Weltgeschichte
>> verlaufen wäre, wenn Du mein Lehrausbilder gewesen
>> wärest.
>> Schätzungsweise wärst Du auf dem Heidefriedhof und
>> ich im Knast... :)
>
> Wenn das mal kein Irrtum ist ;-)

Ja, wer weiss... Wir werden es wahrscheinlich nie
erfahren... :)


> "Ich werde euch brechen, und dann gaaanz langsam wieder
> aufbauen! HABT IHR MADEN DAS VERSTANDEN?!!"

:)

Markus O. schrieb:
> Wenn der Aktor1 (hier "Act1") nicht false ist, soll dieser schalten und
> erst wenn dieser wieder auf low ist, soll dieser auf false schalten und
> die Variable für Step 2 auf true gesetzt werden.

Dieser Satz ergibt für mich keinen Sinn. Ich vermute du hängst fest weil 
du auch keinen richtigen Plan vom Ablauf hast. Erstelle doch mal einen 
Plan - völlig lös gelöst von der Programmiersprache. Der bringt dich 
bestimmt weiter.

Falk B. schrieb:
> Teo D. schrieb:
>>> Schätzungsweise wärst Du auf dem Heidefriedhof und
>>> ich im Knast... :)
>>
>> Jaja, Andersdenkend Umbringen.... Hatten wir das nich schon mal, irgend
>> wann, irgend wo?
>> In welcher Hohle/Hölle bist du den aufgewachsen?!
>
> Das mit dem sinnerfassenden Lesen mußt du noch ein wenig üben . . .

Jo, is nicht mein Humor! Klär mich doch mal auf!

Was du da machen willst lässt sich wunderbar in einem Zustandsdiagramm 
(oder Tabelle) darstellen und in einem Zustandsautomaten umsetzen. Im 
Grunde genommen brauchst du eine Aufstellung aller möglichen Zustände. 
Für jeden Zustand listest du auf, welche Ereignisse auftreten können und 
wie darauf reagiert werden soll.

Siehe http://stefanfrings.de/multithreading_arduino/index.html#planung 
für ein bildliches Beispiel

Markus O. schrieb:
> Also noch einmal einfach gesagt...

Das ist wieder wirrer Text.

Warum läuft er eine definierte Zeit? Dieser Aktor hat also zwei Zustände 
(läuft bzw läuft nicht). Aber die Maschine hat noch andere Dinge, die 
den Gesamt-Zustand definieren. Löse dich vom Aktor und definiere alle 
Zustände der gesamten Maschine, dann für jeden Zustand die möglichen 
Ereignisse und dann für jedes Ereignis die Reaktion.

Du hast in deiner Aufzählung Zustände, Ereignisse und Reaktionen 
durcheinander gewürfelt. Ebenso sieht dein Code aus. Der Fehler steckt 
primär in deinem Plan.

Soweit ich das überblicke hast du insgesamt folgende Zustände:

1

Ausgangslage (Strom an)

2

Aktor 1 läuft

3

Pause nach Aktor 1

4

Aktor 2 läuft

5

Pause nach Aktor 2

Ist das so richtig? Ich würde aussagekräftigere Namen verwenden wie

1

Ausgangslage (Strom an)

2

Abpumpen

3

Pause nach Abpumpen

4

Auffüllen

5

Pause nach Auffüllen

Nur du kannst wissen, welche Namen sinnvoll sind.

Jetzt schreibe dahinter die Ereignisse und wie darauf reagiert werden 
soll. Entsprechend meiner Vorlage auf die ich eben verlinkt habe.

Deine Nummerierungen Act1, Act1, delayy, etc. sind grausam. In unserer 
Firma wurde jemand gekündigt, weil er das immer wieder gemacht hat. 
Benutze Aussagekräftige Namen! "Actuator" ist nicht aussagekräftig. 1, 2 
und y noch weniger.

Markus O. schrieb:
> blockieren do/while nicht den Arduino?

Wenn man es "richtig" macht, dann nein!
Wobei man "richtig" hier mit Protothreads, oder Rtos übersetzen könnte.

Falk B. schrieb:
> Dann bist du aber ein grottenschlechter Übersetzer! Erst recht, wenn
> deine Zielgruppe solche Leute wie der OP sind. Für Anfänger macht man
> das DEUTLICH einfacher, nämlich mit einer Statemachine.

Endliche Automaten und Nebenläufigkeit sind 2 völlig unterschiedliche 
Kapitel.
Sie kommen oft gemeinsam vor, sind aber doch nicht das gleiche.

Hier ein Vorschlag, welcher Nebenläufigkeit und Endlicher Automat 
vereint.
In Anlehnung an dem Adam Dunkels seine ProtoThreads.
Garniert, mit ein paar Endlosschleifen und Wartezeiten.....

EAF schrieb:
> ein Vorschlag

Sorry, das taskPriority(10000); hat da nichts zu suchen, bitte 
wegdenken.

>taskPriority(10000)

Würde ich sogar noch raufsetzen, damit das Programm möglichst gut läuft.

EAF schrieb:

> Egon D. schrieb:
>> aber auch in vielen Fällen falsch sind.
>
> Oder kannst du das begründen,

Selbstverständlich.


Ich bin mir nur gerade nicht sicher, ob ich angesichts
von ...

> Mit deiner fachlichen Kompetenz scheinst du ja nicht
> glänzen zu können. Eher schon mit mieser Anmache und
> Priestertum.

... Lust dazu habe.


> Bedenke: Ich habe jede der "Regeln" (mehr oder weniger)
> begründet.

Sicher, und die Begründungen sind ja auch nicht falsch --
nur sind sie das, was solche Begründunge immer sind:
Unvollständig.

Das Problem bei der Programmiererei ist ja nicht, dass
es einen Mangel an Regeln gäbe, und auch ein Mangel
an Begründungen für die Regeln ist nicht das Problem.

Das Problem ist m.E., dass die meisten Regeln allgemeingültig
formuliert werden, es aber nicht sind -- und es wird kein
Detektor mitgeliefert, der zu erkennen gestattet, wann die
Regel NICHT gilt.


> Das erwarte ich jetzt auch von dir, diese Ansage zu
> begründen.

Ich bin zwar nicht verpflichtet, über jedes Stöckchen zu
springen, aber sei's drum...

Ich beschränke mich auf die erste Aussage "Codedopplungen
sind böse". Im großen und ganzen ist die Aussage richtig.
Dennoch ist es m.E. nutzlos, dies als zu befolgendes
Gebot in den Raum zu stellen: Einem einigermaßen geübten
Programmierer widerstrebt es sowieso, genau denselben
Ablauf mehrfach hinschreiben zu müssen -- der braucht
dieses Gebot nicht.

Einem Anfänger dagegen hilft die Regel in keiner Weise --
er hatte ja einen Grund , den Code mehrfach hinzuschreiben.
Man muss ihm helfen, diesen Grund zu finden, zu verstehen
und zu beseitigen.


Für die Dopplungen gilt m.E. ungefähr folgendes:

"Exakte Dopplungen längerer Codepassagen sind i.d.R.
ein Anzeichen dafür, dass das Programm noch nicht
ausgereift ist. Sie sind in Programmen, die zur
praktischen Nutzung gedacht sind, zu vermeiden, weil
sie nutzlosen Speicherplatzverbrauch, schlechtere
Wartbarkeit und schlechtere Verständlichkeit zur Folge
haben.

Während der Entwicklungsphase können solche Dopplungen
leicht auftreten, weil man oft nicht von vornherein
kompletten Problemüberblick hat, sondern in die Struktur
der zu lösenden Aufgabe erst Schritt für Schritt
eindringt. In diesem Fall kann es sehr sinnvoll sein,
zunächst mal einen verstandenen Fall nach dem anderen
wegzuprogrammieren, ohne sich um Dopplungen zu kümmern.

Wenn man dann sicher ist, dass das Programm so, wie man
es heruntergeschieben hat, korrekt ist, überarbeitet
man den Quelltext nochmal ("Refactoring") und fasst
dabei mehrfach auftretenden Passagen zusammen. Man
verhindert auf diese Art, dass man fälschlich Fälle
zusammenfasst, die in Wahrheit subtile Unterschiede
aufweisen und nicht zusammengefasst werden dürfen."

Egon D. schrieb:
> Ich bin zwar nicht verpflichtet, über jedes Stöckchen zu
> springen, aber sei's drum...

Mache dir keine Sorgen...
Du bist nicht über das Stöckchen gesprungen.

Ganz im Gegenteil, du folgst meiner Argumentation in allen Belangen, 
bist sogar etwas ausführlicher.
Und mit keinem Wort hast du deine "falsch" Ansage
> aber auch in vielen Fällen falsch sind.
mit irgendeinem Beleg versehen!
Also eigentlich genau das, was ich von einem vernünftigen Menschen 
erwartete.

Tipp:
Wenn du weiter auf mich einhauen möchtest, kann ich dir sogar die 
Munition liefern.
Denn meine TaskMakros beinhalten statische Variablen.
Einfach als Kompromiss, da es so schlanker und einfacher ist, als dort 
einen Stack Wechsel Mechanismus einzubauen.
Eine Form der Faulheit. Meiner Faulheit.

EAF schrieb:

> Ganz im Gegenteil, du folgst meiner Argumentation
> in allen Belangen,

Nicht ganz.


> bist sogar etwas ausführlicher.

Nicht nur das.


Ich formuliere meinen Punkt noch deutlicher:

Codedopplungen sind keineswegs immer böse.

Es ist in manchen Fällen sehr empfehlenswert, sie
während der Entwicklungsphase zeitweise in Kauf zu
nehmen oder sogar als bewusstes Hilfsmittel für das
Problemverständnis einzusetzen.

Das ist bereichsweise das exakte Gegenteil von dem,
was Du behauptet hast.


Ist aber auch nicht weiter wichtig. Wer mich verstehen
will, versteht mich, und wer nicht will, lässt es eben
bleiben.

EAF schrieb:
> Wie soll denn eine "Anfänger" je sauber programmieren lernen, wenn ihm
> nie gesagt wird, was falsch und richtig ist.
> Und wo die Probleme stecken.

Ähem... Sowas lernt man zur einen Hälfte durch gute Beispiele und zur 
anderen Hälfte durch eigenes logisches Denken und einer Prise 
Selbstdisziplin. Aber nicht durch einen Wald von Verbots-Schildern.

Ich hab das hier schon recht vielen Leuten geschrieben: zuerst die 
Funktionalität durchdenken und das Projekt planen und danach erst in die 
Tastatur hauen und Quellcode produzieren.

Allerdings bin ich aus den diffusen Äußerungen des TO auch nicht schlau 
geworden. Für mich sieht das wie ein einfaches Schrittschaltwerk aus, wo 
zu bestimmten Zeiten auf der langsam drehenden Walze irgendwelche 
Kontakte für eine bestimmte Zeit mal geschlossen werden sollen. 
Irgendwelche Funktionalität, die dann boolean Ergebnisse früherer 
Aktionen berücksichtigt (if (IOResult==false) then ZieheNotbremse() oder 
so), habe ich hier nicht sehen können.

Möglicherweise meint der TO jedoch etwas ganz anderes.

W.S.

Egon D. schrieb:
> Das ist bereichsweise das exakte Gegenteil von dem,
> was Du behauptet hast.

Pah....
Du hast behauptet dass meine Aussagen falsch sind, zumindest in 
vielen Fällen.
Siehe:
> aber auch in vielen Fällen falsch sind.
Das hast du nicht belegt, und wirst du auch nicht belegen können.

Im Gegenteil, du hast in deinen Begründungen zugestimmt und zwar, dass 
diese "Anstandsregeln" grundsätzlich richtig sind.




W.S. schrieb:
> Aber nicht durch einen Wald von Verbots-Schildern.
Fahren lernt man in der Fahrschule.
Und da fängt es mit den Regeln an.
Erst die wichtigste Theorie und dann ans Steuer.

Ansonsten kann ich nur sagen, dass sich der TO schon viel vorher bei mir 
in die Nesseln gesetzt hat, per Dokuleseverweigerung.
Sinngemäß: "Bücher interessieren mich nicht."

Und so leid es mir tut, wenn man nur aus Beispielen lernen will, also 
herzlich kenntnisfrei ist, dann sind die Arduino Beispiele im Netz nicht 
unbedingt hilfreich. Manche gar kontraproduktiv.

So hat er einmal klare Ansagen bekommen, sogar mit Lösungsansätzen.
Was er dann daraus macht, ist ganz alleine sein Problem.
Lass ihm doch das Problem.
Warum möchtest du den Boten töten?
Warum willst du den "Anfänger" weiter seltsamen Code produzieren lassen?

Zum Zweiten:
Wir sehen doch, dass er nicht von alleine logisch denkt und 
diszipliniert schreibt. Klar kann man im Straßenverkehr auch auf alle 
Anstandsregeln oder "Verbotsschilder" kacken. Bringt nur nix positives. 
Eher nur Frust und Ärger.

"Verbotsschilder", so ein Schwachsinn....
Ersetze alle "böse" in dem angemeckerten Text durch "unvorteilhaft" oder 
"suboptimal", wenn dir das lieber ist.


----------------

Grundsätzlich:
Aus Büchern will/kann er es nicht lernen.
Die Arduino Beispiele zeigen es auch eher selten.
Und ich soll/darf es ihm nicht sagen.

Was soll der Mist?
Wollt ihr Arduino User, oder andere Anfänger, absichtlich blöd 
sein/bleiben lassen, um dann hinterher drüber herziehen zu können?
Schwachfug!

Wenn es jetzt noch fachlich was zu dem Eingangsproblem zu sagen gibt, 
dann ok. Aber mit dem anderen Kram könnt ihr mir an der Pupe schmatzen. 
Das interessiert mich nicht(mehr).

Markus O. schrieb:
> und würde mich freuen
> wenn sich den jemand ansehehn und Verbesserungsvorschläge außern würde.

Eins kann ich dazu schon sagen:
Eine Kristallkugel bis zur Version 5.47.11 ist dafür nicht wirklich 
ausreichend.
Welche muss ich dafür erwerben?