Beiträge von rmac

Abschließende Info zum Thema:

Also CrossCom funktioniert auch unter 2.2.x !

Der Fehler lag, wie schon vermutet, an meiner BOF-Startüberwachung, nicht am CrossCom.

Der Tipp von robodoc ( ) funktioniert auch, allerdings musste ich das so Einbinden
wie unter
http://www.roboterforum.de/rob…egistry_keys-t1622.0.html
beschrieben.

gruß
rmac

Doch, es gibt da ein Problem:

Ich habe mir die Sache nochmal durch den Kopf gehen lassen und
muß dust2 doch teilweise recht geben.

Ich revidiere mich zwar ungerne , aber andererseits möchte
ich hier auch nichts Falsches stehen lassen.

Wie schon gesagt, ist der (echte) Überlauf der NUM (=Single real) nicht das
Problem, aber der (Gleitkomma-)Zähler wird irgendwann mal so groß (> 16777216),
dass das Inkrement (+1) kleiner als die speicherbare Genauigkeit
(7-8 Stellen bei Single) wird. D.h. beim nächsten Inkrement fällt die +1
damit unter den Tisch und der Zähler zählt nicht mehr weiter sondern bleibt
bei 16777216 stehen.
Im Klartext: (num)16777216 + 1 = (num)16777216

Insofern wäre die Prüfung einer Obergrenze (wie von dust2 vorgeschlagen )
doch sinnvoll, allerdings dann erst bei 16777216.
Also wenn ihr mal einen Zähler habt, der (mit Inkrement +1 bzw. kleinen Inkrementen)
bei 16777216 stehen bleibt, dann wisst ihr jetzt warum....

Ziehe hiermit meinen Einwand also zurück....
gruß
rmac

Hi,

Zitat von roboprog

[...]2. wenn ich immer nur +/- 1 zähle wie soll da meine num ein real annehmen ??
einfach mal so ???[...]

Braucht sie nicht annehmen, ist sie nämlich schon.....
Soll heißen: Ganzzahlen werden in RAPID nicht explizit in einem Ganzzahlen-Format (Integer) gespeichert,
sondern immer als Gleitkommazahlen.

gruß

Hi dust2,

Zitat von dust2

[...]Letzendlich muss jeder selbst wissen, was er tut![...]

Yep, genau so ist es.

Zitat von dust2

[...]Ganzzahlen zwischen -8388607 und +8388608 werden immer als exakte Ganzzahlen gespeichert. [...]

Das hatte ich bislang überlesen. Hab ich wieder was dazu gelernt. Thx...

Zitat von dust2

[...]Die Frage, wo den nun counter im Listing von robprog das erste Mal auf 0 initialisiert werden soll, ist immer noch nicht beantwortet!!?? Wo würdet Ihr das tun, um auch über PZtoMain hinwegzählen zu können?[...]

Ich denke
PERS num nCounter:=0;
sollte hierfür ausreichend sein. Rücksetzen dann z.B. über das Panel.

Gruß
rmac

dust2,

bei ein paar deiner Ausführungen gebe ich dir zweifellos recht, aber der Ton
macht bekanntlich die Musik.... und da sehe ich durchaus noch Verbesserungs-Potential.

Eine Sache leuchtet mir hingegen nicht ein:

Zitat von dust2

[...]Gute Programmierer achten beim Hochzählen auf Überlauf:
IF counter<8388628 THEN
counter:=counter+1;
ELSE
! Fehler Überlauf geht schneller als man denkt! siehe WINDOWS....
ENDIF
[...]

Alles anzeigen

Wie kommst du denn auf diesem Überlauf (oder hast du da nur wahllos etwas eingetippt ?)
Laut Handbuch sind bei ABB die NUMs nach ANSI IEEE 754-1985 (Single) kodiert (siehe http://de.wikipedia.org/wiki/IEEE_754),
d.h. die größte darstellbare Zahl liegt bei ca. 3,403·10³⁸.

Selbst wenn der Prozess nonstop im Sekundentakt laufen würde (was beim Schweißen ja wohl selten der Fall sein wird),
wäre der Zählerstand nach einem Jahr bei 3,1536·10⁷ (= 60*60*24*365).
D.h. der Zähler würde so ungefähr nach 1,08·10³¹ ( = 3,403·10³⁸ / 3,1536·10⁷) Jahren überlaufen.

Glaubt man der Annahme, dass unser Sonnensystem noch vielleicht 4-5 Milliarden (10⁹) Jahre existiert,
hat der Zähler also noch ein wenig Luft nach oben.
Ich würde mich sogar zu der Aussage hinreißen lassen, dass, selbst wenn die Menschheit (und der Roboter) bis dahin
überleben und sie bei der Flucht aus dem zusammenbrechende Sonnenssystem die Schweißanlage mitnehmen würden,
der Zähler selbst bis zum Ende des Universums nicht überlaufen wird.

Ich glaube unter diesen Umständen würde ich mir eine Überlaufs-Prüfung sparen.
Gute Programmierer machen das ....

In diesem Sinne
gruß
rmac

Nach meinem Kenntnisstand nicht; der fehlende Parameter ist dann eben (zur Laufzeit) nicht definiert (ungültig)
und erzeugt dann ggfls. einen (Laufzeit-)Fehler wenn innerhalb der Routine auf den Parameter zugegriffen
wird.

Mach doch mal in der EXT den zweiten Parameter mit rein (wie in der DEF), also:

EXT ftcInit(INITOPTIONS:IN, REAL:IN)

Thilbi: das ist doch keine Funktion.....

Guter Tipp! :ylsuper:
Werd ich mal probieren...

Danke
gruß
rmac

Hi,

mußt du nicht auch den Parameter-Typ deklarieren (?):

DEF ftcInit(ftcInitSwitch:IN,flexDeg:IN)
DECL INITOPTIONS ftcInitSwitch
SWITCH ftcInitSwitch
CASE #init1
....
CASE #init2
....
ENDSWITCH
END

gruß

Hi robodoc,

Danke für den Hinweis, aber ich habe das nicht als VB-Projekt, sondern unter Delphi programmiert.
Die Einbindung erfolgt hier dynamisch über die OLE-Klasse "CrossCommEXE.CrossCommand".

Ich denke ich habe folgendes Problem:
Beim Hochfahren der Steuerung wird meine Anwendung automatisch gestartet (AutoStart-Ordner)
und wartet zunächst auf das vollständige Hochfahren der BOF !
Die Anwendung wartete hierbei (max. 5 Minuten) bis ein Fenster der Klasse "ThunderRT6FormDC",
das zum Prozess "KukaBOF.exe" gehört, geöffnet wird. Damit ist das Hochfahren der BOF
normalerweise beendet. Bei der 4.1 funktionert das so.

Möglicherweise weicht bei der 2.2.x Steuerung der Name der Fensterklasse und/oder des Prozesses
ab und dadurch laufe ich auf den Timeout.
Werde das mal prüfen wenn ich wieder an die Steuerung komme.

thx anyway und gruß
rmac

Hi,

Danke für den Tipp.
Ich meine ich hätts dynamisch eingebunden, aber ich schau mir nochmal den Quelltext an...
Werd mal in dieser Richtung weiterforschen.

gruß
rmac

Hi,

ich mache bei diversen KRC1 Ver. 4.1 Datenaustausch per Crosscom.exe und das
funktioniert auch ziemlich gut.

Jetzt habe ich hier eine KRC1 Ver. 2.2.8 (oder so ähnlich) und da funktioniert das nicht mehr (?)

Könnt ihr bestätigen, dass das bei 2.2.x prinzipiell nicht funktioniert, oder
kann/muß man da was einstellen ?

Habe hier ein (inoffizielles) PDF, da steht drin, dass das ab VKR C1, R1.1.8 funktionieren soll.

Bin für jegliche Info dankbar.....

Gruß
rmac

Zitat von Jesi

[,,,]Ich bin doch im Experten Modus, und laut beschreibung darf man in diesem solche syntaxe wie loop und if verwenden. oder nicht?[...]

...wenn du die "Experten"-Anweisungen syntax-konform formulierst, sollte das schon gehen...

Wenns geht, poste doch dein Programm (ggfls. auszugsweise) hier und schreib Fehlerort- und meldung dazu.

Tut mir leid, aber dazu kann ich mir einen Kommentar nicht verkneifen

Zitat von Jesi

[...]Es verarscht mich irgendwie...[...]

...das geht mir jeden Tag so....gewöhn dich einfach dran....

Zitat von Jesi

[...]Bei jeder anderen Programmiersoftware, kann man schreiben was man braucht und das funktioniert dann auch[...]

...also ich programmier schon knapp ein Vierteljahrhundert, aber so einen Spruch habe ich bislang weder gehört, geschweige denn so etwas in der Realität erlebt...

"Wie" versuchst du denn zu programmieren ? Über das KCP ?
Wie gehst du denn vor ? Gib mal mehr Infos....

gruß

Hi,

wenn du etwas KUKA-ähnliches suchst, dann schau mal in der Doku unter:
ClkStart bzw. ClkStop bzw. ClkReset

Es gibt aber auch noch einen getimten Interrupt....
ITimer

gruß
rmac

Hi,

das Ding heißt "Pow"

Zitat:
Pow Calculates the power of a value
Pow (Power) is used to calculate the exponential value in any base.
The value of the base x raised to the power of the exponent y ( x^y ).

Pow (Base, Exponent)
Base Data type: num
Exponent Data type: num

Insider-Info: sowas steht im Handbuch.....

gruß
rmac

Hi,

des Rätsels Lösung lautet:
ATAN2(Y,X) (Standardfunktion)

Zitat Doku:
[...]Arcustangens
Der Tangens eines Winkels ist definiert als Gegenkathete (Y) dividiert durch Ankathete (X)
im rechtwinkligen Dreieck. Hat man die Länge der beiden Katheten, kann man also den Winkel
zwischen Ankathete und Hypotenuse mit dem Arcustangens berechnen.
Betrachtet man jetzt einen Vollkreis, so ist es entscheidend, welches Vorzeichen die Komponenten
X und Y haben.Würde man nur den Quotienten berücksichtigen, so könnten mit dem
Arcustangens nur Winkel zwischen 0° und 180° berechnet werden. Dies ist auch bei allen
üblichen Taschenrechnern der Fall: Der Arcustangens von positiven Werten ergibt einen
Winkel zwischen 0° und 90°, der Arcustangens von negativen Werten einen Winkel zwischen
90° und 180°.
Durch die explizite Angabe von X und Y ist durch deren Vorzeichen eindeutig der Quadrant
festgelegt, in dem der Winkel liegt (s. Abb. 6). Sie können daher auch Winkel in den
Quadranten III und IV berechnen. Deshalb sind zur Berechnung des Arcustangens in der Funktion
ATAN2(Y,X) auch diese beiden Angaben notwendig, z.B.:
A = ATAN2(0.5,0.5) ;A=45
B = ATAN2(0.5,-0.5) ;B=135
C = ATAN2(-0.5,-0.5) ;C=225
D = ATAN2(-0.5,0.5) ;D=315
[...]

Ansonsten hilft: Doku lesen....

gruß
rmac

Hi,

Zitat von dust2

TASK PERS num rr{6,6,2}:=[[ ...

Wenn du
TASK PERS num rr{2,6,6}:=[[ ...
geschrieben hättest, hätts auch gefunzt....
D.h. die Schachtelung (von aussen nach innen) läuft entsprechend der Indizes
von links nach rechts.

Gruß
rmac

Hi,

ich denke, dass es da keine Grenze bzgl. des TEST-Ausdrucks oder der CASE-Ausdrücke gibt,
sondern das die Größe der gesamten Konstruktion durch die max. Code- bzw. Programmlänge begrenzt ist.

Egal ob der Quelltext durch einen Compiler in Maschinen- oder P-Code umgewandelt, oder
durch einen Interpreter abgearbeitet wird, letztendlich läuft es intern auf eine (lange)
IF-THEN-ELSE... Kette hinaus, die bei vielen CASEs einfach langen Code erzeugt.
Wenn es (irgendwann) zu eine Fehlermeldung kommen sollte, würde ich das eher in
dieser Richtung vermuten.

Falls das in deinem Projekt so vorgegeben ist, nun gut, dann kann man da nichts machen.

Anderenfalls würde ich das folgendermaßen realisieren:
- Jedes (Teil-)Programm in eine Routine packen
- Ein Array aus Records mit Index-Nr. und String (=Routinenname) als Konstante deklarieren
und mit den Indizes und den entsprechenden Routinennamen besetzen
- Zur Laufzeit den Gruppeneingang lesen, und
- über eine Schleife das Array nach dem (Gruppen-)Index durchsuchen und im Erfolgsfall
- den Routinenname per "CallByVar" ausführen

Wenn du noch einen draufsetzen willst, kannst du auch die Array-Daten aus einer externen
Textdatei einlesen, ähnlich einer INI-Datei, und könntest damit auch (theoretisch) zur Laufzeit
das Verhalten ändern/anpassen.

Eleganter/flexibler wirds nich....

Gruß
rmac

Zitat von Iceberg

Somit könnte man sich schöne Module zusammenbauen, die man wieder nutzen kann wenn mehrere Sachen berechnet werden sollen. Dazu müsste die Berechnung natürlich in einer unterroutine sein...

... und in eine solche Routine baut man dann so schöne Sachen ein wie z.B.
Plausibilitätsprüfung(en)/Fehlerhandling, in diesem Fall auf Messwert_3 == 0 bzw. Gegenkathete_Alpha ==0 prüfen

gruß