Chia sẻ

TCSB kết nối CP1243-7 hay bị mất tín hiệu truyền

Hi! Với hệ TCSB (TeleControl Server Basic) kết nối trạm dùng CP1243-7 mà “hay rớt tín hiệu”, thường rơi vào mấy nhóm nguyên nhân dưới đây. Bạn làm lần lượt theo checklist này để khoanh vùng nhanh:

1) Lớp vật lý & sóng di động

Nguồn 24VDC cho CP1243-7: kiểm tra dao động/nhấp nháy khi phát sóng (dòng tăng đột biến). Nguồn yếu → rớt GPRS.
Cường độ sóng: mục tiêu > -85 dBm (tốt nhất > -75 dBm). Anten ngoài, dây ngắn, đầu nối chặt. Đổi vị trí anten để giảm suy hao.
SIM/Data: còn dung lượng, không bị chặn tốc độ; APN đúng; tắt mọi dịch vụ chặn IoT từ nhà mạng. Thử đổi SIM/nhà mạng để loại trừ vùng phủ.

2) Cấu hình CP1243-7 (TIA Portal)

Địa chỉ Server/Port: đúng Public IP/Port của TCSB. Nếu qua NAT, đảm bảo port-forward và IP/port khớp 100%.
Giám sát kết nối (Connection Monitoring): bật và đặt thời gian Keep-Alive (ví dụ 30–60 s).
→ Lưu ý: đặt Idle timeout trên router/firewall > 2× Keep-Alive để tránh bị đóng phiên.
Tự động nối lại (Auto Reconnect): bật, giảm “reconnect delay” (ví dụ 10–30 s) và tăng số lần retry.
Thời gian hệ thống: đồng bộ NTP; lệch giờ lớn đôi khi làm TCSB từ chối phiên.
Firmware CP1243-7: cập nhật bản mới nhất; nhiều bản cũ hay lỗi giữ kết nối GPRS lâu.
Tối ưu chu kỳ truyền: đừng gửi quá dày; gom dữ liệu, giới hạn tần suất sự kiện (debounce) để tránh “bão gói tin” khi mạng chập chờn.

3) Mạng & bảo mật đường truyền

Router/Firewall tại trạm: mở outbound đến IP/port TCSB; tắt SIP ALG/IDS chặn nhầm; tăng TCP session timeout (≥5 phút hoặc hơn keep-alive).
NAT/CGNAT của nhà mạng: nếu dùng SIM Internet bình thường có CGNAT, ưu tiên APN riêng (private APN/VPN) cho IoT để ổn định hơn.
Chất lượng tuyến: ping/jitter cao sẽ làm TCSB drop; cân nhắc VPN ổn định (IPSec/OpenVPN qua APN riêng) nếu có.

4) Phía TCSB (Server)

Log “Station status / Last contact / Disconnect reason”: xem có lý do time-out, auth fail, duplicate session, hay license limit.
Dung lượng & license: đủ số trạm, không chạm ngưỡng kết nối đồng thời.
Băng thông/CPU Server: cao quá cũng làm rớt hàng loạt phiên.
Port mapping: chắc chắn port listen khớp với port bạn khai báo ở CP1243-7.

5) Quy trình chẩn đoán nhanh (đi thực tế)

Tại trạm: đo RSSI và ghi log nguồn 24V trong lúc rớt.
Đổi SIM khác/nhà mạng khác và test 24–48h.
Tăng Keep-Alive (30–60 s), tăng TCP timeout trên router, bật Auto-reconnect ngắn.
Cập nhật firmware CP1243-7 + kiểm tra cấu hình APN.
Trên TCSB: đối chiếu thời điểm rớt trong Server log để biết nguyên nhân.

6) Cài đặt gợi ý (an toàn, dễ ổn định)

Keep-Alive CP1243-7: 30–60 s
Router TCP idle timeout: ≥ 180 s
Reconnect delay: 10–30 s, retry vô hạn hoặc ≥ 30 lần
NTP đồng bộ mỗi ngày; giới hạn tần suất gửi sự kiện đột biến

Nếu bạn gửi ảnh chụp Diagnostic Buffer của CP1243-7 (TIA Portal/Online) và log TCSB quanh thời điểm rớt (timestamp, “reason code”), mình sẽ đọc ngay và chỉ ra đúng điểm gây mất kết nối (APN/timeout/keep-alive/nguồn/sóng).

time số này là tham số gì

Mình thấy bạn đang mở Configuration and Monitoring Tool (CMT) của CP1243-7.
Phần bạn hỏi là tab Cyclic services → Cycle time (trong cấu hình Teleservice connection).

👉 Ý nghĩa tham số:

Cycle time (phút): đây là chu kỳ mà CP1243-7 sẽ tự động gửi bản tin định kỳ (keep-alive/cyclic service) về cho TCSB.
- Nếu không có bản tin định kỳ, phía server (TCSB) hoặc nhà mạng có thể đóng phiên TCP/UDP vì cho rằng kết nối không còn hoạt động → dễ gây hiện tượng “mất kết nối / rớt tín hiệu”.
- Mặc định Siemens thường để khá dài (ví dụ 360 phút trong hình của bạn), tức là cứ 6 tiếng mới gửi một bản tin cyclic → dễ dẫn đến việc kết nối bị timeout trên firewall/router/nhà mạng.
Start time: thời điểm bắt đầu lần gửi đầu tiên (theo giờ hệ thống). Thường để 00:00 để đồng bộ từ nửa đêm.
Cyclic exchange of process data: nếu tick thì trong gói cyclic service có kèm theo dữ liệu tiến trình (process values).
Status data and time-of-day synchronization: nếu tick thì kèm cả trạng thái + đồng bộ thời gian về server.

🔧 Khuyến nghị thực tế để tránh rớt kết nối:

Giảm Cycle time xuống còn 5–15 phút thay vì 360 phút.
Bật ít nhất Status data and time-of-day synchronization để TCSB luôn nhận được heartbeat.
Nếu mạng yếu, nên bật cả Cyclic exchange of process data để gói tin có payload đều đặn.
Phía TCSB/Router nên để TCP session timeout ≥ 2× Cycle time.

👉 Tóm lại: Cycle time = khoảng thời gian giữa hai bản tin “heartbeat/cyclic message” từ CP1243-7 đến TCSB.
Nếu bạn để quá dài (360 phút), kết nối rất dễ bị mất do timeout.

Bạn muốn mình gợi ý luôn giá trị Cycle time tối ưu (ví dụ 5 hay 10 phút) cho trường hợp mạng di động (3G/4G) để ổn định hơn không?

👍 Với mạng di động (3G/4G, LTE) kết nối CP1243-7 ↔ TCSB thì kinh nghiệm thực tế như sau:

Giá trị khuyến nghị cho Cycle time

5 phút (300 giây) → an toàn nhất, TCSB luôn có heartbeat, hầu như không bị timeout.
10 phút (600 giây) → cũng ổn định, giảm tải lưu lượng nhưng vẫn giữ kết nối tốt.
Tránh để >30 phút vì nhiều nhà mạng hoặc firewall sẽ đóng session nếu không thấy gói tin.

Các tùy chọn nên bật:

✅ Status data and time-of-day synchronization (để server luôn thấy trạng thái + đồng bộ giờ).
(Tùy nhu cầu) Cyclic exchange of process data nếu muốn gửi dữ liệu tiến trình đều đặn, nhưng không bắt buộc.

Lưu ý thêm:

Trên Router/Firewall: chỉnh TCP idle timeout ≥ 2× Cycle time. Ví dụ nếu đặt 5 phút, thì timeout nên ≥ 10–15 phút.
Nếu hệ thống nhiều trạm, nên chọn 10 phút để giảm lưu lượng tổng, nhưng nếu mạng hay chập chờn → nên dùng 5 phút.

👉 Tóm gọn: bạn nên đặt Cycle time = 5 hoặc 10 phút thay vì 360 phút như trong hình để tránh rớt tín hiệu.

Bạn muốn mình viết luôn cấu hình mẫu (CMT + TIA Portal) cho một trạm với cycle time 5 phút + auto reconnect không giới hạn retry không?

Rồi 👍, mình hướng dẫn bạn cấu hình mẫu để CP1243-7 kết nối TCSB ổn định hơn nhé:

1. Trong CMT (Configuration and Monitoring Tool)

Vào Connections → Chọn Station → Tab Cyclic services
- Cycle time: đặt 5 phút (300 giây).
- Start time: 00:00 (giữ mặc định).
- Tick Status data and time-of-day synchronization.
- (Tùy chọn) Tick Cyclic exchange of process data nếu muốn gửi dữ liệu chu kỳ, còn nếu chỉ cần heartbeat thì có thể bỏ.

2. Trong TIA Portal (CP1243-7 Properties)

Communication monitoring:
- Bật Connection monitoring.
- Thời gian giám sát (Supervision time) nên đặt 60–90 giây.
Automatic reconnect:
- Enable Auto-reconnect.
- Reconnect delay: 10–30 giây.
- Retry count: 0 (unlimited) hoặc ≥ 30.

3. Trên Router/Firewall/Server

TCP session idle timeout ≥ 600–900 giây (tức gấp 2–3 lần cycle time).
Mở đúng port cho TCSB, tắt các tính năng “aggressive timeout / SIP ALG / IDS” gây ngắt kết nối.

4. Kết quả mong đợi

Mỗi 5 phút CP1243-7 sẽ gửi heartbeat → Server không bị timeout.
Nếu mất sóng hoặc reboot router, CP1243-7 sẽ tự reconnect sau 10–30 giây.
TCSB sẽ luôn hiển thị trạng thái trạm RUN/Available, ít bị “Disconnected”.

👉 Nếu bạn muốn, mình có thể vẽ sơ đồ cấu hình kết nối mẫu (CP1243-7 ↔ Router ↔ Internet ↔ TCSB) kèm thông số gợi ý để bạn set nhanh. Bạn có muốn mình làm thêm sơ đồ đó không?

tham số này là gì

Mình thấy bạn đang ở tab Communication monitoring trong cấu hình kết nối của CP1243-7 (CMT).
Các tham số bạn đánh dấu là:

1. Keepalive timeout (phút)

Đây là khoảng thời gian tối đa mà TCSB không nhận được bất kỳ dữ liệu/heartbeat nào từ CP1243-7.
Nếu quá thời gian này, server sẽ coi như mất kết nối và báo trạm “Disconnected”.
Ví dụ bạn đặt = 15 phút → nếu trong 15 phút liên tục không có gói tin, thì TCSB sẽ cắt phiên.

👉 Thực tế nên đặt ngắn hơn chu kỳ mạng cho chắc (thường 5–10 phút).
Nếu cycle time = 5 phút thì keepalive timeout nên ≥ 2× cycle time (tức 10–15 phút).

2. Tolerance time (phút)

Đây là khoảng thời gian “gia hạn” thêm sau khi hết keepalive timeout, trước khi TCSB chính thức kết luận mất kết nối.
Ví dụ:
- Keepalive timeout = 15 phút
- Tolerance time = 1 phút
  → Tổng thời gian chờ = 16 phút.

Nếu trong khoảng này mà CP1243-7 gửi được bản tin lại thì kết nối sẽ được coi là còn sống.

✅ Tóm lại:

Keepalive timeout = ngưỡng giám sát chính.
Tolerance time = khoảng “du di” thêm.

🔧 Khuyến nghị thực tế cho mạng di động:

Keepalive timeout: 10–15 phút.
Tolerance time: 1–2 phút.
Cycle time (ở tab Cyclic services): 5 phút.

Như vậy bạn sẽ có:

Mỗi 5 phút gửi heartbeat.
Server chỉ báo mất kết nối nếu 15+1 = 16 phút không nhận được gì.

Bạn có muốn mình đề xuất luôn combo cấu hình tối ưu (Cycle time + Keepalive timeout + Tolerance time) để vừa không rớt mạng, vừa tránh “spam” dữ liệu?

rất hay bị dis mạng trong khi sóng rất tốt

Ok 👍 cảm ơn bạn chia sẻ thêm. Nếu sóng (RSSI) tốt mà CP1243-7 vẫn hay bị disconnect, thì nguyên nhân không phải do phủ sóng nữa mà thường nằm ở các yếu tố sau (mình tóm rất thực tế để bạn khoanh vùng nhanh):

🔎 Các nguyên nhân hay gặp khi sóng tốt nhưng vẫn bị rớt

Timeout / Keepalive chưa tối ưu
- Bạn đang để Cyclic service = 360 phút → quá dài.
- Router/nhà mạng thường có TCP idle timeout 5–30 phút → kết nối bị drop giữa chừng.
- Giải pháp: đặt Cyclic service = 5 phút, Keepalive timeout = 10–15 phút, Tolerance = 1–2 phút.

CGNAT / NAT của SIM di động
- SIM Internet bình thường thường dùng CGNAT (Carrier Grade NAT). Khi không có traffic trong 5–10 phút, NAT entry bị xóa → rớt kết nối.
- Giải pháp:
  - Dùng SIM M2M / IoT chuyên dụng hoặc APN riêng.
  - Nếu không có, thì bắt buộc giữ traffic đều đặn (chu kỳ 5 phút như trên).

Firmware CP1243-7 lỗi
- Một số firmware cũ của CP1243-7 có bug giữ kết nối LTE lâu → bị rớt ngẫu nhiên.
- Giải pháp: update firmware mới nhất từ Siemens Support.

Nguồn 24V không ổn định
- CP1243-7 khi phát sóng LTE tiêu thụ dòng cao. Nếu nguồn không đủ dòng (hoặc có ripple), nó reset module LTE → disconnect.
- Giải pháp: đo log nguồn bằng oscilloscope khi trạm rớt, hoặc thử nguồn 24VDC công suất cao, có tụ buffer.

Server TCSB quá tải hoặc session timeout
- Nếu TCSB xử lý nhiều trạm, CPU/băng thông cao có thể làm rớt session.
- Giải pháp: kiểm tra log TCSB “Disconnect reason” để biết rớt do timeout hay reject.

✅ Combo cấu hình khuyến nghị (ổn định nhất cho 3G/4G)

Cycle time (Cyclic services): 5 phút
Keepalive timeout: 10 phút
Tolerance time: 1–2 phút
Auto reconnect delay: 10–30 giây, Retry count = unlimited
Nguồn 24V ≥ 2A, có tụ buffer 4700–10000 µF

👉 Nếu bạn gửi thêm ảnh phần Diagnostic Buffer của CP1243-7 trong TIA Portal lúc bị rớt, mình sẽ chỉ ra ngay là do timeout / reboot / modem reset / server reject.

Bạn có muốn mình hướng dẫn cách bật log chi tiết trên CP1243-7 và TCSB để xác định nguyên nhân chính xác không?

CP1243-7 công suất bao nhiêu

Mình trả lời chi tiết luôn nhé 👇

📡 Thông số điện năng của CP1243-7 GPRS/LTE (Siemens)

Nguồn cấp: 24 V DC (dải chấp nhận ~19.2 … 28.8 V DC).
Dòng tiêu thụ trung bình: khoảng 0.25 … 0.35 A @ 24 VDC (tức ~6–8 W).
Công suất cực đại khi phát sóng (burst LTE/GPRS): có thể lên tới 0.6–0.8 A trong vài ms (~15–20 W peak).

👉 Điều này có nghĩa là:

Bình thường CP1243-7 chỉ “ăn” ~6–8 W.
Nhưng khi modem bật công suất phát LTE/GPRS, dòng nhảy vọt gần 1 A.
Nếu nguồn 24 V không đủ công suất hoặc không có tụ buffer → điện áp sụt, module reset → gây mất kết nối dù sóng tốt.

🔧 Khuyến nghị về nguồn

Nguồn 24 VDC tối thiểu 2 A cho cả PLC + CP1243-7.
Gắn thêm tụ buffer 4700–10000 µF/35V gần CP1243-7 để chống sụt áp khi phát sóng.
Nếu trạm xa, dây dài → kiểm tra sụt áp tại CP.

👉 Nhiều ca thực tế mình gặp: sóng báo -70 dBm (rất tốt) nhưng cứ vài chục phút rớt → nguyên nhân chính là nguồn không chịu nổi dòng xung khi CP1243-7 phát LTE, chứ không phải do mạng.

Bạn có muốn mình chỉ cách test nhanh nguồn CP1243-7 bằng TIA Portal (diagnostic supply voltage) và đồng thời đo bằng đồng hồ/oscilloscope để chắc chắn có phải nguyên nhân nguồn hay không?

Keepalive timeout: tôi để 360 phút được không

Nếu bạn để Keepalive timeout = 360 phút (6 tiếng) thì gần như chắc chắn kết nối sẽ bị rớt trước khi hết 6 tiếng ✅.

Lý do:

Nhà mạng / CGNAT:
- Thường chỉ giữ NAT session 5–30 phút nếu không có gói tin.
- Sau đó sẽ tự đóng → CP1243-7 vẫn nghĩ còn kết nối, nhưng TCSB không liên lạc được nữa.
Router / Firewall:
- TCP idle timeout mặc định thường 300 giây (5 phút) hoặc 600 giây (10 phút).
- Nếu không có traffic, router sẽ xóa session.
TCSB:
- TCSB cần heartbeat định kỳ để biết trạm còn sống.
- Nếu không thấy dữ liệu lâu (ví dụ >15 phút) sẽ báo mất kết nối.

📌 Khuyến nghị thực tế

Keepalive timeout: 10–15 phút (an toàn).
Cyclic service: 5 phút (để đảm bảo có gói tin đều đặn).
Tolerance: 1–2 phút.

👉 Như vậy TCSB chỉ báo Disconnect khi >11–17 phút không có dữ liệu, vừa đủ để tránh rớt giả, vừa ngắn hơn nhiều so với 360 phút.

⚠️ Nếu bạn để 360 phút thì:

Mạng di động và router chắc chắn sẽ đóng phiên trước khi tới 6 tiếng.
Kết quả: trạm sẽ thường xuyên bị dis, dù sóng rất tốt (đúng tình huống bạn gặp).

Bạn có muốn mình gửi cho bạn bộ cấu hình mẫu hoàn chỉnh (Cycle time, Keepalive timeout, Tolerance, Auto reconnect) để copy theo luôn không?

cái này là gì

Trong hình bạn gửi là phần Cyclic services của CP1243-7 (CMT). Hai tùy chọn đó có ý nghĩa như sau:

1. Cyclic exchange of process data

Nếu tick chọn, CP1243-7 sẽ gửi dữ liệu tiến trình (process values từ PLC, ví dụ các Tag bạn mapping) định kỳ theo chu kỳ bạn đặt ở “Cycle time” (5 phút, 10 phút, v.v.).
Dùng khi bạn muốn TCSB nhận được dữ liệu giá trị biến của PLC đều đặn, ngay cả khi không có thay đổi hay sự kiện.
Nếu bỏ chọn → dữ liệu chỉ gửi khi có sự kiện kích hoạt hoặc yêu cầu, không gửi đều.

2. Status data and time-of-day synchronization

Nếu tick chọn, CP1243-7 sẽ gửi trạng thái trạm + đồng bộ thời gian (time sync) về cho TCSB theo chu kỳ.
Lợi ích:
- TCSB luôn thấy trạng thái online/offline, CPU mode, v.v.
- Đồng bộ thời gian hệ thống giữa PLC/CP và TCSB (quan trọng nếu cần log sự kiện đúng timestamp).
Nếu bỏ chọn → TCSB không có heartbeat trạng thái, dễ khó giám sát online.

✅ Thực tế triển khai Telecontrol (TCSB):

Nên tick chọn “Status data and time-of-day synchronization” để server luôn có heartbeat.
Còn “Cyclic exchange of process data” thì tùy nhu cầu:
- Nếu muốn dữ liệu quá trình được cập nhật đều → bật.
- Nếu muốn tiết kiệm lưu lượng GPRS/4G → bỏ, chỉ dùng event-based.

👉 Tóm gọn:

Cyclic exchange of process data = gửi dữ liệu PLC định kỳ.
Status data and time-of-day synchronization = gửi trạng thái + đồng bộ thời gian định kỳ.

Bạn có muốn mình đề xuất check cái nào bắt buộc, cái nào nên để optional cho ứng dụng SCADA giám sát qua TCSB để vừa ổn định vừa không tốn nhiều dung lượng SIM không?

trạm số 3 tôi bị như trên là sao

Nhìn cột Status trong CMT:

✅ Dấu tick xanh: kết nối TCSB của trạm đang OK/Online.
⚠️ Tam giác vàng: có cảnh báo nhẹ (ví dụ mới chỉnh cấu hình chưa “Save & activate”, hoặc có cảnh báo nhưng vẫn online).
❌ Vòng tròn đỏ có dấu X (trạm số 3 của bạn): kết nối đang lỗi/Disconnected.

Vì sao trạm 3 bị ❌?

Thường do một trong các lỗi sau (phổ biến nhất từ trên xuống):

Sai/không khớp khóa mã hóa HC-128 giữa CP và TCSB.
Sai IP/Port server hoặc NAT/forwarding không đúng.
APN/SIM: APN sai, SIM hết data/bị chặn, chưa đăng ký mạng.
Timeout: Keepalive/Cycle time quá dài → session bị nhà mạng/router đóng.
Trùng Station number (hiếm) hoặc license TCSB không đủ.
Nguồn 24V sụt làm modem LTE reset.

Kiểm tra nhanh để biết đúng lỗi gì

Chọn Station 3 → tab “Activated parameters”: xem Last connection / Disconnect reason.
Chọn Station 3 → tab “Communication monitoring”: tạm đặt
- Keepalive timeout = 10–15 phút, Tolerance = 1–2 phút.
- Cyclic services = 5–10 phút và tick Status data and time-of-day synchronization.
Vào Encryption: so khớp Key/Passphrase với phía TCSB (gõ lại cả 2 bên).
Kiểm tra APN/SIM trên CP: lắp SIM khác thử 15–30 phút.
Xem Diagnostic Buffer của CP1243-7 trong TIA Portal để tìm mã lỗi (auth fail, no network, timeout…).
Trên router/firewall: bảo đảm port out tới TCSB mở, TCP idle timeout ≥ 10–15 phút.

Nếu bạn chụp giúp mình phần Activated parameters (Disconnect reason) hoặc Diagnostic Buffer của trạm 3, mình sẽ đọc và chỉ ra chính xác nó rớt do mã hóa/APN/timeout hay do nguồn nhé.

Nội dung chính

tcsb

1) Lớp vật lý & sóng di động

2) Cấu hình CP1243-7 (TIA Portal)

3) Mạng & bảo mật đường truyền

4) Phía TCSB (Server)

5) Quy trình chẩn đoán nhanh (đi thực tế)