Beiträge von BBS_Le

Lies lieber ab Seite 9 deines Anhangs; dort ist's m.E. gut dargestellt. Beachte den Fingerzeig und besorge dir die Klemmen-PDFs.

Und: vielleicht solltest du wirklich lieber neu aufsetzen - wie WolfHenk schon angesprochen

Zitat von X197

Die Kommunikation funktioniert und ich kann die IO schon "ansteuern".
z.b. Bei $OUT [1]=TRUE -> 1.Ausgang der 2.Klemme geht an. (WIESO BEI DER 2.? )

Guck dir die Beschreibung deiner Phoenix-Klemme an und du wirst entdecken, dass die nicht "der Reihe nach" beschaltet sind. Es ist in der Tat ein wenig irritierend... wenn man es aber weiß, ist's schließlich easy.

Klingt fast so, als hätte sich die Hintergrundbeleuchtung von deinem KCP verabschiedet. Mit einer starken Taschenlampe könntest du erkennen ob das Panel noch arbeitet. Die CCFL-Beleuchtung lässt sich relativ einfach durch LED-Stripes ersetzen.

Also, die Festplatte mit den Werkseinstellungen läuft einwandfrei. Der Fehler entstand somit durch irgendeine nachträgliche Konfiguration. Ich werde nunmehr aber lieber nicht das gesamte Archiv zurücksichern, sondern lieber die Peripherie einzeln - mit Zwischenprüfung. Wir haben leider das volle Programm laufen (DeviceNet, Profibus, Interbus usw.)...
Vielleicht stoße ich ja so auf die Ursache

Besten Dank an SJX und Gruß
ToM

Ok, das werde ich morgen zuallererst ausprobieren und dann berichten.

Ok, das klingt ja dann so, dass ich mich mal an die Hardware machen muss. Gibt es einen genaueren Schaltplan bzw. ist es möglich, das "Pufferung Stop-Signal" abzufragen bzw. gibt es einen Messpunkt?
Beim eigentlichen Pufferungsende ist kurz ein Klicken eines Relais zu hören; dies sollte dann wahrscheinlich die Pufferung beenden (gefühlt, die 210 Sekunden danach )...
Das Zeitfenster des Erscheinens des Klickens ist jedoch sehr kurz, sodass ich bisher nicht lokalisieren konnte, wo es "klick" macht.
Elektrotechnisch sind wir gut versorgt - auch mit diversen Ersatz-Platinen von der Steuerung - bis hin zum Mess-Equipment. Nur, ich wollte das bloße Tauschen auf Verdacht gerne umgehen und lieber verstehen. Deine Anmerkungen dazu sind jedenfalls schon einmal recht hilfreich.

1-4 habe ich schon durchgeführt. Ich werde morgen mal eine zweite Festplatte einbauen. Auf dieser ist die Original KSS drauf und noch keine weiteren Änderungen (Auslieferungszustand).

Gut wäre allerdings, wenn ich das Signal konkret lokalisieren könnte und dann erst einmal feststellen könnte, ob es überhaupt ausgelöst wird...

Besten Dank vorerst

Beste Grüße Tom

Ein Hallo an die Fachleute hier im Forum

wir sind eine kleine berufsbildende Schule und haben hier einen KR30 mit einer KRC1-Steuerung (SW. V__41_0317_1_HF1) für die Ausbildung stehen.

Seit kurzem schaltet sich der Computer nach dem Ausschalten am Steuerschrank-Hauptschalter nicht mehr vollständig aus.
Der Computer speichert nach dem Abschalten ordnungsgemäß die Roboterdaten zurück und verliert auch keine seiner (Positions-)Daten) bis zum nächsten Einschalten. Jedoch kommt dann der Hinweis, dass Win95 ausgeschaltet werden kann, startet den Rechner erneut und bootet das System - diesmal natürlich alles über die eingebauten Akkus... Die Akkus sind neu und voll.
Ich kann nicht ausschließen, dass einer meiner Kollegen etwas an der Software, im BIOS oder an Windows95 verstellt hat... finde aber selber nichts.

In der Autoexec.bat wurde nichts verstellt:

REM KUKA Setup* do not modify or remove this section
AKKUOFF -N
WIN
SMARTDRV /C
AKKUOFF /DD000
REM KUKA Setup+ do not add any lines after this section

Warnmeldungen bekomme ich auch keine angezeigt - lediglich die Info (blaues "i") "Unterspannung PM1" beim Abschalten am Hauptschalter.
Das manuelle Beenden von Cross3 und dem Beenden von Win95 geht natürlich noch - nur war es schöner, wenn der Steuerschrank von "alleine" stromlos wird. Die Akkus würden sich zwangsläufig im Nu leer ziehen, wenn es beim Ausschalten keiner bemerkt...

Was kann das sein?

Beste Grüße

Die solltest du im eingeschalteten Zustand entnehmen und wechseln. Somit bleiben die BIOS-Einträge erhalten und resetten nicht automatisch.
Beste Grüße
ToM

Ahh, ganz lieben Dank dafür! Naja, die englischsprachige Ausgabe kommt in den nächsten Jahren sicherlich auch noch verstärkt zum Einsatz...
Beste Grüße Sven

Hallo liebes Forum,
kann uns (Berufsschule in privater Trägerschaft) einer mit einer in Deutsch abgefassten Version des "Reference Guide 4.1" weiterhelfen? Wir haben leider nur eine englische Ausgabe... und dies wird allzuoft von meinen Schülern nicht richtig interpretiert bzw. eher ignoriert... Ich möchte nun möglichst nicht die Defizite meiner (Enlisch-)Kollegen kompensieren, sondern vielmehr effizient kreative Programmierkenntnisse in die Praxis überführen.

Ganz lieben Dank im Voraus
Sven

Ok, danke für den Hinweis. Ich habe es geschafft!
Die Meldung ist weg und es funktioniert! Habe im im 25poligen Stecker den Master mit dem Slave (IN) verbunden und bin mit Slave (Out) dann zum nächsten (eigentlich ersten) Teilnehmer gegangen. Dann eine neue *.svc-Datei generiert und im Ergebnis war die Fehlermeldung weg
Beste Grüße
Sven

hm, hört sich gut an, das mit der internen Lösung... Didaktisch auf jeden Fall "sauberer" als eine Fehlermeldung!
Werde ich dafür den Bus des Slaves entsprechend verdrahten müssen oder geht das intern (Software-Konfiguration)? Ansonsten müsste ich ja wohl vom Master in den Slave der Karte und dann weiter zum entfernt stehenden Schaltschrank gehen..? Im 25poligen Stecker wäre dann Platz für die Brücken Master->Slave...
Momentan sind wir mit dem 25poligen Anschluss der IBS-Karte direkt zum Bussknoten (nur Master-Remote; also 4 Pin) gegangen.

@ Hermann: Natürlich, du hast Recht! Ich habe das mit der Profibus-Karte verwechselt. Habe es schlichweg verwechselt! Sorry! Der Profibus - mit der CP5614 - läuft einwandfrei, genauso das DeviceNet. Die Treiber habe ich schon auskommentiert und zwar die, die da nun stehen und auch funktionieren.
Die ibus.log zeigt keinen Fehler (habe es verglichen mit der Kuka-Anleitung) und der Interbus arbeitet auch mit den angeschlossenen Teilnehmern. Es ist "lediglich" dieser angezeigte Fehler... Im Schulungsbetrieb ist das ziemlich nervig, da selbst mir als Lehrer dazu eine plausieble Antwort fehlt
@ Pred0509: Das ist ja mal eine Aussage! Also bin ich wohl gezwungen, unsere S7 mit einzubinden, damit der Text verschwindet... Ziemlich unbefriedigend! Nein, wir verwenden alle zur Verfügung stehenden Bus-Varianten; eben zur Demonstration.
Ich bedanke mich schon einmal bei euch beiden, wenngleich ich noch hoffe, dass mir jemand um die Ecke kommt und verrät, wie die blöde Meldung auch anderweitig weggeht.
Beste Grüße
Sven

tja, danke, das haben wir bereits versucht. Auch nichts

Hallo, wir haben in unserer Ausbildungswerkstatt (Berufsschule) einen KR30 mit einer KRC1-Steuerung (V4.1.7 SPO8 HF1) am Laufen. Nun möchten wir gerne die Profibus-Karte 5614 daran betreiben. Über die Phoenix-App "IBS CMD" haben wir eine *.svc_Datei erstellt und über diese auch erfolgreich die E/A- Baugruppen
1x Bussknoten ST24
1x DI 16x
1x DO 16x und
1x AO 4x
zum Start bewegen können - zumindest über den digitalen Prozessmonitor der Phoenix-Software.Der Roboter soll als Master und NUR als Master (eingebaut ist ja eine Master/Slave-Karte) laufen.Allerdings bekommen wir beim Hochfahren der KRC folgende Meldung: Interbus: Busfehler im Slavekreis (1617).Wie können wir den Slave derart deaktivieren (oder die Meldung), dass das System fehlerfrei hochfährt?Ich hänge mal die Auszüge zur Interbus.ini und der iosys.ini mit dran.
Wäre großartig, wenn uns da von euch Profis einer weiterhelfen kann
Beste Grüße und Dank voraus!
Sven

[CONFIG]
VERSION=2.00
[DRIVERS]
MFC=0,mfcEntry,mfcdrv.o
INTERBUS=1,ibusInit,ibusdrv.o
DEVNET=2,dnInit,dndrv.o
PBMASL=11,pbmsInit,pfbmsdrv.o
[MFC]
INW0=0 ;$IN[1-16]
OUTW0=0 ;$OUT[1-16]
OUTW2=2 ;$OUT[17-32]

[INTERBUS]
;------- Inputs ------------------
INW10=0 ;$IN[81-96]
;------- Outputs -----------------
OUTW10=0 ;$OUT[81-96]
;------- Analog Outputs ----------
ANOUT1=2,12,0 ;$ANOUT[1]
ANOUT2=4,12,0 ;$ANOUT[2]
ANOUT3=6,12,0 ;$ANOUT[3]
ANOUT4=8,12,0 ;$ANOUT[4]

;------- Slave Inputs ------------
;INW50=896 ;$IN[401-416]
;INW52=898 ;$IN[417-432]
;INW54=900 ;$IN[433-448]
;INW56=902 ;$IN[449-464]
;------- Slave Outputs -----------
;OUTW50=896 ;$OUT[401-416]
;OUTW52=898 ;$OUT[417-432]
;OUTW54=900 ;$OUT[433-448]
;OUTW56=902 ;$OUT[449-464]

[DEVNET]
;INW64=5,0,x2 ;$IN[513-544]
ANOUT5=5,0,12,0 ;$ANOUT[5] .....
----------------------------------------------------------------
; Konfiguration INTERBUS: Wildenburg 31.05.96 RE-SG

[INTERBUS]

IO_ADDR=0X390
BOARDNUMBER=1
MEMBASE=0XD400
CARD_IRQ=0

[SLAVE]
ID=0403 ;SlaveID HEX

[CONFIGURATION]
;WATCHDOG 1=enable
;WATCHDOG 0=disable
WATCHDOG=1
;MASTERRING=0 Mastering not used (no I-Bus modules connected); just Slave operation
; Bus will not be started; Slave use possible
;MASTERRING=1 Mastering used (I-Bus modules connected)
MASTERRING=1
;Report a local master error to a Robot BIT == $OUT[x]
;x must be mapped to the I-Bus slave (see IOSYS.INI)
;e.g. : LOCALMASTERNOTOK=401 : Master Error ist reportet to $OUT[401]
;Attention could overwrite a security output (check twice)!!
;LOCALMASTEROK=401

;New LOCALMASTEROK Bit. The value of the variable is the bit position of the LOCALMASTEROK bit
; in the slave output memory. The adress of the slave output memory must be start at 896.
;NEWLOCALMASTEROK=1

;Name of Logfile
IBLOGFILE=log\ibus.log

;SWAP_SL_BYTES=1 : Swap (exchange low and high byte of a 16-bit word) Bytes of a Salveword
;SWAP_SL_BYTES=0 : Bytes of a Salveword are not swapped
SWAP_SL_BYTES=0

;CONTINUE_WITH_WARNING=1; if a buswarning (device state has changed) is received the bus keeps operable
;CONTINUE_WITH_WARNING=0; if a buswarning is received the bus is not usable any more by the RC
CONTINUE_WITH_WARNING=1

;if robot inputs ($IN[]) shall be updated even during a bus failure, activate the option PASSIVE_UPDATE
;below. If this option is set to 1 the robot inputs are read from the interbus card even if the driver
;detects a bus failure; this is especially interesting for the onboard slave inputs or the diagnostic status
;information (see section DIAGNOSTIC_REGISTERS) which are not affected by a bus failure of the master ring;
;so inputs, which are coming from the PLC via the onboard slave, can be processed even during a bus failure.
;Of course, inputs which are affected by a bus failure, as all the inputs of the local master, will stay
;in the state they had before the bus failure.
;If this option is set to 0 or is commented and a bus failure occures, all inputs (also the onboard slave
;inputs) keep the state they had before the failure.
;All outputs are allways set to 0 in case of a bus failure (also the onboard slave outputs)
;This option works only with a driver version 1.06 or greater (see driver version in iosys.log).
;PASSIVE_UPDATE=1

; the cycle time of the interbus task can be changed over this entry. The value corresponds to 1/100 seconds.
;IBSTASK_CYCLE_TIME = 100

;this value is only available with the newlocalmasterok bit
;ON_ERR_CLEAR_MPM_OUT=1 => when driver is in error state mpm output area is set to zero
;ON_ERR_CLEAR_MPM_OUT=0 => when driver is in error state mpm output area is not set to zero
;ON_ERR_CLEAR_MPM_OUT=0

[CMD_CONFIGURATION]
;if you want to use CMD directly on the KR C1 via a serial link, only a baudrate of 1200 Baud
;is possible; to tell the Interbus master to communicate with this baudrate, activate the
;option below. This baudrate has to correspond with the baudrate CMD itself is using; it can
;be adjusted in the file "IBDDIWIN.INI" which can be found in the windows directory;
;change the option "[IBS3964R_COM1/2]->Baudrate" (1/2 depending on the serial link you are
;using : COM1 or COM2 ) to the appropriate baudrate (BAUDRATE=1200)
;BAUDRATE=1200

;Configuration file made with Phoenix CMD; if used, some options are
;disabled/not used (SlaveID,MASTERRING)
CMD_FILE=init\vielossa.svc

;EXTERN_START=1 BUS will be started via CMD
;EXTERN_START=0 BUS will be started by the robot controller
EXTERN_START=0

[DIAGNOSTIC_REGISTERS]
;STATUS=n : Byte Address in the Mulitport Memory (of the IBS-Card) of the Master's
; Status-Register. Can be displayed in the input image of the robot controler.
; e.g.: STATUS=600; IOSYS.INI : INW10=600 => $IN[81-96] represents the
; status register of the IBS-Master
;PARAMETER=n : Byte Address in the Mulitport Memory (of the IBS-Card) of the Master's
; Parameter-Register. Can be displayed in the input image of the robot controler.
;STATUS=600
;PARAMETER=602

[TASK]
;AUTOSTART=time : peroid time in seconds after which a bus restart is periodicaly retried
; (after a bus error)
;if time < 8 : period time of 8 seconds is used
;if time = 0 : no automatical restart is performed
;AUTORESTART=1

[NAMES]
;Syntax :
;Nn=S.T:Name
;n:Continous Number 1..32
;S:IBUS-Segment Number
;T:IBUS-Participant Number
;Name:Symbolic Name of Participant
;max 60 Enties will be read !
;each entry must have 18 characters at max
;------123456789012345678
N1=1.0:BK Serverschrank
N2=1.1:Digital-Ausgabe
N3=1.2:Digital-Eingabe
N4=1.3:Analog-Ausgabe
;N5=1.4:Fibrotor 1
;N6=1.5:Fibrotor 2

[END SECTION]

wie Bert schon richtig schreibt: Deine Festplatte ist das Hauptproblem! Da nützen keine Abschaltungen von Lüftern - sondern vielmehr ein temperaturgeregeltes Klima im Inneren des Schrankes.
Auch gibt es für die Festplatten selbst solche temperaturgeregelten Heizungen; es sind (vielmehr) Heizfolien, die man problemlos - mit 12 V betrieben (aus dem HDD-Anschluss) - in den vorhandenen Rahmen unterbringen kann. Panasonic stattet z.B. damit seine Toughbooks aus
Die Schrankheizelemente von Rittal sind zwar ganz nett, allerdings im Dauereinsatz recht unökonomisch, da eigentlich nur die HDD Probleme macht.

Gruß
Sven

Hi Woodworker,

ich kann dir zwar nicht helfen, finde nur, dass diese Frage es rechtfertigt, dass sie hier noch einmal (indirekt) aufgegriffen wird... vielleicht war einfach nur das lange Wochenende "schuld" daran

Also, auch ich würde gerne wissen wollen, was da los sein kann. Kann soetwas passieren, wenn ich am Systemtakt (Prozessorgeschwindigkeit; overclocking) herumbaddle?

Grüße
Sven

Also, das kann man so wirklich nicht stehen lassen
Das Zitat stammt inmitten aus einem PC-Welt-Artikel, dessen Qualitat zudem stark anzuzweifeln bzw. dem der BILD gleichzusetzen gilt...
Die Zeiten der speicherbedingten Ausfälle - wie sie bei CF-Karten immer noch vorkommen - sind schon längst vorbei!
Lest bitte einfach mal bei Wiki nach; dort sind auch seriösere Quellen angegeben...

http://de.wikipedia.org/wiki/Solid-State-Drive

In modernen IPC (Industrierechnern) werden fast ausnahmslos SSD verbaut; natürlich keine No-Name-Produkte...

Dass deine ( echo) SSD abgeraucht ist, ist zwar ärgerlich, jedoch "normal" und könnte genausogut mit einer konventionellen (billigen?!) Festplatte passieren.
Wir haben schon seit einigen Jahren auf SSD umgestellt. Also, bitte keine Panikmache!

Sven

ich möchte sie nicht mehr missen.
Einmal richtig eingewiesen (und eingestellt!), dann geht es schneller und effizienter als per Taste.

@Roland56: Mit Verlaub, aber auch hier bitte keine Unwahrheiten verbreiten

Windows95 wurde am 27. August 1997 (Buildnr. 4.03.1212) mit USB-Unterstützung ausgeliefert - nicht erst ab Win98.
PS/2-Schnittstellen wurden mit Einführung der ATX-PCs vermehrt verbaut - was ja nicht ausschließt, dass es bei SOHO zeitnah geschehen sein muss - wenngleich die letzten KRC1-Boards mit Celeron (433Mhz) ausgestattet waren und das Bios bereits USB-Optionen anbot... Ok, darum ging es aber auch wohl nicht wirklich...

SOHO, als damaliger OEM-Lieferant der Motherboards, verwendete keine speziellen IRQ-Tabellen. Zu der Zeit gab es zwar einige Wildwüchse, was Interruptvektoren angeht. Beste Beispiel sind hierfür die "reservierten" IRQs 10-12; die wurden immer wieder für alles Mögliche hin- und hergebogen (SK, NWK, SCSI, VGA, IDE, PCI).

Beim IBM-Kompatiblen SOHO-Board entspricht jedoch die Vektortabelle die des IBM-PC/AT.
Schaut man mal in's Bios des KRC1-Rechners, wird man feststellen, dass die 2. HDD lediglich nicht aktiviert ist, die IRQ jedoch bei 15 liegt und nicht anderweitig belegt/genutzt wird. Ich weiß, dass das ein Unterfangen ist, die zweite HDD zum Laufen zu bewegen - aber es geht! Von der MFC wird sie jedenfalls nicht verwendet. Überhaupt: ein Blick ins Bios lohnt sich: Es sind keine aussergewöhnlichen Einstellungen zu erkennen. Kuka hat zwar im Bios einige Merkmale eingebettet (Default, Logo etc.) - jedoch nichts umverlegt oder gar permanet deaktiviert. Ein Blick in die "PNP/PCI Configuration" zeigt, dass alles auf Standard/Auto steht. Der Interupthandler für VXWorks greift naturgemäß auch nur auf unbelegten IRQs zurück - warum sollte sich die MFC in Konfliktzonen begeben? Dass die KRC-Software nicht ohne MFC funktioniert, hat ja nun nichts allgemein mit den IRQs zu tun - wenngleich die MFC HW-Interrupts an den Prozessor meldet. Also, insgesamt kein Grund, dem verbauten IPC übermässig Respekt zu zollen; es ist kein Hexenwerk! Die haben auch alle nur mit Wasser gekocht. Wäre dies Tierchen nicht schon so alt (und so groß), könnte man daraus glatt einen Bürocomputer machen

woodworker: Jupp, probier mal

LG Sven