TIA 'Any-Pointer' im DB speichern?

Zuviel Werbung?
-> Hier kostenlos registrieren
In der Jobliste kann man einen "Index" angeben der nach dem Empfang das jeweilige "Parsen" der Daten macht (z.B. switch case)

Was mir wichtig scheint, ist das dies vollsymbolisch bleibt.
Any-Pointer und Peek/Poke sollten der Vergangenheit angehören.
In der Theorie soweit so einfach... Problem ist, dass die Angabe des Zielbereiches in der Jobliste anscheinend nicht symbolisch möglich ist - oder kennt jemand einen Weg?
Alternative: nach dem Empfang noch per switch case für jeden einzelnen Job (jedes einzelne Ziel) eine eigene Kopier-Aktion programmieren.

btw: Any-Pointer und Peek/Poke gehen nur mit nicht "optimierten" Zielbereichen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
In der Theorie soweit so einfach... Problem ist, dass die Angabe des Zielbereiches in der Jobliste anscheinend nicht symbolisch möglich ist - oder kennt jemand einen Weg?
Alternative: nach dem Empfang noch per switch case für jeden einzelnen Job (jedes einzelne Ziel) eine eigene Kopier-Aktion programmieren.

btw: Any-Pointer und Peek/Poke gehen nur mit nicht "optimierten" Zielbereichen.
Ich verwende da
Code:
 #MBVariant := REF("DBData".Struktur1);
 
Ok, wenn ein selbstgeschriebener Baustein universeller oder gar besser als Siemens ist, wie ist da das Problem gelöst:
Wenn man mit einer Jobliste mit mehreren Leseaufträgen verschiedener Register-Bereiche arbeiten will: wie speichert man da am besten die Zieladresse in den einzelnen Jobs? (was die eigentliche Frage hier im Thread ist)

Das ist genau der Punkt. Ich kann mit MB_Client in einem Rutsch max. 125 Register auslesen, ich werde am Ende auf etwa 100 auszulesende 'Blöcke' kommen. Natürlich könnte ich mir auch einen Extra Empfangspuffer schaffen, der löst aber mein Problem nicht.

Was hier wichtig ist: Die Empfangenen Daten sollten immer in einen Empfangs-Puffer geschrieben werden.
Vorteil die "alten" Daten können bis zum Eintreffen weiter verwendet werden (Zugriff auf den Empfangspuffer sind nicht erlaubt während der Übertragung)

Ist der Empfang dann komplett, können die Daten dann in ein Ziel kopiert werden.
Und hier scheint das Problem zu liegen...:

Entweder man baut die Quelle nach: DB-Anlegen mit der selben Struktur und dann mit Deserialize die Daten kopieren
Oder man kopiert das in ein Array (auch mehrdimensional)
In der Jobliste kann man einen "Index" angeben der nach dem Empfang das jeweilige "Parsen" der Daten macht (z.B. switch case)

Auch die Verwendung von Deserialize löst mein Problem nicht, denke ich? In meinem angehängten Bild habe ich mal als Beispiel drei Deserialise-Aufrufe mit verschiedenen Zielbereichen innerhalb meines Empfangs-DB zusammengefügt. Und ich möchte wenn möglich eben genau nicht diesen Baustein (wobei es egal ist ob ich Deserialize oder gleich den MB_Client verwende) 100 mal mit verschiedenen Zieladressen programmieren, sondern möchte diese Zieladresse symbolisch in meiner Joblise speichern und als Variable an den MB_Client(MB_Data_PTR) bzw. Deserialize(DEST_VARIABLE) schreiben.

Was mir wichtig scheint, ist das dies vollsymbolisch bleibt.
Any-Pointer und Peek/Poke sollten der Vergangenheit angehören.
Ja genau. Ich könnte meinen Empfangs-DB nicht optimiert anlegen und dann in meiner Jobliste den Offset speichern, und dann mit nem generierten any-Pointer arbeiten. Aber genau das will ich eigentlich vermeiden.

Gruß Frank


MB_4.pngMB_5.pngMB_6.png
 
Zuletzt bearbeitet:
Aus den 1en Breitrag wurde es beschrieben wie sämtliche Daten für alle Datensätze auf einmal gelesen werden sollte.
Dies weil eine Schleife beschriben wurde, und das Problem war halt 'nur' wie man die Daten mittels ein Index in das Ziel-Bereich kopieren konnte.

Hantiert die Server die Verteilung, Priorizierung usw. von die Produktionsaufträge ?
Die Maschine soll die Aufträge ausführen ?
Wenn ja, dann ist etwas falsch mit den ganzen Idée, alle Aufträge auf Einmal von die Server holen.
Ich hätte gerne eine Beschreibung von die eigentliche Aufgabe.
 
Aus den 1en Breitrag wurde es beschrieben wie sämtliche Daten für alle Datensätze auf einmal gelesen werden sollte.
Dies weil eine Schleife beschriben wurde, und das Problem war halt 'nur' wie man die Daten mittels ein Index in das Ziel-Bereich kopieren konnte.

Hantiert die Server die Verteilung, Priorizierung usw. von die Produktionsaufträge ?
Die Maschine soll die Aufträge ausführen ?
Wenn ja, dann ist etwas falsch mit den ganzen Idée, alle Aufträge auf Einmal von die Server holen.
Ich hätte gerne eine Beschreibung von die eigentliche Aufgabe.
Der MB-Server ist eine optische Sortierung, die (in diesem Fall) Kartoffeln prüft und fehlerbehaftete Kartoffeln (grüne, fleckige oder faule Kartoffeln oder Fremdkörper) aus dem Produktstrom ausschleust. Und als 'Nebeneffekt' erstellt die Maschine Statistiken über Größenverteilungen, Fehler, Farben usw. Die SPS soll diese statistischen Daten abrufen (nicht zeitkritisch), ggfs kombinieren, und dann dem Lieferanten bzw. dem Auftrag zugeordnet ans ERP übertragen. Es werden keine Aufträge zwischen der opt. Sortierung und der SPS ausgetauscht.

Gruß Frank
 
Zuviel Werbung?
-> Hier kostenlos registrieren
OK, ich habe das Wort 'Jobliste' interpretiert als dass die Server eine Liste von Arbeits-Aufträge an eine Maschine sendet. Das war also falsch.
Und die 'Server' ist kein Datenbank o.Ä, es ist nur 'Server' in das es Modbus TCP Server ist.

Um jetzt viele (auch strukturell verschiedene) Datensätze abholen zu können
Wie du es in den letzten Beitrag beschreibst, denke ich dass die Struktur fest ist, oder ?

Ich wurde trotzdem erwarten dass die optische Sortierung pro beendete 'Auftrag' das Ergebnis an die 'Statistik'-SPS sendet. Die SPS plaziert dann diese Werte in ein FIFO Puffer. Die Statistik kann dann auf die FIFO Puffer gemacht werden.
Nicht dass die 'Statistik'-SPS eine totalisierte Liste von beendete Aufträge holt.
 
Zuletzt bearbeitet:
In der "Jobliste" sind die Modbus-Leseaufträge abgelegt, die das Programm nacheinander immer wieder ausführen soll. Weil nicht alle interessierenden Variablen/Register in einem Auftrag am Stück gelesen werden können.

PS: oder wenn man mehrere Modbus-Teilnehmer nacheinander abfragen will, dann ist so eine Jobliste ungemein sinnvoll. Allerdings sind da alle Träume von symbolischer Adressierung der Zieladressen fruchtlos. Das geht nur mit POKE oder POINTER oder halt für jede Zieladresse eine eigene Anweisung.
 
Zuletzt bearbeitet:
Was ich da auch schon Stunden, Nächte, Wochen damit verbracht habe...
Auch auf die Gefahr hin, das meine Meinung auf widerstand stößt: Ich habs aufgegeben.
Weder mit der 1500er Modbus-Baugruppe, noch mit diesem Steck-Teil von der 1200er.. Alles Mist und viel zu kompliziert und fehleranfällig.

AMSAMotion PN1-MB ist meine Lösung.
Direkt über die GSDM-Datei als PN-Device einbindbar und übernimmt den ganzen quatsch. Du greiftst dann nur auf die E/A-Adressen zu.
1773174761933.png

Ob das was für jeden ist? Sicher nicht.. Schont es Nerven? auf jeden fall! (mindestens meine)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bevor das hier nun komplett ins OT abdriftet, so habe ich es jetzt gelöst:
- Den DB nicht optimiert
- In der Jobliste nur die MB-Adresse und Länge
- einen extra Empfangspuffer verwendet
- einen FC geschrieben an den ich immer 10 Ziele aus meinem Empfangs-DB symbolisch angeben kann, Verteilung dann über den Umlauf-Index und BLKMOV

Nicht ganz so wie ich es mir gewünscht hätte, aber so bleibt es nun erst einmal.

MB_7.pngMB_8.pngMB_9.pngMB_10.png
 
Und, selbst wenn man in KOP oder FUP programmiert, dann kann man einzelne SCL Zeilen einfügen.
Für genau solchen Zweck sehr nutzlich.
Also braucht man nicht unbedingt ein separaten SCL Baustein für die 'Verteiler'.

Du kannst vermutlich einen 1-Zeiler in diesen Stil programmieren:
"EB_EF_Tomra5a".Kriterium[#i] := "DB_EF_Tomra5A".Empfangspuffer ;
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Du kannst vermutlich einen 1-Zeiler in diesen Stil programmieren:
"EB_EF_Tomra5a".Kriterium[#i] := "DB_EF_Tomra5A".Empfangspuffer ;
Dann müsste er alle Modbus-Empfangsziele/Variablen in dieses Array Kriterium[] legen. Und alle Variablen-Structs müssten die selbe Größe und Aufbau haben.
 
Dann müsste er alle Modbus-Empfangsziele/Variablen in dieses Array Kriterium[] legen. Und alle Variablen-Structs müssten die selbe Größe und Aufbau haben.
Ja, wie er es in Beitrag #28 beschrieben hat, glaube ich es ist tatsächlich so.

Ich habe gefragt, aber kein Anwort bekommen.
Wie du es in den letzten Beitrag beschreibst, denke ich dass die Struktur fest ist, oder ?
 
Zurück
Oben