Post by dakmueller on Zielsystem Problem nach Bibliotheken hinzufügen ^{CODESYS Forge talk (Post)}
Hallo, ich habe ein altes Projekt geöffnet um auf einer Anlage eine Änderung einzufügen. Beim öffnen haben etliche Bibliotheken gefehlt. Diese habe ich dann installiert und übersetzt. Online kam ich nicht, weil kein Zielsystem angegeben war. Beim Übersetzten gab es keine Meldungen. Als ich das Zielsystem XV-1xx-V2.3.9 SP3 ausgewählt habe und das übersetzt kamen viele Fehlermeldungen. Viele Variablen nicht deklariert. Die Steuerung/HMI ist eine EATON XV-102-E8-57TVRC-10. Hilfe
Last updated: 4 days ago

Deutsch 🇩🇪 ^{CODESYS Forge talk (Discussion)}
German forum
Last updated: 4 days ago

Zielsystem Problem nach Bibliotheken hinzufügen ^{CODESYS Forge talk (Thread)}
Zielsystem Problem nach Bibliotheken hinzufügen
Last updated: 4 days ago

Post by dakmueller on Zielsystem Problem nach Bibliotheken hinzufügen ^{CODESYS Forge talk (Post)}
Hallo, ich habe ein altes Projekt geöffnet um auf einer Anlage eine Änderung einzufügen. Beim öffnen haben etliche Bibliotheken gefehlt. Diese habe ich dann installiert und übersetzt. Online kam ich nicht, weil kein Zielsystem angegeben war. Beim Übersetzten gab es keine Meldungen. Als ich das Zielsystem XV-1xx-V2.3.9 SP3 ausgewählt habe und das übersetzt kamen viele Fehlermeldungen. Viele Variablen nicht deklariert. Die Steuerung/HMI ist eine EATON XV-102-E8-57TVRC-10. Hilfe
Last updated: 4 days ago

Post by alexschooneveld on OPC UA PubSub SL 1.3 — UADP WriterGroup with assigned PSS.SecurityGroup still publishes plaintext ^{CODESYS Forge talk (Post)}
I am currently investigating an OPC UA PubSub connection over UDP. When I don't use encryption, the publish and subscribe are working correctly. But with encryption it does not. Environment OPC UA PubSub SL 1.3.0.0 (namespace UADP) OPC UA PubSub Security 1.3.0.0 (namespace PSS) OPC UA PubSub Base 1.3.0.0 (namespace PSB, incl. PSS.SecurityGroup / PSS.CONFIG) Programmatic PubSub in a CFC: UADP.Configuration → UADP.Connection → UADP.writerGroup → UADP.writer → writerDataSet, plus a CyclicCall gated by xEnable. Goal: publish secured UADP, SignAndEncrypt, policy PubSub-Aes256-CTR. What I do (one-shot, before xEnable := TRUE): fbSecurityGroup.SetInitialValue( 'http://opcfoundation.org/UA/SecurityPolicy#PubSub-Aes256-CTR', PSB.SECURITY.SIGNING_AND_ENCRYPTION); stSecurityCfg := fbSecurityGroup.GetConfig(eErrorID => eError); // eError=NO_ERROR, udiEncryptionKeySize=32 eError := fbSecurityGroup.SetSecurityKeys(udiTokenId, ADR(abyKey), SIZEOF(abyKey), 2436001000); // eError=NO_ERROR, SIZEOF=68 // writerGroup.itfSecurityGroup := fbSecurityGroup -- set in the WriterGroup block's Parameters (a per-scan code write got overwritten) What I verified eError = NO_ERROR after both GetConfig and SetSecurityKeys; udiEncryptionKeySize = 32. Key length = 68 bytes (signing 32 ‖ encrypt 32 ‖ nonce 4). itfSecurityGroup is set via the WriterGroup's Parameters (so it isn't clobbered each scan). Init runs before xEnable (the writer doesn't run with xEnable=FALSE). The UADP.writerGroup FB exposes only itfSecurityGroup for security — no SecurityMode/MessageSecurityMode property. Result: the published datagrams are still plaintext — ExtendedFlags1 = 0x01 (security bit 0x10 clear), no security header: b1 01 29 00 0f 16 00 … (PublisherId 41, WriterGroupId 22, RawData, no security) Questions With UADP.writerGroup, is assigning a configured + keyed PSS.SecurityGroup to itfSecurityGroup sufficient to enable message security, or is there an additional step/property/method to switch the WriterGroup to SignAndEncrypt? At what point in the WriterGroup lifecycle is itfSecurityGroup read? Must it be assigned/keyed before xActive, and does the group need a stop→start to pick it up? Is there a required call order, and does SetSecurityKeys need to be called once or repeatedly? Should security be configured on the Connection/Configuration level rather than (or in addition to) the WriterGroup? Is there a working example of secured (SignAndEncrypt) programmatic UADP publishing with this library, or a known limitation in 1.3? How can I read back at runtime whether security is actually active (via itfDiagnostics or similar)? Additional information I can confirm that the consumer side works — i.e. a standard subscriber decrypts the same keys fine — so the keys/profile aren't the issue. The Wireshark capture of the published message is: 0000 b1 01 29 00 0f 16 00 df 0d bb 25 01 00 0e 00 1b ..).......%..... 0010 0e 00 00 00 00 00 00 00 ........
Last updated: 3 days ago

Post by alexschooneveld on OPC UA PubSub SL 1.3 — UADP WriterGroup with assigned PSS.SecurityGroup still publishes plaintext ^{CODESYS Forge talk (Post)}
I am currently investigating an OPC UA PubSub connection over UDP. When I don't use encryption, the publish and subscribe are working correctly. But with encryption it does not. Environment OPC UA PubSub SL 1.3.0.0 (namespace UADP) OPC UA PubSub Security 1.3.0.0 (namespace PSS) OPC UA PubSub Base 1.3.0.0 (namespace PSB, incl. PSS.SecurityGroup / PSS.CONFIG) Programmatic PubSub in a CFC: UADP.Configuration → UADP.Connection → UADP.writerGroup → UADP.writer → writerDataSet, plus a CyclicCall gated by xEnable. Goal: publish secured UADP, SignAndEncrypt, policy PubSub-Aes256-CTR. What I do (one-shot, before xEnable := TRUE): fbSecurityGroup.SetInitialValue( 'http://opcfoundation.org/UA/SecurityPolicy#PubSub-Aes256-CTR', PSB.SECURITY.SIGNING_AND_ENCRYPTION); stSecurityCfg := fbSecurityGroup.GetConfig(eErrorID => eError); // eError=NO_ERROR, udiEncryptionKeySize=32 eError := fbSecurityGroup.SetSecurityKeys(udiTokenId, ADR(abyKey), SIZEOF(abyKey), 2436001000); // eError=NO_ERROR, SIZEOF=68 // writerGroup.itfSecurityGroup := fbSecurityGroup -- set in the WriterGroup block's Parameters (a per-scan code write got overwritten) What I verified eError = NO_ERROR after both GetConfig and SetSecurityKeys; udiEncryptionKeySize = 32. Key length = 68 bytes (signing 32 ‖ encrypt 32 ‖ nonce 4). itfSecurityGroup is set via the WriterGroup's Parameters (so it isn't clobbered each scan). Init runs before xEnable (the writer doesn't run with xEnable=FALSE). The UADP.writerGroup FB exposes only itfSecurityGroup for security — no SecurityMode/MessageSecurityMode property. Result: the published datagrams are still plaintext — ExtendedFlags1 = 0x01 (security bit 0x10 clear), no security header: b1 01 29 00 0f 16 00 … (PublisherId 41, WriterGroupId 22, RawData, no security) Questions With UADP.writerGroup, is assigning a configured + keyed PSS.SecurityGroup to itfSecurityGroup sufficient to enable message security, or is there an additional step/property/method to switch the WriterGroup to SignAndEncrypt? At what point in the WriterGroup lifecycle is itfSecurityGroup read? Must it be assigned/keyed before xActive, and does the group need a stop→start to pick it up? Is there a required call order, and does SetSecurityKeys need to be called once or repeatedly? Should security be configured on the Connection/Configuration level rather than (or in addition to) the WriterGroup? Is there a working example of secured (SignAndEncrypt) programmatic UADP publishing with this library, or a known limitation in 1.3? How can I read back at runtime whether security is actually active (via itfDiagnostics or similar)? Additional information I can confirm that the consumer side works — i.e. a standard subscriber decrypts the same keys fine — so the keys/profile aren't the issue. The Wireshark capture of the published message is: 0000 b1 01 29 00 0f 16 00 df 0d bb 25 01 00 0e 00 1b ..).......%..... 0010 0e 00 00 00 00 00 00 00 ........
Last updated: 3 days ago

OPC UA PubSub SL 1.3 — UADP WriterGroup with assigned PSS.SecurityGroup still publishes plaintext ^{CODESYS Forge talk (Thread)}
OPC UA PubSub SL 1.3 — UADP WriterGroup with assigned PSS.SecurityGroup still publishes plaintext
Last updated: 3 days ago

OPC UA PubSub SL 1.3 — UADP WriterGroup with assigned PSS.SecurityGroup still publishes plaintext ^{CODESYS Forge talk (Thread)}
OPC UA PubSub SL 1.3 — UADP WriterGroup with assigned PSS.SecurityGroup still publishes plaintext
Last updated: 3 days ago

Post by fabiodasilveira on Dynamic Setting IP Address from IEC code ^{CODESYS Forge talk (Post)}
It is a shame that it does not work with Eaton XC303 PLCs :(
Last updated: 3 days ago

Why Is Academic Writing So Stressful for Many Students? ^{CODESYS Forge talk (Thread)}
Why Is Academic Writing So Stressful for Many Students?
Last updated: 2 days ago

Runtime 🇬🇧 ^{CODESYS Forge talk (Discussion)}
Related questions to SoftPLCs e.g. Raspberry Pi, Beaglebone, IoT2000 and other platforms
Last updated: 2 days ago

<Dereference of invalid pointer> ^{CODESYS Forge talk (Thread)}
<dereference of="" invalid="" pointer=""></dereference>
Last updated: 2 days ago

Version management ^{CODESYS Forge talk (Thread)}
Version management
Last updated: 1 day ago

SCADA Systems Are Becoming Easier to Integrate With Modern Applications ^{CODESYS Forge talk (Thread)}
SCADA Systems Are Becoming Easier to Integrate With Modern Applications
Last updated: 1 day ago

Motion 🇬🇧 ^{CODESYS Forge talk (Discussion)}
Realizing single or multi axis motion control, CAM, CNC and Robotic applications
Last updated: 18 hours ago

Post by gseidel on CODESYS SoftMotion Generic DSP402 on WAGO PFC200 + Festo CMMT-AS: MC_Power stays Busy, Controlword remains 0 ^{CODESYS Forge talk (Post)}
Hi gilad, the missing license does not prevent the axis from being enabled. As far as I know, Festo distributes a CODESYS SoftMotion driver for the CMMT drives together with their software. I would contact Festo and ask for the driver. Best regards, Georg
Last updated: 18 hours ago

CODESYS SoftMotion Generic DSP402 on WAGO PFC200 + Festo CMMT-AS: MC_Power stays Busy, Controlword remains 0 ^{CODESYS Forge talk (Thread)}
CODESYS SoftMotion Generic DSP402 on WAGO PFC200 + Festo CMMT-AS: MC_Power stays Busy, Controlword remains 0
Last updated: 18 hours ago

Sort by relevance or date