TwinCat Load Symbol Data @camper

[camper]

Version? TC31-Full-Setup.3.1.4020.39.zip bei mir

[booster]

Na dann ist meine neuer: 3.1.4022.16
??

[camper]

nvm. sehe gerade, dass ich auch Build 4022 habe, hatte die Datei nur verschoben.
Evtl. funktionieren ja inplace Updates nicht so gut - also mal mit Deinstallation (schauen, dass die Verzeichnisse auch verschwinden) und dann Neuinstallation versuchen?

[booster]

Evtl. funktionieren ja inplace Updates nicht so gut

An dem scheint es gelegen zu haben.

[booster]

Funktioniert das ganze eigentlich auch noch für TwinCat2

[booster]

Und noch einen Kompilierungsfehler:

'adsData::datatypeInfo *const ': unknown size

adsdata.h(102): note: see reference to class template instantiation 'std::vector<adsData::datatypeInfo,std::allocator<_Ty>>' being compiled

[camper]

booster schrieb:

Und noch einen Kompilierungsfehler:

'adsData::datatypeInfo *const ': unknown size

adsdata.h(102): note: see reference to class template instantiation 'std::vector<adsData::datatypeInfo,std::allocator<_Ty>>' being compiled

Ich habe keine Ahnung, in welcher Weise du meinen Code verändert hast.
Die Zeilenangabe passt schon mal nicht. Allerdings ist das einzige in adsdata.h, dass mit datatypeInfo zu tun hat, die deklaration des privaten members types_
Was ich nicht weiss, ist wo der Fehler auftritt.
note: ist keine Fehlermeldung
Bei einem Fehler steht immer error: da
Note ist bloss eine Erläuterung in Ergänzung

Da du umformatiert hast, wirst du zur Fehlermeldung immer auch das zugehörige Stück Code posten müssen, damit ich zuordnen kann.

[booster]

Ja ok ich habe folgendes geändert:

Ich habe das Laden der Symbole aus dem Konstruktor raus genommen.
Weil ich die Verbindung zur SPS in einer anderen Klasse mache.

Dafür habe ich einmal einen Standardkonstruktor
und einen der die vectoren für syData und dtData übernimmt.

explicit adsData() = default;

adsData::adsData(const std::vector<char>& symData, const std::vector<char>& dtData)
{
    initialize(symData, dtData);
}

[camper]

explicit adsData() = default;

Das ist dein Problem. Die implizite Instantiierung dieses Konstruktors instantiiert den Defaultkonstruktor von vector, was nur geht, wenn der Elementtyp vollständig definiert ist.
Aus diesem Grund muss auch die Definition des Defaultkonstruktors in adsdata.cpp erfolgen - wie auch schon für Destruktor, Movekonstruktor und Move-Assignment op von adsData.

Sauberer wäre nebenbei, einen Konstruktor, zu haben, der dieselben Parameter wie initialize nimmt. Vom Defaultkonstruktor halte ich nichts. Mit diesem hindert dich nichts, initialize mehrfach aufzurufen. initialize räumt aber nicht zunächst auf (weil es nur bei Objektkonstruktion aufgerufen werden soll).
Falls du irgendwann später mal Datenn neuladen willst, kann das immer noch geschehen: einfach ein neues adsData-Objekt erzeugen und dem anderen Move-Zuweisen.

[booster]

Achso. Wieder was gelernt.

Tu mir ehrlich gesagt noch schwer den ganzen Code zu verstehen.

Auch mein Resharper hat noch Schwierigkeiten mit dem Code
Der zeigt mir noch ziemlich viele Fehler an.

Aber kompilieren tut es jetzt.

Zum Speicherverbrauch kann ich noch nichts sagen. Aber der Code ist nun um einiges komplexer geworden.

Oftopic: Gibts eigentlich gute Schulungen die einem c++ und im speziellen die Neuerungen von c++ 11 bis c++17 vorstellen.

[booster]

Nochmals zur Ordnerstruktur von ADS. Hierzu habe ich mit Beckhoff Rücksprache gehalten.

Hier wurde mitgeteit das die Dateien im Verzeichnis:

C:\TwinCAT\3.1\sdk\Include

nur für interne Zwecke vorgesehen sind.

Bitte nehmen Sie nur die Dateien aus den AdsApi Ordner!

Also diesem hier.

C:\TwinCAT\AdsApi\TcAdsDll\Include

Ich weiß jetzt nicht inwiefern das sich nun mit deinem Code verträgt. Ich sollte es aber tunlichst vermeiden irgendwas zu verwenden das von unserem SPS lieferanten nicht unterstützt wird.

[camper]

booster schrieb:

Zum Speicherverbrauch kann ich noch nichts sagen.

Sicher etwas größer als in meinem ursprünglichen Code, weil die Daten nicht mehr in der kompakten Form gehalten werden, in der sie vom Netzwerk kommen. Andererseits werden keine Duplikate erstellt, so dass der Speicherverbrauch der gesamten Datenstruktur nur linear von der Größe der Netzwerkdaten abhängt. Ein davongallopieren des Verbrauchs wie zuvor ist ausgeschlossen.

booster schrieb:

Aber der Code ist nun um einiges komplexer geworden.

Dafür kann er auch mehr

Irgendetwas habe ich beim Experimentieren kaputtgemacht. Egal wie mein POU aussieht, ich erhalte keine Daten mehr darüber, bloss die paar Systemvariablen, die immer da sind. Irgendeine Idee dazu?

booster schrieb:

Oftopic: Gibts eigentlich gute Schulungen die einem c++ und im speziellen die Neuerungen von c++ 11 bis c++17 vorstellen.

Wenn du jetzt noch nach C++11 fragen musst, wären eher ein paar Bücher angesagt. Die Antwort dazu überlasse ich mal Anderen, die einen besseren Überblick über die aktuelle Literatur haben.

[camper]

booster schrieb:

Hier wurde mitgeteit das die Dateien im Verzeichnis:

C:\TwinCAT\3.1\sdk\Include

nur für interne Zwecke vorgesehen sind.

Bitte nehmen Sie nur die Dateien aus den AdsApi Ordner!

C:\TwinCAT\AdsApi\TcAdsDll\Include

Wenn diese Dateien gepflegt und intern konsistent wären, wäre das ja auch kein Problem.

Beispiel:

TcAdsDef.h schrieb:

typedef struct
{
	ADS_UINT32		entryLength;	// length of complete datatype entry
...
	// GUID			typeGuid;		// typeGuid of this type if ADSDATATYPEFLAG_TYPEGUID is set
	// ADS_UINT8	copyMask[];		// "size" bytes containing 0xff or 0x00 - 0x00 means ignore byte (ADSIGRP_SYM_VALBYHND_WITHMASK)
} AdsDatatypeEntry, *PAdsDatatypeEntry, **PPAdsDatatypeEntry;

Schön und gut. Nur dass ADSDATATYPEFLAG_TYPEGUID eben nirgends definiert ist, wie auch ADSIGRP_SYM_VALBYHND_WITHMASK.

Die Sachen in <ads.h> an denen wir interessiert sind, sind ausschliesslich diese Stukturdefinitionen und die zugehörigen Konstanten.

[booster]

Wenn du jetzt noch nach C++11 fragen musst,

Wie meinst das?

Denke die meisten Änderungen sind eher bei c++ 17 angesiedelt. Oder?
Desweiteren bewege ich mich die meiste Zeit in c#. Und darf gerade halt de alten c++ code auf vorderman bringen.

Weiß jetzt nicht ob die ganze komplexität des Programmes hier wegen des Technologiesprungs zu c++17 zu finden ist. Es ist halt eine ganz andere vorgehensweise die ich sonst kenne.

Egal wie mein POU aussieht, ich erhalte keine Daten mehr darüber, bloss die paar Systemvariablen, die immer da sind. Irgendeine Idee dazu?

Wo erhälst du keine Informationen mehr darüber? Aus deiner Schnittstelle.

Teste mal vieleicht das Beispielprogramm von Beckhoff in .Net. Das listet einem die Informationen der Symbole auch auf.

https://infosys.beckhoff.com/content/1031/tcsample_net/html/twincat.ads.sample06.htm?id=7147847683939335804

[booster]

Die Sachen in <ads.h> an denen wir interessiert sind, sind ausschliesslich diese Stukturdefinitionen und die zugehörigen Konstanten.

Die Frage ist warum sind "wir" daran interessiert. Ich hatte ja bisher die benötigten Informationen auch erhalten die ich benötigt hatte.

Kann jetzt nicht sagen für was du ADSDATATYPEFLAG_TYPEGUID oder ADSIGRP_SYM_VALBYHND_WITHMASK benötigst. Oder auch die ganzen anderen Dinge.

Ich glaube dir das dein Code viel mehr kann. Nur die Frage ist ob ich das benötige. Und bin ich kompatibel zu TwinCat2 und den zukünftig folgenden Versionen.

Ich muss den Code hier nachher selber warten, und wenn ich nun meine eigene Wege ohne Beckhoff gehe bekomme ich von denen auch keinen Support mehr.

[camper]

booster schrieb:

Die Sachen in <ads.h> an denen wir interessiert sind, sind ausschliesslich diese Stukturdefinitionen und die zugehörigen Konstanten.

Die Frage ist warum sind "wir" daran interessiert. Ich hatte ja bisher die benötigten Informationen auch erhalten die ich benötigt hatte.

Und woher weisst du dass du die richtigen Informationen (und nicht nur irgendwelche zufälligen Daten) erhalten hast? Das geht nur auf einem Weg: indem die Implemention mit der Spezifikation abgleichst (d.h. dass was im Header oder irgendeiner anderen Dokumentation dazu gelieferten wird) abgeglichen wird.

Aber diese Spezifikation, wie sie geliefert wird, ist eben offenbar fehlerhaft.

booster schrieb:

Und bin ich kompatibel zu TwinCat2 und den zukünftig folgenden Versionen.

Das hängt eben auch nur davon ab, ob das, was du geliefert bekommst, inkompatible Änderungen enthält. In dem Fall hast du verloren, egal was du machst: wenn du solchen Änderungen nicht folgst, funktioniert das Programm mit neuen Versionen nicht mehr, wenn du ihnen folgst, läuft es eben nicht mehr mit alten Versionen.

Betrachte zum Beispiel das hier:

#define	ADSDATATYPEFLAG_BITVALUES		0x00000020	// size and offs are in bits instead of bytes AND iGroup of main symbol incremented by 1!

Das ist eine inkompatible Änderung des Protokolls, weil hier die Interpretation von Datenfeldern, die bereits eine wohldefinierte Bedeutung haben, geändert werden muss. Gleichzeitig wurde darauf verzichtet, diese Änderung in irgendeiner Form (wozu gibt es schließlich das version-Feld) kenntlich zu machen. Ein Programm, dass dieses Flag nicht kennt, wird mit Daten, die in dieser Form geliefert werden, Unfug anstellen.
Umgekehrt hat ein Programm, dass dieses Flag kennt, kein Problem mit Daten, die dieses nicht enthalten, bleibt also zu alten Versionen kompatibel.
Wenn ich mich also auf TcAdsDef.h - wie sie jetzt ist - beschränke, dann ist die Frage, ob der Code mit der aktuellen TwinCAT-Version kompatibel ist, ein einfaches nein. Es ist schlicht unmöglich, kompatibel zu programmieren, ohne diese Änderungen zu kennen.

[camper]

booster schrieb:

Wo erhälst du keine Informationen mehr darüber? Aus deiner Schnittstelle.

Nein, es werden schlicht keine Information dazu geliefert.
Mit deinem kleinen

PROGRAM MAIN
VAR
    myInt:INT:=10;
END_VAR

gibt es kein Main.myInt mehr in den Daten (und ich kriege immer noch ganz normal Daten, mit all dem vordefinierten Zeug, dass immer da ist), die ich über das Netzwerk erhalte. Ich werde aber umgekehrt jedesmal beim Login gefragt, ob ich hochladen will, an fehlender Synchronisation kann es also nicht liegen.

[booster]

Nein, es werden schlicht keine Information dazu geliefert.

Das ist ja genau die Frage. Wo werden keine Informationen mehr geliefert.
Über die Ads c++ Schnittstelle?
Darum die Frage was liefert die .Net Schnittstelle?

Und woher weisst du dass du die richtigen Informationen (und nicht nur irgendwelche zufälligen Daten) erhalten hast?

Na weil ich mir ja anschauen und vergleichem kann was in TwinCat definiert ist und das nachher über die Schnittstelle geliefert wird. Und das hat bisher gepasst.

Und wenn es nicht passt. Rufe ich Beckhoff an und sage da passt was nicht

Das geht nur auf einem Weg: indem die Implemention mit der Spezifikation abgleichst

Welche Implementation. Die von Beckhoff?

Das ist eine inkompatible Änderung des Protokolls, weil hier die Interpretation von Datenfeldern, die bereits eine wohldefinierte Bedeutung haben, geändert werden muss.

Ich versteh nur Bahnhoff.

ref_property<datatype_entry_prop::hasBitValues, flag< AdsDatatypeEntry, datatype_entry_prop::flags, ADSDATATYPEFLAG_BITVALUES>>,

Das ist die einzige Stelle bei der du das Symbol verwendest. Und ehrlich gesagt habe ich Null Ahnung was du da überhaupt machst.

[booster]

Also in der Mail von Beckhoff wird erklärt dass die Kommunikation intern zwischen den verschiedenen Modulen innerhalb von TwinCat auch auf die AdsKommunikation setzen. Hier bei kann es allerdings vorkommen dass die einzelnen Module verschiedene Versionen der AdsSchnittstelle benötigen. Darum kann es vorkommen das in den verschiedenen Headern Symbole mehrfach vorkommen aber anders definiert sind.

Die AdsSchnittstelle für externe Anwendungen basiert aber auf der im AdsApi Ordner und diese Schnittstelle ist für TwinCat2 so wie TwinCat3 gleich.

Heißt für mich ich muss diese auf jeden Fall einsetzen dass ich kompatibel zu beiden Systemen bin und weiterhin Support erhalte.

[camper]

booster schrieb:

Nein, es werden schlicht keine Information dazu geliefert.

Das ist ja genau die Frage. Wo werden keine Informationen mehr geliefert.
Über die Ads c++ Schnittstelle?
Darum die Frage was liefert die .Net Schnittstelle?

Ah, jetzt verstehe ich die Frage. Sorry, war etwas verwirrt.
...
testing
...
Nope, die gesuchte Variable ist wirklich nicht da

booster schrieb:

Und woher weisst du dass du die richtigen Informationen (und nicht nur irgendwelche zufälligen Daten) erhalten hast?

Na weil ich mir ja anschauen und vergleichem kann was in TwinCat definiert ist und das nachher über die Schnittstelle geliefert wird. Und das hat bisher gepasst.

Aha. Und du bist natürlich in der Lage, jeden möglichen Fall vorher zu testen und nicht verantwortlich, wenn später etwas schief geht, weil du etwas nicht bedacht hast. Weil nicht sein kann, was nicht sein darf Womit ich nicht sagen will, dass man Fehler komplett ausschliessen kann. Andereseits ersetzt aber Testen nicht eigenes Denken.

booster schrieb:

Das geht nur auf einem Weg: indem die Implemention mit der Spezifikation abgleichst

Welche Implementation. Die von Beckhoff?[/code]

Nein. Der Code deines Programmes. Was antwortest du, wenn dein Chef fragt, ob der Code funktioniert?

Das ist eine inkompatible Änderung des Protokolls, weil hier die Interpretation von Datenfeldern, die bereits eine wohldefinierte Bedeutung haben, geändert werden muss.

booster schrieb:

Ich versteh nur Bahnhoff.

ref_property<datatype_entry_prop::hasBitValues, flag< AdsDatatypeEntry, datatype_entry_prop::flags, ADSDATATYPEFLAG_BITVALUES>>,

Das ist die einzige Stelle bei der du das Symbol verwendest. Und ehrlich gesagt habe ich Null Ahnung was du da überhaupt machst.

Das ist deshalb die einzige Stelle, weil ich das Flag noch nicht benutze und also dessen Folgen noch nicht berücksichtigt werden. Bin ja erst 90% fertig.

Der Code selbst ist rein deklarativ:
die Zeile ist ja Teil einer Argumentliste und fügt die Spezialisierung von ref_property dieser Liste hinzu.
ref_property ist ein paar aus einem int und einem Typ. Der Typ (flag<...>) enthält all den Code, der benötigt wird, um auf dieses Flag innerhalb der binären Daten zuzugreifen. structured_type ist nichts weiter als eine Aufzählung dieser int-Type-Paare und stellt praktisch eine map dar, die zur Compilezeit eine Zuordnung des ints zu diesem Typ ermöglicht (in properties_of<T>::get_accessor).

Wozu das Ganze? Ich wollte eben nicht 1000 mal den gleichen Code schreiben. Denn wie auf einzelne Felder der Binärstruktur zuzugreifen ist, sieht ja immer mehr oder weniger gleich aus. Gerade wenn subtile Unterschiede bestehen, übersieht man diese aber leicht.
Was ich also mache, ist erst mal abstrakt zu beschreiben, welche Art von Datenfeldern existieren, und wie auf diese zuzugreifen ist; das sind die verschiedenen Formen von Accessoren. Und im Anschluss wird in den Spezialisierungen von properties_of Zeile für Zeile, jedes einzelne Datenfeld aufgezählt und der dafür passende Accessor spezifiziert.
Diese Zuordnung funktioniert nahezu 1:1, so dass man eben die Übereinstimmung mit der Spezifikation leicht überprüfen kann, sofern man sich außerdem überzeugt hat, dass
1. die Accessoren das tun, was sie sollen, und
2. auch der richtige Accessor ausgewählt wird.

Die konkrete Zeile besagt letzlich, dass dem int Wert des enums dataype_entry_prop::hasBitValues der ein flag-Accessor zugeordnet ist, dieser Accessor hängt selbst von einer anderen Property (auf die per datatype_entry_prop::flags verwiesen wird) ab, verknüpft diesen Wert binär mit der angegebenen Maske (der 3.Templateparameter) und vergleicht das Ergebnis mit der Maske.

Ohne diese Strukturen, hätte ich dem Template ref (oder alternativ entsprechend vielen normalen Klassen) entsprechend viele Zugriffsfunktionen spendieren müssen, gleichzeitig würde der Code zwischen diesen Funktionen zum Teil subtil varrieren, weil semantisch gleichartige Felder nicht immer denselben Namen haben oder an der gleichen Stelle in der Struktur gefunden werden. Das kannst du im Ansatz bereits in den adsDT und adsSym-Klassen sehen in dem Code, den ich ganz am Anfang gebracht hatte. Mit jedem weiteren Datenstruktur, die das Programm kennen soll, verschlimmert sich die Situation.
Es ist wahrscheinlich auch nicht so, dass all die extra Information die du jetzt bekommen kannst, für dich nutzlos ist.
Structured Text erlaubt ja beispielsweise wertbeschränkte Variablen:

VAR
    myInt: INT (1..10);
END_VAR

Unabhängig davon, was dein Programm macht, ob bloß Überwachung oder auch Änderungen von Speicher, wirst du wahrscheinlich diese Beschränkungen beachten wollen. Die Information über diese Wertgrenzen wird aber durch Attribute gesendet, mit dem einfachen Beispielcode bekommst du sie nie zu sehen.