AGLink, AGLDotNET.dll Version 3.7 unter Windows 10

Maagic7

Level-2
Beiträge
384
Reaktionspunkte
180
Zuviel Werbung?
-> Hier kostenlos registrieren
habe ein Problem an einer Alten Maschine.

AUSGANGSLAGE


Ich musste nach einem Defekt, den alten Visualisierungs-PC austauschen
XP-SP3,
Der neue Panel-PC ist mit Windows 10 Version 1909

WinCC flexible hab ich wieder hinbekommen.

Es läuft aber parallel zum WinCC eine Betriebsdatenerfassung Programmiert mit Visual Studio 2005.
Diese Software verwendet zur SPS-Verbindung CPU315-2AG10
die AGLink Bibliothek.

Ich bekomme nun keine Verbindung mehr zur SPS.
Ursache dürfte die MPI-Karte des neuen PC seine, eine CP5612, der alte hatte noch ein CP5611
(Karten Umbauen geht leider nicht, da im Siemens Panel PC fest verbaut)

Mit AGL-Conifg kann ich die Schnittstelle schon nicht mehr auswählen.
Ebenfalls hab ich dann noch DemoVersion 3.7 und 5.4 von AGLink gezogen.
Mit beiden Versionen konnte ich die CP5611 Karte nicht einstellen.

FRAGEN


1. kann AG-Link unter Windows 10 über die CP5612 zugreifen ? Wenn ja, welche Version von AGLink

2. Wenn das mit Version 3.7 funktioneren sollte. Wo kann der Fehler liegen
AGLink Dateien hab ich nach Windows\SysWOW64 kopiert





 
Mit ACCON-AGLink 3.7 geht das definitiv nicht.
Welche ACCON-AGLink-Version war denn in dem alten Visualisierungs-PC im Einsatz?
Ist die CP5612 denn über PG-PC-Schnittstelle einstellen sichtbar und ansprechbar?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die CP5612 Karte wird in PG/PC Schnittstelle einstellen korrekt angezeigt und ist auf MPI Adr.21 187.5kB eingestellt.
Step7 und WinCC Flexible Runtime kommunizieren darüber.

Anbei ein ScreenShot der AGLink Dateien vom Original XP Rechner,
diese hab ich auf den neuen Win10 Rechner nach SysWOW64 kopiert,
Auf XP waren diese in System32

Auf Windows10 wird bei Rechtsklick Eigenschaften Version folgende angezeigt
AGLDotNET.dll Version 3.7.0.xxxx

AGLink.DLL Version 3.6

Das AGLink Konfigurationsprogramm zeigt bei "Zugangspunkt der Applikation"
keine Auswahlmöglichkeit an (siehe Screenshot)





AGLinkDateien.jpgAGLinkConfig_ScreenShot.jpg
 
WIe gesagt, ACCON-AGLink 3.x kann die PG-PC-Schnittstelle von 64 Bit Betriebsystemen nicht verwenden. Dazu wird eine aktueller Version von ACCON-AGLink benötigt. In aktuellen Version von ACCON-AGLink (derzeit 5.6) sind mir keine Probleme mit der PG-PC-Schnittstelle bekannt. Zum Testen bitte das Konfigurationsprogramm der aktuellen Version verwenden, sonst wird immer ACCON-AGLink Version 3.x geladen und die neuen Möglichkeiten stehen nicht zur Verfügung.
Wenn dies dann passt, hilft nur ändern des BDE-Quellcodes, denn von Version 3.x auf Version 4.x hat sich die Programmierschnittstelle geändert.
 
Hall Herr Hönle,

Vielen Dank für die Info.
Leider geht es auch mit Version 5.6 nicht.

Ich pack den neuen Rechner erst mal wieder ein und nimm ihn mit nach Hause.
Ich werde mich dann nächste Woche telefonisch bei Ihnen melden, da ich das auf jeden Fall hinbekommen muss
und ein Update für die AGLink benötige.AGLink_5.6_Insta.jpg

Folgende Lage besteht jetzt:

ich habe alle AGlink Version entfernt, neu gestartet
dann mit CCleaner die Registry und Tempverzeichnese aufgeräumt,
dann neu gestartet
dann AGLink V5.6 installiert
neu gestartet

Mit AGLink Konfigurationsporgramm gestartet.

Das Problem ist:
Die Auswahl S7-PC/CP erscheint im Konfigurationsprogramm nicht!

Siehe angehängter ScreenShot mit AGKonfig, PG/PC Schnittstelle einstellen und Gerätemanger S7NET
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich konnte das leider noch nicht ausprobieren.
Ich hab den Rechner mit zurück ins Büro genommen.
Bin aber diese Woche schon wieder an anderem Projekt.

Ich melde mich auf jeden Fall, wenn ich es probiert habe!

Vielen Dank
 
Neuigkeiten ja! Erfolg leider nein!

Die aktuelle Version der AGLink funktioniert soweit. Ein Testzugriff auf die SPS geht.

Leider verträgt sich das original Programm nicht mehr der neuen AGLink.
Ist erst auch mal klar, da anderer Name.
Hab die AGLink DLL's dann kopiert und in die alten Namen umbenannt (ohne der 40)

Das Visu-Programm stürtzt dann sofort beim Start ab. Exe blinkt nur kurz auf.

Ohne original SourceCode wird das wohl nicht zu machen sein!

Hab dann für einen Test ein fast identisches Programm genommen (von welchem der SourceCode vorhanden ist) und wollte das auf die neue AGLink
hochrüsten.
1. original Projekt von VS2005 in VS2015 geöffnet und konvertieren lassen
2. Leider scheitert es schon beim übersetzen. Es wird noch eine EXE erzeugt, die läßt sich aber nicht starten
- Side by Side Konfigurationsfehler! Wenn ich Dr. Google richtig verstanden habe, dann sind das NET Abhängigkeitsfehler!

Danach hab ich es erstmal frustriert aufgegeben!
Da auch noch die beiden AGLink wohl zueinander inkompatibel sind rechne ich mir keine Chancen mehr aus!

So wie es aussieht müssen wir alten XP Rechner besorgen und das irgendwie dort zum laufen bringen.
Eine Dauerlösung ist das aber nicht!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich weiß nicht wie das bei Aglink aussieht, meistens steckt in der .net.dll hauptsächlich nur etwas mehr oder weniger aufwändiger Glue-Code um die eigentliche C-dll in die .Net Umgebung einbinden und komfortabel verwenden zu können.
Vielleicht kannst du diesen Teil neu schreiben und die alte .Net API auf die neue C-dll API von Aglink umbiegen.
 
Von AGLink Version 3.x zu AGLink Version 4.x hat sich im Jahre 2006 die komplette Aufrufschnittstelle nicht nur der Funktionsname geändert. Dies war z. B. für die mit 4.x eingeführte asynchrone Aufrufmöglichkeit erforderlich. Version 3.x wurde noch einige Jahre mitgepflegt, die Kompatibilität zu den 64 Bit-Betriebsystemen bei S7-PC/CP ist nicht mehr enthalten.
Es hilft wirklich nur ein ändern des Quellcodes und anpassen an die neue API.
Oder Du verwendest ein 32-Bit-Betriebsystem auf dem Rechner. Dann sollte es auch noch mit Version 3.x funktionieren.
 
Langsam gibt es Licht am Ende des Tunnels!

Hab den SideBySide Fehler behoben. Das war in XML-Datei *exe.Config, die Zeichcodierung!
Die hab ich entfernt dann ging es! Windows Ereignis-Log sei Dank!

Die neue AGLink hab ich nun auch korrekt im VB_Net-Projekt eingebunden! Alle alten Verweise sind entfernt!
unter Projekt Verweise wird
Name Typ Version
AGL4DotNet.dll .NET 5.6.0.0

Problem ist jetzt anscheinend nur noch die neue Version von AGLINK

Ich kann die Exe nicht erstellen! Folgende Fehler treten auf!

Der Typ: Accon.AGL ist nicht definiert
Der Typ: Accon.AGL.DATA.RW ist nicht definiert
Der Typ: AGL.DATA.RW ist nicht definiert

Da ich mich bisher weder mit der Software noch mit AGLink jemals beschäftigt habe steh ich erst mal wieder auf dem Schlauch!

Hat das jetzt neue Namen oder ist meine Einbindung der AG4DotNet.DLL doch nicht korrekt?

Ich hab ein Modul in VB_Net "mod_AGL.vb", dort ist die erste Zeile "Imports Accon"
dann die Funktionen
Public Function write_INT (dValue As Long, nDB As Integer, nDW As Integer) as Boolean
Public Function write_DWORD(dValue As Long, nDB As Integer, nDW As Integer) as Boolean
usw.

Fragen:
1. Ich nehme an das ist von AGLink mitgelieferter Code, bin mir aber nicht sicher

2. Imports Accon ; was ist Accon
Ich nehme an Accon ist der Import der Funktionen aus der AG4DotNet.DLL

(die IDE sagt mir hierzu Imports ist nicht notwendig)

3. Ich kann keinerlei API Definitionen für irgendwelche Funktionen aus der AG4DotNet.Dll finden.
Gehe mal davon aus das ist bei NET so und es handelt sich um NET-Klassen, die automatisch zur Verfügung stehen,
wenn die DLL in den Verweisen eingebunden ist.


Bin leider nur VB6 und SPS Spezialist, mit NET hatte ich bisher noch nichts zu schaffen. Aber mit ein paar Infos werd ich das
wohl noch gebacken bekommen!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Von 3.x auf 4.x hat sich nicht nur die API von ACCON-AGLink sondern auch die API des .net-Wrappers geändert. Teste das Ganze doch einmal mit der alten Version unter einem 32-Bit-Betriebsystem.
 
Leider nur auf Windows XP, da geht es ja!
Wenn ich die Gelegenheit dazu habe, werde ich das mal auf Win7x32 testen,
das wäre zumindest jetzt noch eine Alternative.

Leider wohl nicht lange, da die meisten aktuellen Prozessoren praktisch jetzt schon kein Win7 mehr unterstützen.
 
Zurück
Oben