TwinCat Load Symbol Data @camper

Dann kann ich nur vermuten, dass das neu und deine twincat Version zu alt ist. Bei mir ist sie drin (Dateidatum 22.02.2018 10:07 Uhr). Ich denke mir das ja nicht aus

Meine Ads.h ist vom 24.05.2017. Versteht wer will. Ich habe mir die neuste TwinCat Version letze Woche von der Hompage gezogen und installiert.

camper

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

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?

Evtl. funktionieren ja inplace Updates nicht so gut

An dem scheint es gelegen zu haben.

Funktioniert das ganze eigentlich auch noch für TwinCat2

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.

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.

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.

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.

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

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.

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.

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.