Lang anliegender Eingang nur einmal Variable hochzählen

IrrerPolterer · February 25, 2011 at 12:46 AM

Quote from Twister

Eventuell könnte sogar folgende Zeile zu einen "wahren" Zustand führen
wenn genau in der Abfrage sich der Zustand von $IN[42] ändert

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

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.

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

Twister · February 25, 2011 at 1:00 AM

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

titan72 · February 25, 2011 at 9:45 AM

@ twister

Quote

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?

Tilman · February 25, 2011 at 10:21 AM

Hallo Rainer,

Quote

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

Gut gepoltert 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

Twister · February 25, 2011 at 12:53 PM

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

Twister · February 25, 2011 at 12:57 PM

titan
Sorry, hab dich überlesen.
Nein, ist noch nicht vorgekommen, habs aber auch noch nie
so getestet oder sowas programmiert.

Gruß
Twister

IrrerPolterer · February 27, 2011 at 11:58 AM

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.

Tilman · February 27, 2011 at 1:28 PM

Hallo Polterer,

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

Da Ihr mir ja nicht den O2I Treiber geben wollt , 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 : das erste Mal bereits bei i1=~500, und dann immer, und immer, und immer wieder.

Mit freundlichen Grüssen,
Tilman/Frankreich

PS:

Quote

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!

Urmel · February 27, 2011 at 2:17 PM

Quote from 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).

WolfHenk · February 27, 2011 at 4:09 PM

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

IrrerPolterer · March 2, 2011 at 6:02 PM

Quote from 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.
Entschuldigung angenommen?

Tilman · March 2, 2011 at 6:54 PM

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 ? 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 (warum kann man hier eigentlich nicht mit Rotwein anstoßen?)
Tilman

Lang anliegender Eingang nur einmal Variable hochzählen

Gebrauchtroboter kaufen - Was ist zu beachten. Die Checkliste zum kauf von gebrauchten Robotern

Was macht ein Roboterprogrammierer genau und was verdient er?

Vernetzen, referenzieren, kollaborieren: Das B2B Portal für die Produktionsautomatisierung

Sie wollen Ihr Stellenangebot im Roboterforum schalten? Ab 149€

Werde Roboterprogrammierer bei ROBTEC GmbH in Mainburg / Bayern

Tags

Wieviele Mitglieder waren heute eingeloggt?