Ich habe folgendes Problem, das mich ein wenig nervt. Vielleicht könnt ihr mir helfen..
Ich steuere eine Reihe von Profibus-Geräten an, indem ich die Daten, die ich von diesen bekomme in eine Struktur schreibe und diese als Variable mit Startadresse deklariere.
also z.B:
  (*PGx*)    PGx_in:PRESSUREGAUGE_inputAT%IB1.18;    PGx_out:PRESSUREGAUGE_outputAT%QB1.24;  (*PGy*)    PGy_in:PRESSUREGAUGE_inputAT%IB1.24;    PGy_out:PRESSUREGAUGE_outputAT%QB1.33;
mit
  TYPEPRESSUREGAUGE_input:    STRUCT  (*inputstructurefromTIC251/252*)      dwPressure:DWORD;      byData:BYTE;      byCommAck:BYTE;    END_STRUCT  END_TYPEund  TYPEPRESSUREGAUGE_output:    STRUCT      dwPressureAdj:DWORD;  (*adjustpressure*)      byR:BYTE;    (*bytevalue:  0:nocommand                1:activateDeGas                2:adjustlowpressure                3:adjusthighpressure                4:transmitcorrfactor                5:filamenton(coldkathode)                6:filamentoff            (*----------------------------------------------------  *)*)      wCorrFacPI:WORD;  (*correctionfactorpriani*)      wCorrFacKK:WORD;  (*correctionfactorcoldcathode*)    END_STRUCT  END_TYPE
das heißt, die Input-Struktur ist 6 bytes, die Output-Struktur 9 bytes lang. Die Adressen werden vom PS501 v2.1.0 automatisch zugewiesen. Wenn ich das Projekt auf überlappende Speicherbereiche überprüfe bekomme ich folgende Meldungen:
%IW1.12 wird durch folgende Variablen referenziert:
PGx_in AT %IB1.18
PGy_in AT %IB1.24
%QB1.33..%QD1.9 wird durch folgende Variablen referenziert:
PGx_out AT %QB1.24
PGy_out AT %QB1.33
Ich verstehe nicht ganz, wo mein Fehler ist. Die Speicherbereiche überlappen sich offensichtlich nicht, aber im ersten Fall schreibt PGx_in in den Speicherbereich von PGy_in, obwohl es nur 6 bytes lang ist. Im zweiten Fall überschreibt PGx_out (9 bytes) ganze 4 bytes von PGy_out. Legt CoDeSys die Strukturen nicht geschlossen im Speicher ab?
Ich bin für Tipps sehr dankbar, mir sind nämlich die Ideen ausgegangen.
AC500 Pm592-ETH V2.1
Control Buidler Plus PS501 v2.1.0
CoDeSys 2.3.9.28
Vielen Dank
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Moin
Es gab (oder gibt evtl. immer noch) den Fehler, dass die In- und Out-Strukturen der Profibusteilnehmer symetrisch sein mussten.
Sprich wenn du 9 Byte OUT benutzt musst du auch IN mit 9 Byte belegen.
Ich kenn das von der RTE. Wie das auf deiner Hardware, bzw. dem zugehörigen LZS ist weiss ich nicht.
Aber einen Versuch ists ja vielleicht wert.
Gruß Erik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ich glaube allerdings nicht, dass das Problem in diesem Fall dort liegt. Die Konfiguration des Projekts muss ich auf meiner HW im ControlBuilder machen. Der mappt auch die Profibus-Geräte automatisch auf die Adressen (zumindest habe ich keine Möglichkeit gefunden diese manuell zuzuweisen). In CoDeSys sehe ich dann nur mehr das Mapping. Ich glaube, dass CoDeSys gar nicht mehr "weiß", dass es sich um ein Profibus-Gerät handelt.
Wenn ich dich richtig verstehe, müssten deiner Meinung sowohl In- als auch Output so lang sein wie der längere der beiden (also in meinem Fall 9bytes), oder? Bei mir ist nämlich auch der längere Output schon zu lang...
Ich kann ja mal versuchen, das Output-Mapping ganz wegzulassen, vielleicht hilft es ja was. Zumindest wüsste ich dann, wo das Problem leigt, auch wenn es keine Lösung ist...
Gruß Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dein Bistadressen überschneiden sich auch
Dei Startadresse %IB1.18 mach aucht kein sinn wenn es sich um ein Word oder länger handelt.
Sollte dieses nicht %IB18 heißen ?
Dann währe die nächste freie Addresse bei einer länge von 6Byte %IB24
(PGx)
PGx_in : PRESSUREGAUGE_input AT %IB1.18;
PGx_out : PRESSUREGAUGE_output AT %QB1.24;
(PGy)
PGy_in : PRESSUREGAUGE_input AT %IB1.24;
PGy_out : PRESSUREGAUGE_output AT %QB1.33;
mfG Jochen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ich denke, die Adressierung stimmt. In der Hilfe unter Punkt 2.1 Schnittstellen für Ein- / Ausgänge in AC500 steht:
Zitat:
Die Adressierung das Kommunikationsmodul-E/As erfolgt zweistufig in der Form:
%I(Q)BKommunikationsmodul-Nummer.ByteKommunikationsmodul
Mein Profibus-Master (CM572-DP) hat die Moduladresse 1. Dann müsste das Adressschema doch stimmen?
Was ich mir mittlereweile gedacht habe ist, dass ich ein Wort eventuell nur auf eine Wortadresse schreiben kann, also die Startadresse eines Wortes nur z.B. %IB1.0 und dann wieder %IB1.2 sein kann. Wenn das so ist müsste ich das Programm dementsprechend umschreiben, da ja dann z.B. in der Struktur zwischen dem und dem ein Byte frei bleiben würde usw...
  TYPEPRESSUREGAUGE_output:   STRUCT     dwPressureAdj:DWORD;  (*adjustpressure*)     byR:BYTE;   (*bytevalue:  0:nocommand            1:activateDeGas            2:adjustlowpressure            3:adjusthighpressure            4:transmitcorrfactor            5:filamenton(coldkathode)            6:filamentoff         (*----------------------------------------------------  *)*)     wCorrFacPI:WORD;  (*correctionfactorpriani*)     wCorrFacKK:WORD;  (*correctionfactorcoldcathode*)   END_STRUCT  END_TYPE
Ich bin gerde dabei das auszuprobieren. Kann es daran liegen?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
diese Adressen werden schon vom I/O-Bus verwendet (hängt direkt an der CPU). Ich bekomme auch Meldungen wie . D.h. das Adressschema ist in diesem Fall
Gruß Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-05-22
Originally created by: blackenslaver666
Hallo Alex.
Ich glaube deine Adressierung ist falsch. Erik & Co haben Recht, ich kenne das auch nicht anders. Hier mal ein paar generelle Basics zum DP:
- Es ist richtig, dass der DP-Master eine Moduladresse hat (default #1). Allerdings mappt der ja selbst keine Daten & da sollte auch dein Fehler beim Zugriff liegen. Ein Zugriff mit I/QB1.xxxx.xxxx schlägt daher fehl.
- Jeder DP-Slave wird üblicherweise über eine GSD-Datei eingebunden & bekommt neben einer Knotenadresse (1-127) seine E/A-Parameter übergeben (die Daten die der Slave mit dem Master austauscht, wobei die GSD die entsprechenden Möglichkeiten anbietet (8 Byte E/A, 16 Byte E/A etc.). Im Slave-Eigenschaften-Fenster kann man zudem die SPS-IEC-Adresse bestimmen, auf die der Master die Slave-Daten mappt. So definiert man sein DP-Netz.
- Die Angabe in der Hilfe ist korrekt. In der SPS sind DP-Module meist globale Objekte, d.h. sie kann man überall aus dem Programm her ansprechen. Bei uns geht das über den Knotennamen (aus der Steuerungskonfig).ByteNr.Bitadresse. Da dies umständlich ist (weil lange) haben wir eine globale IO-Liste wo wir dem ref. E/A-Bereich des DP-Knotens symbolische Identifier (mit absoluten IEC-Adressen) geben. Mit denen arbeiten wir im Programm, prinzipiell sind aber beide Zugriffe möglich (Daten logischerweise identisch).
- Du kannst jetzt so auch arbeiten, oder aber du musst deine Adresse mit der Knotenadresse deines Slaves verknüpfen, nicht der vom Master. Die Adressierung kommt mir trotzdem seltsam vor, das Komm-Modul ist mMn komplett überflüssig (in deinem Sinne sogar doppelt)...
Ich kenne die ABB-SPS jetzt nicht. Es wäre vielleicht für uns alle ganz hilfreich, wenn du mal einen Screenshot von der Steuerungskonfig anhängst. Mich interessiert wie du einzelne Slaves einbindest (Ventile etc.), deren Eigenschaften- & Parameterfenster. Dann kann man auch besser helfen...
Gruss Andy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
erstmal danke für die Infos. Hab mich noch ein bisschen eingelesen und bei mir nach den von dir beschriebenen Möglichkeiten gesucht. Also dann hole ich einmal etwas aus
Im Screenshot 1 siehst du rechts die Steuerungskonfiguration. Direkt an der CPU der I/O-Bus (Heizungen, Lagerückmelder für Ventile, Vorvakuumpumpen, Thermocoupler, ...). Dieser Bereich wird mir im Format %[I/O][B/W/D][Nr] in Codesys gemappt.
Darunter COM1/2, verwende ich um über rs485 Ionengetterpumpen und Titansublimatoren anzusteuern und finally mein Sorgenkind die Kommunikationsmodule. Der CM572_DP ist der DP-Master, an diesem hängen eine Ventilinsel (pneumatische Ventile) und dann eine Reihe von Turbopumpen und Druckmesszellen.
Derzeit habe ich diese so eingebunden wie zuvor beschrieben. Ich habe eine In-/Output-Struktur geschrieben und gebe dieser eine Startaddresse im Format %I/QBx.x. In einem Funktionsblock zerlege ich die Das funktioniert auch soweit, bis eben auf die Überlappenden Speicherbereiche. Wenn ich nun einen Variablennamen vergebe (Screenshot 2) dann sehe ich diesen im Codesys als Globale Variable mit Variablenname AT %I/QB1.xx vom Datentyp <variablenname>_<channel>_Mapping_Structure (Screen1). So kann ich theoretisch auch einzelne Bits im Konfigurationseditor benennen und habe sie dann als globale Variablen (mit Adressierung) vorliegen. Deswegen - um nicht alles per Hand mappen zu müssen - habe ich mir gedacht, eine Startadresse müsste doch ausreichen.</channel></variablenname>
Zitat:
- Jeder DP-Slave wird üblicherweise über eine GSD-Datei eingebunden & bekommt neben einer Knotenadresse (1-127) seine E/A-Parameter übergeben (die Daten die der Slave mit dem Master austauscht, wobei die GSD die entsprechenden Möglichkeiten anbietet (8 Byte E/A, 16 Byte E/A etc.). Im Slave-Eigenschaften-Fenster kann man zudem die SPS-IEC-Adresse bestimmen, auf die der Master die Slave-Daten mappt. So definiert man sein DP-Netz.
(Screenshot 1 und 3)
Genau..das einzige was ich nicht finde, ist die Möglichkeit die auf die zu mappende Adresse zu bestimmen.
Das das ein wenig umständlich/überflüssig ist, da stimme ich dir voll und ganz zu, v.a. weil ich so viel mehr Speicher belegen muss als es notwendig wäre.
Gruß
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Was ist denn das für eine Konstruktion ??? V2.3 Projekt mit V3.x Konfigurator ?
Da konnte wohl jemand die V3 nicht erwarten und hat dann einen Zwitter draus gemacht, oder ?
Aber so wie Andy das schon gesagt hat, ein Screenshot der Steuerungskonfiguration wäre interessant.
Denn dort stehen die verwendeten Adressen. (zumindest stehen sie dort bei 'normalen' CoDeSys Projekten)
Gruß Erik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-05-23
Originally created by: blackenslaver666
Mahlzeit.
Ja, wie Erik schon sagte sieht das in der Tat wie ein Zwitter aus V2.3 & V3 aus. Und das schaut in der Tat gänzlich anders aus als das was ich kenne....
Anhand deinen Screenshots kann man aber folgendes sehen:
- Es ist komfortabel dass dein Editor schon automatische eine globale var der entsprechenden Adresse zuordnet. dass müsste im Register "DP-Module I/O-Abbild" zu finden sein (wie die Hilfe sagt). Bei uns geschieht das nur manuell nicht automatisch.
- Evt. ist das Register pro Knoten gesperrt weil der Master die Adressen automatisch vergibt. Bei uns gibt es im Master einen Parameter "Adressen automatisch". Wenn man den abwählt kann man die Adressen pro Knoten manuell vergeben.
- ich würde gerne mal das Register "DP-Module I/O-Abbild" sehen.
Im Anhang findest du ein paar SCs von meinem DP-Netz. Der Master ist von Hilscher, es gibt 7 Slaves, ein Beckhoff-Knoten ist exemplarisch mit seinen IO-Adressen gezeigt (GSD-name ebenso). Im register Ein-/Ausgänge definiert man den Datenaustausch...
Gruß A.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ja diese Zwittergeschichte hat mir anfangs auch Kopfzerbrechen bereitet. Aber man benützt den ControlBuilder (basiert auf v3.4) und entwickelt dann in 2.3. Deswegen ist meine Steuerungskonfiguration auch leer. Die wird direkt übergeben.
Aha, du musst das alles noch selber anlegen. Das ist dann hier wirklich ein wenig komfortabler. Aber danke für den Screnshot. Ich wollte immer schon einmal sehen, wie das ohne diese kombination aussieht.
Im Anhang der Screenshot vom I/O-Modul-Abbild Register.
Aber jetzt mal zurück zu meinem Problem hat jemand ideen? Derzeit bin ich am überlegen, ob ich nicht den gesamten Input/Output-Channel byteweise einlese/schreibe und erst in der Objektinstanz zusammenfüge/zerlege.
Gruß
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wir würden ja gerne helfen. Aber da sich von uns wohl keiner wirklich in dein Problem reinarbeiten kann, würde ich vorschlagen du wendest dich an den der diesen Konfigurator 'verbrochen' hat.
ABB hat ja sicher auch nen Support. Oder direkt über e support@3s-software.com e .
Gruß Erik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
tja, da hast du wohl recht. Ich dachte es fallen vielleicht noch irgendwo Ideen vom Himmel
Werde mich an den Support wenden und in der Zeit noch selbst anch einer Lösung suchen. Melde mich hoffentlich mit einer Lösung meines Problems wieder...
Gruß
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo zusammen,
Ich habe folgendes Problem, das mich ein wenig nervt. Vielleicht könnt ihr mir helfen..
Ich steuere eine Reihe von Profibus-Geräten an, indem ich die Daten, die ich von diesen bekomme in eine Struktur schreibe und diese als Variable mit Startadresse deklariere.
also z.B:
mit
das heißt, die Input-Struktur ist 6 bytes, die Output-Struktur 9 bytes lang. Die Adressen werden vom PS501 v2.1.0 automatisch zugewiesen. Wenn ich das Projekt auf überlappende Speicherbereiche überprüfe bekomme ich folgende Meldungen:
%IW1.12 wird durch folgende Variablen referenziert:
PGx_in AT %IB1.18
PGy_in AT %IB1.24
%QB1.33..%QD1.9 wird durch folgende Variablen referenziert:
PGx_out AT %QB1.24
PGy_out AT %QB1.33
Ich verstehe nicht ganz, wo mein Fehler ist. Die Speicherbereiche überlappen sich offensichtlich nicht, aber im ersten Fall schreibt PGx_in in den Speicherbereich von PGy_in, obwohl es nur 6 bytes lang ist. Im zweiten Fall überschreibt PGx_out (9 bytes) ganze 4 bytes von PGy_out. Legt CoDeSys die Strukturen nicht geschlossen im Speicher ab?
Ich bin für Tipps sehr dankbar, mir sind nämlich die Ideen ausgegangen.
AC500 Pm592-ETH V2.1
Control Buidler Plus PS501 v2.1.0
CoDeSys 2.3.9.28
Vielen Dank
Alex
Moin
Es gab (oder gibt evtl. immer noch) den Fehler, dass die In- und Out-Strukturen der Profibusteilnehmer symetrisch sein mussten.
Sprich wenn du 9 Byte OUT benutzt musst du auch IN mit 9 Byte belegen.
Ich kenn das von der RTE. Wie das auf deiner Hardware, bzw. dem zugehörigen LZS ist weiss ich nicht.
Aber einen Versuch ists ja vielleicht wert.
Gruß Erik
Danke,
ich glaube allerdings nicht, dass das Problem in diesem Fall dort liegt. Die Konfiguration des Projekts muss ich auf meiner HW im ControlBuilder machen. Der mappt auch die Profibus-Geräte automatisch auf die Adressen (zumindest habe ich keine Möglichkeit gefunden diese manuell zuzuweisen). In CoDeSys sehe ich dann nur mehr das Mapping. Ich glaube, dass CoDeSys gar nicht mehr "weiß", dass es sich um ein Profibus-Gerät handelt.
Wenn ich dich richtig verstehe, müssten deiner Meinung sowohl In- als auch Output so lang sein wie der längere der beiden (also in meinem Fall 9bytes), oder? Bei mir ist nämlich auch der längere Output schon zu lang...
Ich kann ja mal versuchen, das Output-Mapping ganz wegzulassen, vielleicht hilft es ja was. Zumindest wüsste ich dann, wo das Problem leigt, auch wenn es keine Lösung ist...
Gruß Alex
Hallo Alex
Dein Bistadressen überschneiden sich auch
Dei Startadresse %IB1.18 mach aucht kein sinn wenn es sich um ein Word oder länger handelt.
Sollte dieses nicht %IB18 heißen ?
Dann währe die nächste freie Addresse bei einer länge von 6Byte %IB24
(PGx)
PGx_in : PRESSUREGAUGE_input AT %IB1.18;
PGx_out : PRESSUREGAUGE_output AT %QB1.24;
(PGy)
PGy_in : PRESSUREGAUGE_input AT %IB1.24;
PGy_out : PRESSUREGAUGE_output AT %QB1.33;
mfG Jochen
Ja, natürlich ! 1.18 usw ist Blödsinn.
Ich bin automatisch von IB18 und IB24 ausgegangen.
Ich denke, die Adressierung stimmt. In der Hilfe unter Punkt 2.1 Schnittstellen für Ein- / Ausgänge in AC500 steht:
Mein Profibus-Master (CM572-DP) hat die Moduladresse 1. Dann müsste das Adressschema doch stimmen?
Was ich mir mittlereweile gedacht habe ist, dass ich ein Wort eventuell nur auf eine Wortadresse schreiben kann, also die Startadresse eines Wortes nur z.B. %IB1.0 und dann wieder %IB1.2 sein kann. Wenn das so ist müsste ich das Programm dementsprechend umschreiben, da ja dann z.B. in der Struktur zwischen dem und dem ein Byte frei bleiben würde usw...
Ich bin gerde dabei das auszuprobieren. Kann es daran liegen?
Servus
Ich glaube du hast die Schreibweise nicht verstanden.
%IB1.0 -> ist das 0.Bit von InputByte 1
%IB1.2 -> ist das 2.Bit von InputByte 1
Richtig wäre:
%IB1 und %IB7
Gruß Erik
Hallo,
diese Adressen werden schon vom I/O-Bus verwendet (hängt direkt an der CPU). Ich bekomme auch Meldungen wie . D.h. das Adressschema ist in diesem Fall
Gruß Alex
Originally created by: blackenslaver666
Hallo Alex.
Ich glaube deine Adressierung ist falsch. Erik & Co haben Recht, ich kenne das auch nicht anders. Hier mal ein paar generelle Basics zum DP:
- Es ist richtig, dass der DP-Master eine Moduladresse hat (default #1). Allerdings mappt der ja selbst keine Daten & da sollte auch dein Fehler beim Zugriff liegen. Ein Zugriff mit I/QB1.xxxx.xxxx schlägt daher fehl.
- Jeder DP-Slave wird üblicherweise über eine GSD-Datei eingebunden & bekommt neben einer Knotenadresse (1-127) seine E/A-Parameter übergeben (die Daten die der Slave mit dem Master austauscht, wobei die GSD die entsprechenden Möglichkeiten anbietet (8 Byte E/A, 16 Byte E/A etc.). Im Slave-Eigenschaften-Fenster kann man zudem die SPS-IEC-Adresse bestimmen, auf die der Master die Slave-Daten mappt. So definiert man sein DP-Netz.
- Die Angabe in der Hilfe ist korrekt. In der SPS sind DP-Module meist globale Objekte, d.h. sie kann man überall aus dem Programm her ansprechen. Bei uns geht das über den Knotennamen (aus der Steuerungskonfig).ByteNr.Bitadresse. Da dies umständlich ist (weil lange) haben wir eine globale IO-Liste wo wir dem ref. E/A-Bereich des DP-Knotens symbolische Identifier (mit absoluten IEC-Adressen) geben. Mit denen arbeiten wir im Programm, prinzipiell sind aber beide Zugriffe möglich (Daten logischerweise identisch).
- Du kannst jetzt so auch arbeiten, oder aber du musst deine Adresse mit der Knotenadresse deines Slaves verknüpfen, nicht der vom Master. Die Adressierung kommt mir trotzdem seltsam vor, das Komm-Modul ist mMn komplett überflüssig (in deinem Sinne sogar doppelt)...
Ich kenne die ABB-SPS jetzt nicht. Es wäre vielleicht für uns alle ganz hilfreich, wenn du mal einen Screenshot von der Steuerungskonfig anhängst. Mich interessiert wie du einzelne Slaves einbindest (Ventile etc.), deren Eigenschaften- & Parameterfenster. Dann kann man auch besser helfen...
Gruss Andy
Hallo Andy,
erstmal danke für die Infos. Hab mich noch ein bisschen eingelesen und bei mir nach den von dir beschriebenen Möglichkeiten gesucht. Also dann hole ich einmal etwas aus
Im Screenshot 1 siehst du rechts die Steuerungskonfiguration. Direkt an der CPU der I/O-Bus (Heizungen, Lagerückmelder für Ventile, Vorvakuumpumpen, Thermocoupler, ...). Dieser Bereich wird mir im Format %[I/O][B/W/D][Nr] in Codesys gemappt.
Darunter COM1/2, verwende ich um über rs485 Ionengetterpumpen und Titansublimatoren anzusteuern und finally mein Sorgenkind die Kommunikationsmodule. Der CM572_DP ist der DP-Master, an diesem hängen eine Ventilinsel (pneumatische Ventile) und dann eine Reihe von Turbopumpen und Druckmesszellen.
Derzeit habe ich diese so eingebunden wie zuvor beschrieben. Ich habe eine In-/Output-Struktur geschrieben und gebe dieser eine Startaddresse im Format %I/QBx.x. In einem Funktionsblock zerlege ich die Das funktioniert auch soweit, bis eben auf die Überlappenden Speicherbereiche. Wenn ich nun einen Variablennamen vergebe (Screenshot 2) dann sehe ich diesen im Codesys als Globale Variable mit Variablenname AT %I/QB1.xx vom Datentyp <variablenname>_<channel>_Mapping_Structure (Screen1). So kann ich theoretisch auch einzelne Bits im Konfigurationseditor benennen und habe sie dann als globale Variablen (mit Adressierung) vorliegen. Deswegen - um nicht alles per Hand mappen zu müssen - habe ich mir gedacht, eine Startadresse müsste doch ausreichen.</channel></variablenname>
(Screenshot 1 und 3)
Genau..das einzige was ich nicht finde, ist die Möglichkeit die auf die zu mappende Adresse zu bestimmen.
Das das ein wenig umständlich/überflüssig ist, da stimme ich dir voll und ganz zu, v.a. weil ich so viel mehr Speicher belegen muss als es notwendig wäre.
Gruß
Alex
Mahlzeit
Was ist denn das für eine Konstruktion ??? V2.3 Projekt mit V3.x Konfigurator ?
Da konnte wohl jemand die V3 nicht erwarten und hat dann einen Zwitter draus gemacht, oder ?
Aber so wie Andy das schon gesagt hat, ein Screenshot der Steuerungskonfiguration wäre interessant.
Denn dort stehen die verwendeten Adressen. (zumindest stehen sie dort bei 'normalen' CoDeSys Projekten)
Gruß Erik
Originally created by: blackenslaver666
Mahlzeit.
Ja, wie Erik schon sagte sieht das in der Tat wie ein Zwitter aus V2.3 & V3 aus. Und das schaut in der Tat gänzlich anders aus als das was ich kenne....
Anhand deinen Screenshots kann man aber folgendes sehen:
- Es ist komfortabel dass dein Editor schon automatische eine globale var der entsprechenden Adresse zuordnet. dass müsste im Register "DP-Module I/O-Abbild" zu finden sein (wie die Hilfe sagt). Bei uns geschieht das nur manuell nicht automatisch.
- Evt. ist das Register pro Knoten gesperrt weil der Master die Adressen automatisch vergibt. Bei uns gibt es im Master einen Parameter "Adressen automatisch". Wenn man den abwählt kann man die Adressen pro Knoten manuell vergeben.
- ich würde gerne mal das Register "DP-Module I/O-Abbild" sehen.
Im Anhang findest du ein paar SCs von meinem DP-Netz. Der Master ist von Hilscher, es gibt 7 Slaves, ein Beckhoff-Knoten ist exemplarisch mit seinen IO-Adressen gezeigt (GSD-name ebenso). Im register Ein-/Ausgänge definiert man den Datenaustausch...
Gruß A.
Ja diese Zwittergeschichte hat mir anfangs auch Kopfzerbrechen bereitet. Aber man benützt den ControlBuilder (basiert auf v3.4) und entwickelt dann in 2.3. Deswegen ist meine Steuerungskonfiguration auch leer. Die wird direkt übergeben.
Aha, du musst das alles noch selber anlegen. Das ist dann hier wirklich ein wenig komfortabler. Aber danke für den Screnshot. Ich wollte immer schon einmal sehen, wie das ohne diese kombination aussieht.
Im Anhang der Screenshot vom I/O-Modul-Abbild Register.
Aber jetzt mal zurück zu meinem Problem hat jemand ideen? Derzeit bin ich am überlegen, ob ich nicht den gesamten Input/Output-Channel byteweise einlese/schreibe und erst in der Objektinstanz zusammenfüge/zerlege.
Gruß
Alex
Servus
Wir würden ja gerne helfen. Aber da sich von uns wohl keiner wirklich in dein Problem reinarbeiten kann, würde ich vorschlagen du wendest dich an den der diesen Konfigurator 'verbrochen' hat.
ABB hat ja sicher auch nen Support. Oder direkt über e support@3s-software.com e .
Gruß Erik
Hallo,
tja, da hast du wohl recht. Ich dachte es fallen vielleicht noch irgendwo Ideen vom Himmel
Werde mich an den Support wenden und in der Zeit noch selbst anch einer Lösung suchen. Melde mich hoffentlich mit einer Lösung meines Problems wieder...
Gruß
Alex