Beiträge von Hermann

Hallo,
warum machst Du Dir da solche Gedanken darüber?
Mein Motto:
wenn's funktioniert und durchschaubar ist, dann ist's gut.

Also, wenn Deine Lösung mit Interrupt funktioniert, warum eine
andere suchen?

Nur weil andere es anders machen? Die haben vielleicht nur nie was von
Interrupts gehört, oder mögen sie nicht, oder haben sie nicht benutzt,
weil es etwas 'komplizierter' aussieht oder, oder oder.

Soll doch jeder nach seiner eigenen Fasson glücklich werden.

Vorteil der Interrupt-Lösung: Man kann nebenher noch was anderes machen
und verpasst doch nichts.
Wenn man aber nichts zu tun hat, dann ist eine Schleifenlösung evtl. einfacher
zu programmieren.

Hermann

Hallo,

Zitat Florian:

Zitat

Passierte aber auch beim Teachen eines Punktes, was doch kein Problem sein sollte.

Beim Teachen eines Punktes wird vom Roboter immer automatisch eine Satzanwahl
gemacht, daher dann auch die selbe Meldung.

Nur sporadisch tritt die Meldung auf, weil es nur passiert, wenn innerhalb einer
logischen Struktur wie switch/case, if then else, while/endwhile ... eine Satzanwahl
stattfindet.

Verhindern lässt sich's nicht, da muss man sich dran gewöhnen und halt wegquittieren.

Hermann

Hallo,
genau das hat RoboBert auch in seinem Post gesagt:
Es gibt immer eine Netzwerkkarte nach aussen, entweder auf dem Motherboard oder bei
den älteren KRC's auf der MFC-Karte.

Hermann

Hallo,
das mit dem endlos Drehen stimmt schon, aber die Sache mit dem faulen Sack bleibt
auch mit der Endlosachse bestehen.

Auch da muss man die Drehung in Abschnitte kleiner 180 Grad aufteilen.
Mir ist da auch noch nichts besseres eingefallen.

Hermann

Hallo,
würde mal in die pfbms.log reinschauen, wenn da kein vernünftiger Hinweis erscheint,
dann eher den Fehler auf der SPS-Seite suchen.
Da werden oft irgend welche falschen Prozesseingangsworte verwendet, oder die
Daten im Zyklus einfach wieder überschrieben ....

In den INI-Dateien sehe ich gerade auch keinen Fehler. In der Slave-Konfiguration
sind die Fehlerquellen ja auch nicht soo gross.

Im Zweifelsfall mal mit einem einzigen Byte probieren.

Hermann

Hallo,
das Gefühl kann da glaube ich recht einfach täuschen.

1. dürften das die max. Geschwindigkeiten sein, die erst nach der Beschleunigungsphase
erreicht werden. Ist der Weg überhaupt lang genug, dass er auf die volle
Geschwindigkeit kommen kann?

2. sind diese alten Monster verglichen mit heutigen Modellen 'gefühlsmässig' deutlich
langsamer.

Hermann

Hallo,
dann versuche ich es etwas ausführlicher:

Es gibt von jedem Roboter zu jedem anderen eine E/A Verbindung

Roboter 1 Ausgang1 Roboter 2 Eingang1 Fertigsignal Teil1
Roboter 1 Ausgang2 Roboter 2 Eingang2 Fertigsignal Teil2
.... usw. je nach dem wieviele Teilabschnitte es gibt

Roboter 1 Ausgang9 Roboter 3 Eingang1 Fertigsignal Teil1
Roboter 1 Ausgang10 Roboter 3 Eingang2 Fertigsignal Teil2
.... usw. je nach dem wieviele Teilabschnitte es gibt

Roboter 2 Ausgang 1 Roboter 1 Eingang9 Fertigsignal Teil1
Roboter 2 Ausgang 2 Roboter 1 Eingang10 Fertigsignal Teil2
.... usw. je nach dem wieviele Teilabschnitte es gibt

Roboter 2 Ausgang 9 Roboter 3 Eingang9 Fertigsignal Teil1
Roboter 2 Ausgang 10 Roboter 3 Eingang10 Fertigsignal Teil2
.... usw. je nach dem wieviele Teilabschnitte es gibt

Roboter 3 Ausgang 1 Roboter 1 Eingang17 Fertigsignal Teil1
Roboter 3 Ausgang 2 Roboter 1 Eingang18 Fertigsignal Teil2
.... usw. je nach dem wieviele Teilabschnitte es gibt

Roboter 3 Ausgang 9 Roboter 2 Eingang17 Fertigsignal Teil1
Roboter 3 Ausgang 10 Roboter 2 Eingang18 Fertigsignal Teil2
.... usw. je nach dem wieviele Teilabschnitte es gibt

Im Zweifelsfall wird das per ganz normalen Dig. E/A's und Drähten bewerkstelligt, die
Nummern der Ausgänge/Eingänge dienen nur als Beispiel und können beliebig geändert werden. Denkbar wäre auch eine Parallelschaltung der Eingänge am Roboter 2 und 3,
die von Roboter 1 kommen, dann hätte man ein paar E/A's gespart, ist aber nicht mehr
ganz so flexibel, von der Programmeirung her.

Alla jetzt:
- Roboter 1 beginnt zu schweissen und setzt Ausgänge 1, 2, 9 und 10 auf false.
- Roboter 2 beginnt zu schweissen und setzt Ausgänge 1, 2, 9 und 10 auf false.
- Roboter 3 beginnt zu schweissen und setzt Ausgänge 1, 2, 9 und 10 auf false.

ist Roboter 1 fertig, so setzt er Ausgang 1 und 9 auf true und wartet bis sein Eingang 9
true ist, dann ist nämlich Roboter 2 fertig mit seinem Teil 1.

ist Roboter 2 fertig, so setzt er Ausgang 1 und 9 auf true, und wartet, bis sein
Eingang 2 true wird (dann ist Roboter 1 mit Teil 2 fertig)

jetzt könnte Roboter 1 mit dem zweiten Teil weitermachen, wofür z.Bsp. Roboter 2 die
Grundlage geschaffen hat. Ist er damit fertig, dann setzt er Ausgang 2 und 10 auf
true. Dann wartet er auf den Eingang 17 (Zustand true), damit weiss er dass
Roboter 3 mit seinem Teil1 fertig ist.

ist Roboter 3 fertig, so setzt er Ausgang 1 und 9 auf true, und wartet, bis seine Eingänge 1,2 und 9 true sind.

Sodele, jetzedle sind alle relevanten Ausgänge/Eingänge auf true und jeder Roboter
weiss, dass alle anderen auch fertig sind. Also kann man beim nächsten Start wieder
von vorne beginnen.

War jetzt nur ein Beispiel, und so dahingeschrieben und evtl. nicht ganz fehlerfrei,
aber das Prinzip sollte doch erkennbar sein.

Zum Busproblem dann evtl. später, das sollte man nämlich gleich mitbestellen,
standardmässig ist da nichts brauchbares am Roboter dabei, diskrete E/A's
übrigens auch nicht.

Zitat

Und was ist mit dem anderen Prob ???

Wie gesagt Schweiss gibt's bei mir höchstens an den Füßen oder in den Achselhöhlen .

Gruss Herman

Hallo,
zum Schweissen kann ich nichts sagen (bei mir schweissen höchstens mal die Füsse )

Die unterschiedlichen Start-/Endezeiten der 3 Roboter bekommt man einfach über eine
'Unterhaltung' der Roboter untereinander hin. Man verbindet alle drei z.Bsp. über einen
Profibus: ein Master zwei Slaves. Und definiert Fertigsignale, die jeweils den anderen Robotern mitteilen, dass ein Teilabschnitt fertig ist.

Kleines Problem ist eigentlich nur dass sich die beiden Slaves nicht direkt miteinander unterhalten können, da muss man am Master dann Eingänge von einem Roboter als
Ausgänge an den anderen (wo sie dann wieder als Eingänge auftauchen) weitergeben,
alles klar?

Die Idee mit der Verweilzeit ist da nicht so besonders, und sollte auf keinen Fall
angewandt werden, da gibt's hundertprozentig jeden Tag Brennersalat.

Hermann

Hallo,
der Stern zwischen den Klammern wird irgendwie als html-kommando interpretiert.
besser man schreibt so was zwischen [ code] [ /code] (jeweils ohne das Leerzeichen.
Oder noch einfacher gleich mit einer Zahl als Beispiel und keinem Stern.

loop
   $out[1] =true
   wait sec 0.4
   $out[1] =false
   wait sec 0.4
  If bedingung == true / false then
    exit
  endif
endloop

Glaube aber nicht, dass es das ist was robocop wollte, denn in der Zeit kann der Roboter ja wohl nichts anderes machen.
Lösungsvorschlag wäre im SPS.sub ein Routine, die über einen Timer alle
0.4 Sekunden einen Ausgang umschaltet.

$timer_stop[1]=false
if $timer[1]>400 then
 $timer[1]=0
 $out[1]=not $out[1]
endif

oder so ähnlich.
Auf keinen Fall die Lösung mit den Wartezeiten im SPS.sub verwenden :evil1:!
Wartezeiten haben da rein gar nichts verloren!

Hermann

Hallo,
das mit der fehlenden Netzwerkbuchse kann ich nicht glauben.
Bei den neuen Steuerungen ist der Netzwerkadapter (wie heute üblich) schon
auf dem Mainboard vorhanden. Evtl. steckt da ein Kabel drin, das geht dann aber
nur runter bis auf das Steckerfeld, kann man rausziehen oder eben unten
anschliessen.

Denkbar wäre nur noch irgend ein Exot: älterer PC-Teil mit neuester MFC-Karte
(ohne Netzwerkadapter), keine Ahnung ob sowas funktioniert und jemals verkauft
wurde .

Diese "shared memory network Karte" ist übrigens keine echte Netzwerkkarte,
das ist nur ein Treiber, der so tut als wäre da eine Netzwerkkarte. Auf der anderen
Seite des 'Kabels', das es gar nicht gibt, ist dann der Treiber im VXWorks-System,
sprich auf Roboterseite, der dort wiederum eine Netzwerkkarte vortäuscht.

Hermann

Hallo,
da hast Du wohl die VxWin RT shared memory Network erwischt.

IP-Adresse muss sein: 192.0.1.2
Subnetmask 255.255.255.0

Seltsamerweise bekommt man immer mal wieder einen Roboter, an dem die echte Netzwerkkarte einfach nicht richtig installiert ist. Muss man dann halt selber nachholen.
Das Problem zieht sich wie ein kleiner roter Faden durch sämtliche Stuerungsgenerationen seit der KRC1.

Hermann

Hallo,
dass ich da nicht auch drauf gekommen bin.
Bei http://www.anybus.com sollte was entsprechendes gefunden werden, da gibts eigentlich fast nichts was es nicht gibt.

EDIT:
Ui, gleichzeitig gepostet. Ja stimmt, CanOpen nur als Slave, schade .

Hermann

Hallo,
will mich da nicht allzu weit aus dem Fenster lehnen, aber denke das wird nicht gehen.

Das mit den gleichen Layern stimmt wohl schon, d.h. man kann die beiden Bussysteme elektrisch miteinander verbinden und es geht nichts kaputt, und evtl. können die sogar ein paar Bytes korrekt miteinander austauschen, aber die höheren Schichten unterscheiden sich dann doch so weit, dass da auf E/A-Ebene nichts mehr gehen wird.

Ist so ähnlich, als wollten sich ein Franzose und ein Engländer unterhalten, bauen auf den selben Layern auf: Lunge, Stimmband, Rachen, Buchstaben aber beim Zusammensetzen der Buchstaben zu sinnvollen Worten hört der Spass auf.

Hermann

Hallo,
ja die Masse scheinen in etwa zu stimmen. Der Sockel scheint mir bei der alten Kiste einiges höher zu sein!

Im Zweifelsfall kann man den Roboter provisorisch anschliessen und ausklappen, aber Vorsicht ohne entprechende Sicherung kippt er dann auf die Schnauze.
Dann ist er zwar um einiges länger, aber garantiert niedriger als 2m.

Hermann

Hallo,
ähm IR760 kenne ich nicht, vielleicht ein Tippfehler?

Eigentlich findet man alle Daten (zumindest der aktuellen Roboter) auf der
Kuka-Homepage :
http://www.kuka-roboter.de

Hermann

Hallo,
die meisten Fehlermeldungen stammen daher, dass in den Maschinenparametern zu viele Achsen eingetragen sind. Auch der Not-Aus Eingang kann daher kommen!

Soweit ich mich noch erinnern kann war das Kommando
DIA MPP
damit kommt man in die Einstellungen der Maschinenparameter.
Dort die Anzahl der Achsen auf 3 stellen. Frag mich nicht nach den genauen Befehlen,
man sollte sich aber mit dem Kommando Hilfe oder war es ? durchhangeln können.

Könnte sein, dass noch mehr Parameter nicht stimmen, wie z.Bsp. Achslängen, Robotertyp usw. das beste wäre du hättest eine Sicherung der Parameter auf Diskette.

Hermann

Hallo,
soweit ich mich noch erinnern kann kommt die Meldung so lange, bis der Leistungsteil eingeschalten ist.
Das muss also nicht unbedingt ein NOT-Aus Taster sein.
Ohne Schaltplan wird das schwierig werden.

Hermann

Hello,
I'm sorry about your trouble with the lack of time.
The reason for not giving the whole source of the project is the copyright.

I did this code for a customer of me, and I am not allowed to give it away.
But I have read some statements that it is possible to use the delphi-code in borland C-builder: Just use the normal installation procedure for components and open the delphi-code instead of the c-code.

May be that you are also a beginner in C (not only in delphi), so (sorry for the clear words) it may be that you have too much work/problems in your current project.
You cannot expect that all your problems will be solved by other people, and i think that you have got enough informations to solve your problem.

In the newer robots there is a possibility to use raw communications on the serial port, so you can use standad serial components. But I am not sure wether this works on the older KRC1 (my own tests someyears ago failed).

In the old robots there is a possibility to communicate with the robot via Crosscommexe, may be this is a solution, but therefore you will need some programming skills in Visual Basic. And the informations about this interface are only very small, so you will have again very much work.

Hermann

Hello,
may be You have done the work on Win98 for the trash.
As I already mentioned (one week ago) in
http://www.roboterforum.de/rob…ic=1939.msg10406#msg10406
there is no easy way to use direct access to hardwareports.
And if you have a look at the source from LindePaul you will see there are statements with direct access to the ports of the serial interface.

So you have to use a program which uses the official API of windows. Otherwise you won't get a stable application.

Hermann

Hello,
one remark: i never use $pro_state. I'm always using $pro_state0 and $pro_state1,
where is one for the main program, and the other for the Submit-interpreter.

The states are (as far as I know)
#p_free, #p_active, #p_stop, #p_reset, #p_end

Hermann