Beiträge von rob

Für mich ist es einfach sehr schwierig abzuschätzen, ab wann Grobfahrlässigkeit vorliegt. Unser Paletteneinschub ist nur 500 mm hoch, 600 breit und der Tunnel ist einen Meter lang und braucht eine Absicherung. Ein Durchkriechen ist meiner Meinung nach aber keine 'vernünftigerweise vorhersehbare Fehlbedienung' nach Maschinenrichtlinie - genausowenig wie das Übersteigen des Tischs beim KUKA-Bild.

Gruss, Rob

Vielen Dank für die Antworten. Die Lichtschranke scheint mir die bessere Lösung zu sein, nicht nur weil die Sicherheits-SPS entfällt. Die Rollenschalter haben zum Beispiel das Problem, dass sie bei Löchern in den unteren Palettenbrettern einen Not-Aus auslösen und die mechanische Stabilität nicht sehr zufriedenstellend ist, sie verbiegen sich oft (immer zugunsten der Sicherheit).

ASI verwenden wir noch nicht, ist aber immer ein Thema. Noch ist alles sternförmig hart verkabelt auf die Sicherheits-SPS (Jokab Pluto), der Rest ist Profibus.

Bei den Bildern von Kuka habe ich einfach das Problem, dass der Bediener ohne grosse Anstrengung drübersteigen kann. Dann ist er in der Anlage und nicht mehr auf der Fussmatte.

Gruss, Rob

Hallo

Ich habe eine Frage zur Handhabung der Sicherheit bei Paletteneinschüben. Wir haben die Anlage 'iso.jpg' schon mehrfach gebaut. Die Palettenein- und Ausgabe ist mit einem Gittertunnel 'top.jpg' überdeckt, der das Durchsteigen erschwert. Von den Abmessungen her wäre es möglich, im Betrieb durch diesen Tunnel zu kriechen 'pal_1.jpg'.

Die aktuelle Sicherheit ist recht aufwändig gelöst 'pal_2.jpg'. Die Rollenschalter (1) muten die Lichtschranke (2). Die Sicherheits-SPS ist so programmiert, dass nachdem die Palette die Rollenschalter verlässt, die Lichtschranke noch eine gewisse Zeit unscharf bleibt, so dass die Palette noch durchfahren kann.

Die Lichtschranke (3) ist immer scharf.

Wie soll ich diesen Palettendurchgang mit der KR C4 am sinnvollsten angehen? Brauche ich eine Sicherheits-SPS, oder ist das übertrieben? Multiprog steht nicht zur Verfügung, wir setzen auf CoDeSys.

Wenn ich die KUKA-Handbücher anschaue, sehe ich immer solche Handeingaben 'kuka_safety.png' (©KUKA) die wesentlich einfacher zu überwinden sind. Ist das in dieser Form verantwortbar?

Vielen Dank für die Inputs.

OK, danke für die Inputs. Es scheint sich bei den verschiedenen Robotern um verschiedene Probleme zu handeln. Bei einem wurde mal das Shuttle HOT-579 Mainboard durch ein SOYO SY-7IZB+N ersetzt (KUKA Austausch-PC), dort ist zwar der IRQ frei, aber der I/O-Bereich durch 'unbekannte Geräte' besetzt. Dort wo noch das Originalboard drinnen ist, ist der IRQ und der I/O-Bereich frei, allerdings hab ich dort einen 'E/A-Read Data-Anschluss für ISA-Plug&Play-Enum' , welchen es auf den Originalinstallationen nicht gibt.

Sternchen habe ich bei den Ressourcen keine gesehen (was würde das bedeuten?). Auswählen kann ich dort zwischen 10 und 11.

Netzwerkkarten sind überall nur die zwei (RTACC und SMC) aufgeführt.

Ich kann die Sache allerdings erst am Montag weiterverfolgen, da die Produktion läuft, melde mich aber sicher wieder, da ich nun einige Anhaltspunkte habe. Nochmal danke für die Inputs

Gruss, Rob

Moin

Die Tech Notes befinden sich auf der ersten Installations-CD unter 'GERMAN/TechNotes', hab die besagte TN2 angehängt.

Ich werde es bei der nächsten Installation auch mal ohne das Tool probieren.

Das Problem ist, dass ich den richtigen IRQ im Netzwerkmenu gar nicht einstellen kann, mit der Meldung, dass ein Konflikt vorliegt, kann aber im Gerätemanager nichts finden, was diesen IRQ schon belegen würde. Die einzige zusätzliche Hardware ist die ProFiBus Masterkarte IM180/181, welche aber als Option schon mit dem KUKA ausgeliefert wurde.

Gruss Rob

Hallo

Ich habe drei ältere KUKAs neu aufgesetzt und kann die in der Tech Note 2 angegebenen Werte nicht einstellen. Installiert habe ich folgendermassen:

- format c: / d:
- Win95 installieren nach Tech Note 1
- Installation Shared Memory nach Tech Note 6
- Installation KUKA Software 2.2.8 Patch f:
-- Setup.exe
-- KRCPatch
-- swpatch nach beiliegender Anleitung
-- mdpatch nach beiliegender Anleitung
- Installation LAN Controller nach Tech Note 2

Mit dem Tool ezstart.exe (DOS-Modus) ist es mir nicht möglich IRQ 11 und I/O Base 340 einzustellen. Stattdessen werden IRQ 10 und I/O Base 220 gewählt. Probiere ich 11 und 340 über Custum Setup, weigert sich das Tool mit einem IRQ Konflikt.

Es ist möglich, die angegebenen Werte im Gerätemanager einzustellen, dann allerdings fährt die KUKA Software nicht mehr hoch. Mit 10/220 -> kein Problem.

Das eigentliche Problem ist, dass bei zwei KUKAs alles inklusive Netzwerk tadellos funktioniert, auch mit dem falschen IRQ / I/O Base, der dritte sich aber weigert irgendwelche Netzwerkaktivitäten durchzuführen. Auch beim Dritten ging das Netz nach der Neuinstallation, aber seit einem Neustart kann ich nichtmal mehr rein- oder rauspingen.

-> Ist es ein Problem, wenn IRQ und I/O Base nicht der Anleitung entspricht? Beziehungsweise wie kriege ich die richtigen Werte gesetzt? Ist meine Installationsreihenfolge falsch? (Die drei verbleibenden, baugleichen Roboter, welche noch in der Ur-Installation laufen, haben die korrekten Werte.)

-> Woran könnte es liegen, dass sich der Dritte weigert zu pingen? Switch / Kabel sind in Ordnung, IP / Subnetmaske stimmt auch, die Netzwerkkarte zeigt keinen Konflikt im Gerätemanager. Ich habe seit dem Funktionieren des Netzes lediglich neu gestartet und nacher, als es nicht mehr ging, Kabel und Switch getestet.

Vielen Dank für eure Hilfe

Naja, es handelt sich um 12 Jahre alte Krücken. Welcher logische Fehler könnte denn einen "halt" auslösen? Also nicht einen "stop" mit in die Bremsen fallen, sondern so als würde man im Programm "HALT" schreiben.

Hab auch nichts geändert an der Logik, ausser den SWITCH zu ersetzten. Kann man eigentlich nicht viel falsch machen.

Wie auch immer, das Problem war reproduzierbar auf 5 Robotern mit 2.2.8 und 3.2.24

Mit >=5.2ern hatte ich das nie, da laufen auch SWITCHs mit Schnittstellen. Allerdings kann ich dort den Problemswitch nicht testen, weil das ganz andere Anlagen sind...

Das Problem ist gelöst. Die Moral lautet:

Lange Schrittketten im sps.sub, die auf SWITCHs aufbauen sind böse:

SWITCH step
  CASE 10
    ;blah
    (IF fertig -> step = 20)
  CASE 20
    ;zeugs
    (IF fertig -> step = 30)
  [...]
  CASE 100
    ;toll, fertig
    (IF fertig -> step = 10)
ENDSWITCH

Anstatt dessen sind IFs zu verwenden ELSE IF vermeiden!

IF step = 10 THEN
  ;blah
  (IF fertig -> step = 20)
ENDIF
IF step = 20 THEN
  ;zeugs
  (IF fertig -> step = 30)
ENDIF
[...]
IF step = 100 THEN
  ;toll, fertig
  (IF fertig -> step = 10)
ENDIF

Ich vermute dass der Interpreter bei einem SWITCH oder ELSE IF (das Zweite hab ich gar nicht erst probiert weil die Vermutung nahe liegt, dass das Gleiche passiert...) die ganze Struktur laden muss, und dass das das sps.sub nicht verkraftet.

Nach dem Umbau der Schrittkette in pure IF THEN ENDIFs läuft die Sache tadellos. Schon seit zwei Wochen jetzt.

Nochmal, das bezieht sich nur aufs sps.sub.

cheers o/

Hallo, ich hab ein komisches Problem. Folgendes Szenario:

Wir haben einen KR6 Jahrgang 1999 mit KRC1 V2.2.8. Der lief bis jetzt ohne unlösbare Probleme. Der Roboter läuft ohne externe SPS im AUT Modus. Die "interne SPS" i.e. das sps.sub steuert die ganze Anlage. Das ist nicht viel, es hat knapp 400 Zeilen, bei der letzten Erweiterung sind etwa 70 Zeilen dazugekommen.

Der Roboter bleibt nun häufig stehen. Manchmal passiert das mehrmals pro Stunde. Nicht so, als ob jemand den Bedienerschutz öffnet, sondern wie bei einem "halt" (Submit und Interpreter bleiben grün, Run wird rot). Ein Drücken auf "start" lässt den Kuka weiterlaufen, als wäre nichts gewesen.

Das passiert immer nur dann, wenn der Roboter auf eine Variable BOHREN == FALSE wartet, während dem das sps.sub die Bohrmaschine steuert, deutlich bevor das Bohren abgeschlossen und die Variable vom sps.sub auf FALSE gesetzt wird.

Im sps.sub habe ich natürlich keine "halt" oder "wait (for)" programmiert. Ist alles schön zyklisch. Im wartenden Programm ist auch kein "halt" drinnen. Nur der WAIT FOR BOHREN == FALSE, in welchen der Kuka stehen bleibt.

Ist mein sps.sub zu lang geworden? Ist da irgend ein watchdog versteckt eingebaut? Kann ich mir eigentlich nicht vorstellen. Normalerweise läuft das sps.sub einfach länger, wenn mehr drinnen ist...

Falls jemand eine Idee hat, wie ich das angehen könnte -> Bin für jede Hilfe dankbar

Gruss, rob

PS: Es passiert nun auch an einer anderen Stelle. Dort in einem WAIT SEC 2 (nicht im sps) während im sps.sub ein Timer für ein Entmagnetisiergerät läuft. Aber auch hier in einem WAIT und ohne Roboterbewegung...

Zitat von LindePaul

Das "HALT-Verhalten" ist in jeder Betriebsart gleich. Die Funktion eject_it( )
wird definitiv durchlaufen ? Bleibt der Interpreter woanders stehen ?Bitte kontrolliere noch, ob die SPS nicht pausenlos Startimpulse gibt !
Wird das entsprechende Programm über CWRITE im SPS.SUB immer wieder gestartet ?

Ja, die Funktion durchläuft er immer. Ich werde das Programm im Handbetrieb testen, um zu sehen, ob die SPS Startimpulse sendet (ich vermute, dass diese im Handbetrieb ausgeblendet werden). Auf der Anzeige sehe ich Keine, sind wohl zu kurz für den LCD

Das SPS.SUB ist sauber.

Danke für die Tipps, ich melde mich wieder

ah danke, das werd' ich gleich mal prüfen. Dummerweise ist der SPS-Programmierer in den Skiferien. Falls es so ist, werd' ich mir anders behelfen müssen

moin

Ist das normal, das in der Betriebsart AUT EXT die HALTs ignoriert werden?

DEFFCT BOOL eject_it( )


  WAIT FOR i_EJE_free


  $TOOL = TOOL_DATA[gnToolGrpA]
  $BASE = BASE_DATA[gnBaseEject]


  PTP{a1 -86.3,a2 -118.2,a3 132.9,a4 57.7,a5 -25.3,a6 35.2}C_PTP
  PTP over_away C_PTP
  PTP over


  set_force( 250 )
  BAS( #VEL_CP, 0.1 )
  LIN station


  $ADVANCE=0
    PULSE( o_GRP_A_open, TRUE, PULSE_TIME )
    await( "i_GRP_A_opened", TRUE, GRIPPER_TIME, E_CANT_OPEN_GRIPPER_A, #PERSIST )
  $ADVANCE=3


  set_force( 500 )


  BAS( #VEL_CP, 0.5 )
  LIN over


  PTP over_away C_PTP
  PTP{a1 -86.3,a2 -118.2,a3 132.9,a4 57.7,a5 -25.3,a6 35.2}C_PTP
  PTP{a1 -90,a2 -130,a3 135,a4 0,a5 35,a6 90}


  ;===============================================
   HALT; Bitte mit gruenem Plus (links) starten :)
  ;===============================================
 
  RETURN TRUE
ENDFCT

(Das ist nicht das ganze src, nur die eine Funktion da drinnen, falls das relevant ist...)

Der läuft mir immer weiter an der markierten Stelle. Lässt sich das HALT-Verhalten irgendwo einstellen?
SW ist 5.2.x

Besten Dank im Voraus, Gruss.

Hallo, ich hab wieder ein Problem mit dem Ethernet KRLXML Modul.

Ich habe eine Sendestruktur definiert:

<sql>
 <mc>32</mc>
 <mr>8</mr>
 <ms>80</ms>
 <s></s>
 <t></t>
</sql>

Im Programm probiere ich mit dem Befehl

EKX_handleerror( EKX_WriteString( "sensor.sql.s", "zu sendender Text" ) )
EKX_handleerror( EKX_Send( "sensor" ) )

einen Text zu senden. Ist dieser nun
- bis zu 58 Zeichen lang, klappt dies einwandfrei. Ist er
- 59 oder 60 Zeichen lang, kommt der Fehler "1429 Zeichenkette zu lang". Ist er
- länger als 60 Zeichen, so kommt kein Fehler mehr, allerdings wird auch nichts gesendet.

Ist diese Länge irgendwo konfigurierbar? Für den Empfang klappt das ja auch mit bis zu 80 Zeichen und eine sql query kann schnell mal lang werden...

Ach ja, ich habe den gleichen Effekt, wenn ich "handleerror" mit "errint" aufrufe, so wie im Beispiel. Das ändert leider nichts.

Vielen Dank für die Hilfe, Gruss, Rob

Achtung!

Kleiner Nachtrag: Die dritte Version oben ohne dummy[] kürzt den empfangenen String auf 64 Zeichen. Mit der Zweiten Version klappt's auch mit 80 ...naaaja. seltsam.

Im ersten Wurf hab ich's so probiert:

bNew = STRCOPY( dummy[], rectext[5].s[] )
         errbl = EKX_GetStringElement(0, dummy[], bNew)
         IF errbl == FALSE THEN
            HALT
         ENDIF

Der Effekt war, dass dummy[] mindestens 21 Zeichen lang war, was der Länge von rectext[5].s[] entspricht. Kürzere Strings wurden auf 21 Zeichen verlängert, längere blieben länger. Beim Zurückkopieren in mein Feld, wurden dann die trailing spaces abgeschnitten, so wäre die Funktion schon zu gebrauchen gewesen:

bNew = STRCOPY( dummy[], rectext[5].s[] )
         errbl = EKX_GetStringElement(0, dummy[], bNew)
         IF errbl == FALSE THEN
            HALT
         ENDIF
         bNew = STRCOPY( result[i,j].s[], dummy[] )

...es geht allerdings auch ohne dummy[] mit dem Feld direkt. Dazu muss es lediglich nach dem Empfang in sich selbst kopiert werden. Denke mal dass STRCOPY() einfach alles hinter \n abschneidet:

bNew = STRCOPY( result[i,j].s[], rectext[5].s[] )
         errbl = EKX_GetStringElement(0, result[i,j].s[], bNew)
         IF errbl == FALSE THEN
            HALT
         ENDIF
         bNew = STRCOPY( result[i,j].s[], result[i,j].s[] )

Hab nochmal ein Problem mit dem XML-TechPack: Alle KUKA-seitig empfangenen Strings werden auf eine Länge von 5 Zeichen gekürzt oder auch verlängert, falls sie kürzer sind. Kann man das irgendwo einstellen?

Die Strings, welche ich der EKX_GetStringElement( ... , hier , ... ) übergebe sind mit 81 Zeichen deklariert (wie im mitgelieferten Beispiel):

STRUC str char s[81]
DECL str result[8,32]

Die Stacksizes der Empfangsstruktur habe ich auf 1024 vergrössert, was natürlich keinen Einfluss darauf hat. Auch hier ist der Empfangsstring, dem Beispiel folgend, mit einer Länge von 80 deklariert:

<Elements>
  <Element Tag="SQL" Type="STRUCTTAG" Stacksize="1024" />
   <Element Tag="SQL.CR" Type="INTEGER" Stacksize="1024" />	
   <Element Tag="SQL.CC" Type="INTEGER" Stacksize="1024" />	
   <Element Tag="SQL.MR" Type="INTEGER" Stacksize="1024" />	
   <Element Tag="SQL.MC" Type="INTEGER" Stacksize="1024" />	
   <Element Tag="SQL.SD" Type="STRING" Size="80" Stacksize="1024" />
</Elements>

Schicke ich nun "12" so empfange ich "12 " mit 3 Leerzeichen. "123456" wird gekürzt auf "12345".

Hat jemand eine Idee was ich falsch mache?

Und noch eine kleine Frage: Gibt es neben dem KRLXML eine einfachere Möglichkeit, über Ports zu kommunizieren? Ich kann mich mit diesem Paket nicht so recht anfreunden.

Es funktioniert jetzt so halbwegs. Hab aber keine Ahnung warum sry.

Ja, der DemoServer funktioniert in Werkskonfiguration. In beide Richtungen.

Sobald ich aber "Use own Data" mit eigenen files probiere geht fast nichts mehr. Die KRC Data werden erst empfangen, wenn ich das (mein eigenes von oben) src abwähle oder zurücksetze (die xml files vom Server hab ich angepasst, dabei konnte ich mir nicht ausmalen, wozu das Krcdata.xml gut sein soll. Die Daten kommen ja sowieso vom Roboter...). Interessanterweise klappt das (KRC->Server) aber gut mit meinem Java Server. KRC-seitiges Empfangen geht mit beiden nicht (obwohl WireShark und HyperTerminal was Anderes behaupten ).

Dann hab ich noch einen VB Server probiert (6 nicht .net). Auch dieser empfängt nichts. Das geht bis jetzt nur mit dem Java Server.

Vielen Dank für den Tip
Werde erst Donnerstag wieder hier 'reinschauen können.

Hallo

Ich probiere mit KUKA.EthernetKRLXML über einen java socket server Abfragen auf eine Datenbank zu machen. Um das im Vorfeld zu testen, hab ich einen kleinen java server geschrieben, der einfach mal empfangen und senden soll.

Aus KUKA sicht klappt das Senden, empfangen kann ich aber nicht.

Wie im C# Beispiel von KUKA konvertiere ich den zu sendenden String erst in einen Byte Array.

Die Konsolenausgabe im Eclipse ist:

received: <mc>32</mc><mr>8</mr><ms>80</ms><s>select * from TJobData</s><t/>
sending: <sql><cr>1</cr><cc>1</cc><mr>1</mr><mc>1</mc><sd>blah</sd></sql>

...allerdings bleibt der KUKA in der Funktion: EKX_WaitForSensorData( ... ) stehen, beziehungsweise im "HALT" danach. Der KUKA wartet nicht auf das Timeout (10s) sondern fällt in den "HALT", nachdem der java server gesendet hat (nach der einen Sekunde Verweilzeit).

Ich habe probiert:
- ohne / mit der einen Sekunde Verweilzeit im java server
- ohne / mit input.close() / output.close() / output.flush() im java server
- mit newlines im zu sendenden String (zwischen den tags und am Schluss)

Da der KUKA den timeout nicht abwartet gehe ich davon aus, dass etwas ankommt, denn ohne die Verweilzeit im java server wartet er die vollen 10 Sekunden ab.

Falls ich mich mit HyperTerminal mit dem java server verbinde, bekomme ich den korrekten String

Falls sich jemand mit diesem TP auskennt, wäre für jede Hilfe dankbar.

Gruss, rob

Der Java Server:

package sql4automation;


import java.net.*;
import java.io.*;


public class Server {
	ServerSocket server = new ServerSocket( 11006 );
	Server() throws IOException{
		while( true ){
			Socket client = server.accept();
			InputStream input = client.getInputStream();
			OutputStream output = client.getOutputStream();

			StringBuilder sb = new StringBuilder();
			while( input.available()>0 ){
				sb.append( (char)input.read() );
			}

			System.out.print( "received: " + sb.toString() );
			System.out.flush();

			long time = System.currentTimeMillis() + 1000;
			while( time > System.currentTimeMillis() );

			String out = "<sql><cr>1</cr><cc>1</cc><mr>1</mr><mc>1</mc><sd>blah</sd></sql>";
			System.out.println( "\nsending: " + out );
			byte[] outbyte = out.getBytes();
			output.write( outbyte, 0, outbyte.length );
			output.flush();

			input.close();
			output.close();
		}
	}
	public static void main(String[] args) {
		try{
			Server server = new Server();
		}catch( IOException e ){
			System.out.println( "Error: " + e );
		}
	}
}

Das KRL source file:

DEF sql4automation2( )


;==============
; declarations
;==============
timeout = 10000; ms


query[1].s[] = "<mc>32</mc>"
query[2].s[] = "<mr>8</mr>"
query[3].s[] = "<ms>80</ms>"
query[4].s[] = "<s>"
query[5].s[] = " "
query[6].s[] = "</s>"
query[7].s[] = "<t/>"


res[1].s[] = "sql4automation2.sql.cr"
res[2].s[] = "sql4automation2.sql.cc"
res[3].s[] = "sql4automation2.sql.mr"
res[4].s[] = "sql4automation2.sql.mc"
res[5].s[] = "sql4automation2.sql.sd"
res[6].s[] = "sql4automation2.sql"


target[] = "sql4automation2"


;test = TRUE
test = FALSE
query[5].s[] = "select * from TJobData"


;==================
; open the channel
;==================
nError = EKX_open( target[] )
EKX_handleerror( nError )


;===============
; data exchange
;===============
;WHILE test
WHILE TRUE


;===========
; send data
;===========
FOR i=1 TO 3
 nError = EKX_write( target[], query[i].s[] )
 IF nError == eioc_error THEN
  HALT
 ENDIF
ENDFOR


FOR i=4 TO 6
 nError = EKX_write( target[], query[i].s[] )
 IF nError == eioc_error THEN
  HALT
 ENDIF
ENDFOR


nError = EKX_write( target[], query[7].s[] )
IF nError == eioc_error THEN
 HALT
ENDIF


IF test THEN
 HALT
ENDIF


;==============
; receive data
;==============


IF NOT EKX_WaitForSensorData( 0, res[6].s[], timeout ) THEN
 HALT ; *** hier bleibt er stehen ohne den timeout abzuwarten... ***
ENDIF


IF NOT EKX_GetIntegerElement( 0, res[1].s[], cr, bNew ) THEN
 HALT
ENDIF


IF NOT EKX_GetIntegerElement( 0, res[2].s[], cc, bNew ) THEN
 HALT
ENDIF


IF NOT EKX_GetIntegerElement( 0, res[3].s[], mr, bNew ) THEN
 HALT
ENDIF


IF NOT EKX_GetIntegerElement( 0, res[4].s[], mc, bNew ) THEN
 HALT
ENDIF


IF( (cr<>mr) OR (cc<>mc) ) THEN
 HALT
ENDIF


sd = res[5]
bNew = TRUE
FOR r=1 TO mr
 FOR c = 1 TO mc
  IF NOT bNew THEN
   HALT; WRONG COUNTERS !
  ENDIF
  IF NOT EKX_GetStringElement( 0, sd.s[], bNew ) THEN
   HALT
  ENDIF
  WHILE NOT StrClear( result[r,c].s[] )
   ; this should never happen...
  ENDWHILE
  sdlen = StrLen( sd.s[] )
  FOR i=1 TO sdlen
   result[r,c].s[i] = sd.s[i]
  ENDFOR; copy
 ENDFOR; columns
ENDFOR ; rows


IF test THEN
 HALT
ENDIF


ENDWHILE; test


;======================
; close the connection
;======================
IF NOT EKX_close( target[] ) THEN
 HALT
ENDIF


END

das dat:

DEFDAT sql4automation


CHAR target[40]


STRUC str CHAR s[81]


CONST INT query_size = 5
DECL str query[5]


CONST INT res_size = 2
DECL str res[2]
DECL str result


BOOL bNew
INT  timeout
INT  nError


INT i
BOOL test


ENDDAT

und die entsprechende Emfangsstruktur:

<Elements>
 <Element Tag="sql" Type="STRUCTTAG" Stacksize="5" />
 <Element Tag="sql.cr" Type="INTEGER" Stacksize="5" />
 <Element Tag="sql.cc" Type="INTEGER" Stacksize="5" />
 <Element Tag="sql.mr" Type="INTEGER" Stacksize="5" />
 <Element Tag="sql.mc" Type="INTEGER" Stacksize="5" />
 <Element Tag="sql.sd" Type="STRING" Size="80" Stacksize="5" />
</Elements>

moin moin

Ja, $ABS_ACCUR war auf true, trotzdem, danke für den Hinweis.

Die Lösung war das Eingeben der richtigen Seriennummer keine Ahnung woher die falsche, 9-stellige Nummer kam...

Gruss