Funktion "RIGHT" setzt CPU in STOPP

Zuviel Werbung?
-> Hier kostenlos registrieren
Ok

Sorry, das war wohl noch die alte version, in der neuen hatte ich zu testzwecken schon einfach anstelle des dint_to_string bausteins einfach ein 'test' eingetragen und es funktionierte trotzdem nicht.
Und in Seriennummer_gesamt steht auch das richtige drin
 
Zuletzt bearbeitet:
Es ist für einen aussen-stehenden etwas schwierig ...

Was steht in "Maschinendaten".Vorzeichenposition für ein Wert ? Die richtige Position des "+" oder irgendein Quatsch ?
Wenn hier etwas unsinniges drin steht - versuch doch mal statt '+' einen tempString mit '+' als Inhalt zu übergeben ...

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ok

Da steht die richtige Position des Zeichens "+" drin. habe ich schon kontrolliert.
Finde es halt komisch, dass ich entweder die DELETE Funktion benutzen kann, oder die darauf folgende concat funktion, das ist doch schon irgendwie komisch, oder?
 
OK ... bleiben wir mal bei der letzten Aussage von dir.
Was liefert denn DELETE zurück - hast du dir das mal angesehen ?
Wenn du DELETE asukommentiert hast und dann den CONCAT mit einer manuell beschriebenen "Maschinendaten".Seriennummer_gesamt versorgst - dann geht es und es steht das Richtige drin ?
Hast du die Länge der Strings mal kontrolliert. Sind die ggf. von der Definition her begrenzt ? Oder wenn nicht - hast du mal versucht, sie zu verkleinern weil du ja sowieso keinen STRING[254] brauchst ?

Mehr fällt mir dazu sonst nicht ein.
 
O

Es funktioniert entweder DELETE, oder CONCAT, und es steht in beiden Fällen das richtige drin. werde noch verrückt ;-)
 
Ok

Die Stringlängen passen alle und sind lang genug. habe sie schon soweit gekürzt, dass sie nicht allzu lang, jedoch immer noch lang genug sind.

Die Strings sind global in einem DB angelegt
 
Ichhab mit mal den Fehler angesehen, der OB 88 soll da wohl aufgerufen werden. In der Hilfe zum OB 88 steht Folgendes:

Code:
Beschreibung

Das Betriebssystem der CPU ruft den OB 88 auf, wenn die Bearbeitung eines Programmbausteins abgebrochen wird. Beispiele für mögliche Abbruchursachen sind:

·	Zu große Schachtelungstiefe bei Synchronfehlern

·	Zu große Schachtelungstiefe von Bausteinaufrufen (U-Stack)

·	Fehler beim Allokieren von Lokaldaten

Wenn Sie den OB 88 nicht programmiert haben und ein Bearbeitungsabbruch tritt auf, geht die CPU in den Betriebszustand STOP (Ereignis W#16#4570).

Wenn der Bearbeitungsabbruch in der Prioritätsklasse 28 auftritt, geht die CPU in STOP.

Sie können den Bearbeitungsabbruch-OB mit Hilfe der SFCs 39 bis 42 sperren bzw. verzögern und wieder freigeben.

Vielleicht liegt ja der Fehler an ganz anderer Stelle!
Prüfe doch mal die Schachtelungstiefe und den Verbrauch des Lokaldatenstack. beim Umgang mit Strings ist da ganz schnell die arg limitierte Grenze erreicht, das hatte ich bereits bei einigen Programmen, in denen mehrere Strings bearbeitet/verkettet werden sollten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ah klingt ganz plausibel

Hey, das klingt zumindest nach einer logischen Erklärung. Leider weis ich nicht genau, was du damit meinst. also warum zu tief verschachtelt? --> beide Bausteine funktionieren alleine einwandfrei.


was das andere mit dem Stack angeht... ---> wie genau ist das gemeint, bzw. was schlägst du vor?
 
an der Lokaldaten-Geschichte hatte ich ja auch ein bißchen herum-laboriert.
Deswegen ja auch die Frage :
Wo sind die Strings deklariert ? TEMP und somit Lokal oder STAT ?
Du schreibst darauf als Antwort "in einem DB". Versuch doch mal die ganzen Strings in der Instanz deines Bausteins zu halten und schließlich nur das Ergebnis herauszugeben.
Ich werde das aber gleich auch mal selber checken ...
 
Hallo Benson,
ich habe das jetzt mal nachgestellt mit einem FB und alle die Strings im STAT-Bereich angelegt. Dann geht es.
Stell doch mal dein Projekt oder jedenfalls den relevanten Ausschnitt davon hier ein.

Gruß
Larry
 
Hey, das klingt zumindest nach einer logischen Erklärung. Leider weis ich nicht genau, was du damit meinst. also warum zu tief verschachtelt? --> beide Bausteine funktionieren alleine einwandfrei.


was das andere mit dem Stack angeht... ---> wie genau ist das gemeint, bzw. was schlägst du vor?

Prüfe einmal den Baustein, in welchem dein "Problem-FB" aufgerufen wird auf die Größe der Lokaldaten. (Und auch deinen FB selbst)
Dazu mit der rechten Maustaste auf den Baustein klicken, "Objekteigenschaften" und dann den 2.Reiter "Allgemein - Teil 2" anklicken. Wieviel Lokaldatenbyte werden dort angezeigt? Bei mit war es ein FC, der viele Strings als Input und Output hatte. Intern wurden diese String einfach nur vom Input auf den Output kopiert, dadurch konnte ich im Programm beliebige Strings in einen DB kopieren und verschicken. Der Lokaldatenverbrauch war "riesig", 472 Byte. Bei einer Speed7, die ja wie eine 318 konfiguriert wird, konnte ich den Stack vergrößern, bei einer 314, für eine kleine Maschine mußte ich jeden String einzeln umkopieren, da der Stack fest und mit 256 Byte zu klein war.

Das ist nur ein Beispiel für Probleme mit den Lokaldaten, es gibt noch mehr Fallen. Aber dazu müßte man mal deinen Baustein sehen.
 
Zurück
Oben