etzel-mes commented on PR #28387:
URL: https://github.com/apache/camel/pull/28387#issuecomment-6382799235
Following up on the real hardware remark on CAMEL-25617: results for
bd9fbb96aa3 on a real PLC.
Setup: a Siemens S7-1200 (CPU 1214C, 6ES7 214-1AG40-0XB0) on a customer test
line, reached from a Windows Server 2025 machine on the plant network. The
connection string was
`s7://<plc>:102?controller-type=S7_1200&cotp.remote-rack=0&cotp.remote-slot=1&pdu-size=240`.
A small camel-main jar with this branch's camel-plc4x and the PLC4X 1.0.0 S7
driver ran the read, write-back and trigger checks on a Java 21 JRE on that
machine. The remaining checks ran on a second machine (Java 25) through an SSH
tunnel to the PLC, which also let me cut or stall the connection on purpose.
Only the tags of one idle line were written.
| Check | Result |
|---|---|
| Periodic read (REAL, two BOOLs), 1 s, 40 reads | all OK; a value changed
by hand during the run showed up on the next read |
| Data types, one request each | BYTE, WORD, INT, DINT, REAL, DWORD, BYTE
array, `%MB`, `%IB`, `%QB`, `%MW` all OK |
| Write the same values back, one request per tag and REAL + BOOL in one
request | all `OK`, values unchanged |
| Write 123.45, -1.5, 0, 3.4E38, 1.0E-38 to a REAL | read back bit-identical
|
| Triggered consumer (BOOL trigger, period 500 ms), 3 pulses of 2 s |
exactly 3 exchanges, 70-90 ms after each rising edge |
| Same endpoint for 60 s: triggered consumer (100 ms) + producer writing
every 50 ms + a pulse every 1 s | 60 pulses → 60 exchanges, 821 writes, 360
polls, 0 failures, no new connection under load |
| Short pulses at period 100 ms | 150 ms and longer: 5/5 each; 100 ms and 50
ms: 4/5 (expected for a polled trigger) |
| REAL tag as trigger | poll fails within 70 ms with "must read as a
Boolean, but read a java.lang.Float", no exchange |
| `%DB999.DBD0`, `%DB1.DBD60000`, `%DB1.DBX16.9`, `garbage` |
`INVALID_ADDRESS` each; the connection stays usable |
| Connection cut for 12 s (`autoReconnect=true`) | each poll fails with
"Connection refused", reconnects about 1 s after the PLC is reachable again,
next pulse delivered |
| PLC silent for 15 s (TCP open, no answers) | polls fail after the 5 s
request timeout; the late answer is dropped ("unknown tpduRef"); no false
trigger, next pulse delivered |
| `controller-type=ANY` / `pdu-size=1024` | the SZL probe identifies the
S7-1200; the PDU is negotiated down to 240 |
Things I saw that are outside this PR, for separate tickets if you think
they are worth it:
- `setupConnection()` replaces the endpoint's connection without closing the
old one. The producer and the triggered consumer both call it on start, so a
route with both holds two PLC connections, which matters on an S7-1200.
- With `autoReconnect=true`, every failed poll logs a WARN with the full
stack trace, every period.
- The PLC4X 1.0.0 S7 driver fails to decode a BOOL array reply
(`%DB1.DBX16.0[0..7]:BOOL` → `INTERNAL_ERROR`, BufferUnderflowException). It is
the same on the real PLC and on snap7, so it belongs to PLC4X, not to
camel-plc4x.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
