Lang anliegender Eingang nur einmal Variable hochzählen



    Eventuell? Könnte? Das würde jegliche Programmierlogik auf den Kopf stellen und macht eine Programmiersprache unbrauchbar.
    Ich gehe mal genaz stark davon aus, dass dies so nicht vorkommen kann.



    Zitat von Twister


    Und hin und wieder hatte ich den Fehler dass es keine gültige $POS_ACT mehr gab
    weil ein Benutzer hin und wieder die Betriebsart wechselt und somit kein
    Koordinatensystem angewählt war.


    Um $POS_ACT zu "verlieren" brauchts schon ein bischen mehr, als nur die Betriebsart zu wechseln...Programm abwählen z.B.

    Greetings, Irrer Polterer!

    Wie poste ich falsch? Nachdem ich die Suche und die FAQ erfolgreich ignoriert habe, erstelle ich das gleiche Thema in mehreren Unterforen, benutze einen sehr kreativen Titel wie "Hilfe", am Besten noch mit mehreren Ausrufezeichen, und veröffentliche einen so eindeutigen Text, dass sich jeder etwas Anderes darunter vorstellt.


    Life is a beta version. Full of bugs and no Manual.

    • Schritt für Schritt zum Roboterprofi!

    Ok, hab ich vergessen zu erwähnen, bei dieser Anlage wird das Roboterprogramm
    automatisch abgewählt wenn die Betriebsart "Auto-Extern" verlassen wird.


    Und das mit dem Wechsel der Eingänge während einer
    Befehlszeile werd ich dann auch mal bei Gelegenheit testen.
    Also jetzt interessierts mich selbst...
    Das hast jetzt davon... Polterer ;)

    Kleinere Wunder werden sofort erledigt... größere nach der Mittagspause...

    @ twister


    Zitat

    IF ($IN[42]==FALSE) AND ($IN[42]==TRUE) THEN
    ;unglaublich aber wahr
    ENDIF


    ... also eine Vermutung von dir und ist noch nicht vorgekommen, ja!? ... oder?

    Hallo Rainer,


    Zitat


    Das würde jegliche Programmierlogik auf den Kopf stellen und macht eine Programmiersprache unbrauchbar.


    Gut gepoltert :applaus: Aber das Problem, das Twister aufgeworfen hat, ist schon reell. Es gibt in der Steuerung mehrere Tasks (2 sichtbare für den Benutzer), und da gibt es einen preemptiven Scheduler, der den Submit Interpreter einfach unterbricht. Alles hier sind Vermutungen, ich weiß das, und ich habe auch nirgendwo Informationen darüber gelesen. Fest steht jedoch, daß mit einer Taktfrequenz von 12ms die Eingänge gelesen werden. Und dann muß halt der Submit Interpreter angehalten werden, wo er gerade steht wird dem Scheduler egal sein.


    Also, daß

    Code
    $IN[x] AND (not $IN[x])

    wahr ist, kann durchaus sein, allerdings ist es sicher sehr unwahrscheinlich.


    In anderen Systemen, gibt es "CriticalSection" oder "Semaphore" um Tasks/Threads gegenseitig zu verriegeln. Das wäre sicher eine saubere Lösung, scheint es jedoch bei KRL nicht zu geben.


    Ich werde jedenfalls in Zukunft besser aufpassen. Und es ist auch einfach. Hier mein korrigierter Code zum Zählen.


    Code
    BOOL in42,m_in42
m_in42=TRUE


in42=$in[42]
if (in42 and (not m_in42)) then
 stueck=stueck+1
endif
m_in42=in42


    Danke, Twister, für Deinen sehr konstruktiven Beitrag.
    Tilman/Frankreich

    Einmal editiert, zuletzt von Tilman ()

    Hallo Tilman,


    danke für dein Verständis.


    Man stellt sich nur einfach vor eine IF - Abfrage ist etwas komplexer:


    IF ($IN[42] AND (SIN(a)==COS(b)) AND (TAN(c)==0.5) AND $IN[42]==FALSE) THEN
    ;wird immer warscheinlicher
    ENDIF


    Na irgendwann wird sich der "Scheduler" schon mal dazwischen drängen. ;)
    Oder es gibt nen internen "CriticalSection" der wenigstens eine Befehlszeile
    gegen Unterbrechung schützt.
    Natürlich umgeht man solche Konstrukte, aber wer weiß, es werden
    mit den Robotern ja nicht nur Werkstücke von A nach B transportiert.
    Vielleicht gibts ja jemand von KUKA der hier was zu sagen kann?


    Auf jedenfall werden zwischen beliebigen Befehlszeilen im SUBMIT
    die Eingangszustände aktualisiert und fast keinem ist dieses Problem
    bewusst. Wenn man sich den sps.sub mal anschaut sieht man dass dies
    eine große Endlosschleife ist (LOOP ... ENDLOOP) ohne Anfang und
    Ende wie z.b. bei einer SPS.
    Ein "CriticalSection" wie bei C++ wär natürlich Klasse.
    Aber man kennt die Eigenheiten und kann sie somit auch an anderer
    Stelle zum Vorteil nutzen.


    Falls ich diesen Thread von Roba nun auf eine andere Schiene
    gelenkt habe möge man mir verzeihen.


    Gruß
    Twister

    Kleinere Wunder werden sofort erledigt... größere nach der Mittagspause...

    Dieser Thread zeigt mal wieder eindeutig den Unterschied zwischen blanker Theorie und Praxis...
    Ich wieß nicht vieviel 1000 Programmzeilen ich in meiner Laufbahn schon hinter runtergetippt habe, aber ich kann euch versichern, das genannte Problem ist nicht aufgetreten.
    Jetzt weiß ich jedenfalls wieder, warum ich einen Elektriker mit Programmiererfahrung, "frisch von der Uni kommenden Studenten" vorziehe. Versteht mich nicht falsch, für unsere Projekte muss man sich über solche Dinge keine Gedanken machen. Es geht um Industrieroboter. Diesollen ihre Aufgabe verrichten - mehr nicht.


    Und da es hier ohne schon völlig OT geworden ist - klinke ich mich mal aus.
    Meine Flankenerkennungen (um nichts anderes ging es dem TS ja) funktionieren jedenfalls immer.

    Greetings, Irrer Polterer!

    Wie poste ich falsch? Nachdem ich die Suche und die FAQ erfolgreich ignoriert habe, erstelle ich das gleiche Thema in mehreren Unterforen, benutze einen sehr kreativen Titel wie "Hilfe", am Besten noch mit mehreren Ausrufezeichen, und veröffentliche einen so eindeutigen Text, dass sich jeder etwas Anderes darunter vorstellt.


    Life is a beta version. Full of bugs and no Manual.

    Einmal editiert, zuletzt von IrrerPolterer ()

    Hallo Polterer,


    Also, ich klinke mich nicht aus, denn das Thema ist wichtig :nasowas:


    Da Ihr mir ja nicht den O2I Treiber geben wollt :bawling:, schlage ich den Versuch mit einer Variablen des Typs BOOL vor. Ansonsten könnte ich es auch mit $IN demonstrieren.


    Folgender Test. In einem Bewegungsprogramm, schreibt man:

    Code
    I1=0
$LOOP_MSG="                                                            "
Loop
 b1=not b1
EndLoop


    b1 und i1 sind global in config.dat deklariert.


    Und dann im Submit-Interpreter:

    Code
    i1=i1+1
b2=b1			;b2 hat also denselben Wert wie b1
if b1 and (not b2) then	;eigentlich immer falsch, oder?
 offset=0
 $LOOP_CONT=true
 SWrite($LOOP_MSG[],Stat,Offset,"unglaublich aber wahr: %d",i1) 
endif


    So, und nun die Frage: "Unglaublich, aber wahr?" Dein Tipp, Irrer Polterer, passiert das wirklich? Was sagen Deine 1000 Programmierzeilen-Erfahrung?


    Überraschung :dance:: das erste Mal bereits bei i1=~500, und dann immer, und immer, und immer wieder.


    Mit freundlichen Grüssen,
    Tilman/Frankreich


    PS:

    Zitat


    Jetzt weiß ich jedenfalls wieder, warum ich einen Elektriker mit Programmiererfahrung, "frisch von der Uni kommenden Studenten" vorziehe.


    Für die Zukunft: Schluß mit solchen dummen Sprüchen. Diese Polemik ist wirklich Unsinn!

    Zitat von Tilman


    Für die Zukunft: Schluß mit solchen dummen Sprüchen. Diese Polemik ist wirklich Unsinn!


    Schön friedlich bitte.


    Die Aussage vom Polterer war sicher nicht polemisch gemeint. Sie entspricht halt seiner Erfahrung in der kleinen orangen Programmierwelt.


    Fakt ist, praktisch in allen Hochsprachen mit Multitasking/Multithreading muss man auf sowas aufpassen.


    Und selbst ohne Parallelverarbeitung, mit der Nummer

    Code
    If Eingang(x) and not Eingang(x) then
   // passiert nie


    kann man sich schon auf einem 50 Cent Mikrocontroller ins Knie schiessen, wenn da zweimal hintereinander der Eingang gelesen wird und keiner garantieren kann, das immer noch die selbe Spannung anliegt (z.B. bei Tastenprellen).

    Einmal editiert, zuletzt von Urmel ()

    Kinners, laßt die Kirche im Dorf.
    Unsere EAs sind meistens aufm Bus.
    Der aktualisiert sich alle 10-20 mS.
    Und die Eingangssignale sind meist Inis also Transistoren, die selbst auch nur (mit Hysterese) schalten, wenn Kontakt sicher da ist.


    Man kann, wenn man will, aber man sollte keine Doktorarbeit draus machen.
    Also seid lieb zueinander :blumen: :liebe024:

    Wolfram (Cat) Henkel

    never forget Asimov's Laws at the programming of robots...

    "Safety is an integral part of function. No safety, no production. I don't buy a car without brakes."


    Messages und Mails mit Anfragen wie "Wie geht das..." werden nicht beantwortet.

    Diese Fragen und die Antworten interessieren jeden hier im Forum.


    Messages and Mails with questions like "how to do..." will not be answered.

    These questions and the answers are interesting for everyone here in the forum.

    Zitat von Tilman

    Für die Zukunft: Schluß mit solchen dummen Sprüchen. Diese Polemik ist wirklich Unsinn!


    Sorry, war nicht so gemeint. Verstehe mich nicht falsch. Sollte nicht bedeuten "ihr habt alle keine Ahnung". Sagen wir's mal so, die Akademiker (oder die werdenden) sind mir einfach zu anstrengend, wenn es um die normalen Anwendungsprogrammierungen geht. Dein Beispiel bleibt nun mal blanke Theorie (siehe auch Post von WolfHenk - besser kann man's nicht beschreiben), mit der ich mich nicht befassen muss oder will. Kollegen, die mich bei Projekten unterstützen oder nach meinen Anweisungen arbeiten sollen mir halt nicht mit solchem theoretischen Krams kommen, sondern das Projekt fertig machen. Aber mir ist durchaus bewußt, dass die Technik nicht so weit wäre, wenn es nicht Leute geben würde, die solche Themen wie dieses hier hinterfragen.


    Also Tilmann, das war einfach nur mal wieder zu schnell runtergetippt - mangels Zeit - und sollte niemanden hier beleidigen. :blumen:
    Entschuldigung angenommen? :beerchug:

    Greetings, Irrer Polterer!

    Wie poste ich falsch? Nachdem ich die Suche und die FAQ erfolgreich ignoriert habe, erstelle ich das gleiche Thema in mehreren Unterforen, benutze einen sehr kreativen Titel wie "Hilfe", am Besten noch mit mehreren Ausrufezeichen, und veröffentliche einen so eindeutigen Text, dass sich jeder etwas Anderes darunter vorstellt.


    Life is a beta version. Full of bugs and no Manual.

    Hallo Rainer,


    Du brauchst Dich wirklich nicht zu entschuldigen. Ich habe überempfindlich reagiert, vermutlich weil ich saulang studiert habe, erst Ingenieur, dann französisch, und dann noch ein Doktorat... Aber wenn wir schon mal beim Entschuldigen sind, verzeihe bitte auch mir, daß ich mich geringfügig über Dich lustig gemacht habe.


    In Rahmen meiner Firma arbeite ich übrigens sehr oft mit Elektrikern zusammen, und schätze besonders deren oft sachliches und nüchternes Denken. Das ist halt Berufserfahrung... an der es Studenten bei ihrem Berufsanfang manchmal (natürlicherweise) fehlt.


    Den Einwand von Twister (hat der eigentlich studiert? Oder war nur ich gemeint :bawling:? Ganz jung ist Twister jedenfalls auch nicht mehr ;)) halte ich jedoch nach wie vor für super wichtig, auch für den normalen Alltagsgebrauch. Ich war jedenfalls ziemlich überrascht, daß bereits nach 500 Zyklen der Scheduler den Submit-Interpreter zwischen 2 Zeilen unterbrochen hat. Währenddessen kann dann ein Eingang seinen Zustand wechseln. Ob der nun "aufm Bus liegt", oder nicht. spielt da keine Rolle.


    Also, ebenfalls :blumen: :beerchug: (warum kann man hier eigentlich nicht mit Rotwein anstoßen?)
    Tilman

    Einmal editiert, zuletzt von Tilman ()

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden