Mục lục
Trả lời ngắn: Signal Engine trong EA là bộ phận đọc một bản chụp dữ liệu, tính các đặc trưng rồi kiểm quy tắc để tạo ứng viên tín hiệu có bằng chứng. Nó chỉ báo điều kiện vừa xuất hiện, đang chờ hay dữ liệu không hợp lệ; nó không tự gửi yêu cầu giao dịch.
Đọc xong, bạn sẽ hiểu:
- Vì sao điều kiện đang đúng chưa chắc là tín hiệu mới.
- Khi nào bar đang chạy làm kết quả đổi liên tục.
- Cách Signal Engine chống phát trùng trên nhiều tick.
- Một candidate cần mang theo bằng chứng gì.
Lưu ý giáo dục: Fast/slow và mọi số trong bài chỉ là dữ liệu giả, không phải chiến lược, tín hiệu mua bán hay lời hứa lợi nhuận.
1. Signal Engine làm gì và dừng ở đâu
a. Nhận dữ liệu, trả một ứng viên
Một snapshot, hay bản chụp, gom các dữ liệu cần thiết tại cùng một thời điểm: mã sản phẩm, khung thời gian, thời gian bar, giá và giá trị chỉ báo. Signal Engine đọc snapshot đó, tạo feature — đặc trưng được tính từ dữ liệu — rồi áp rule, tức quy tắc so điều kiện.
Nếu rule vừa chuyển từ sai sang đúng, engine có thể tạo candidate — ứng viên tín hiệu chờ các bộ phận sau kiểm tiếp. Candidate phải có evidence, tức bằng chứng gồm dữ liệu nguồn, rule version, thời gian và mã nhận diện. Nó không chỉ là một chữ “đúng”.
Ba output nên tách rõ:
CANDIDATE: có sự kiện mới và đủ bằng chứng;WAIT: dữ liệu hợp lệ nhưng chưa có sự kiện mới;INVALID_DATA: dữ liệu thiếu, cũ hoặc lỗi nên không được kết luận.
Event, hay sự kiện, là điều vừa xảy ra theo rule. WAIT đã đủ dữ liệu nhưng chưa có event mới; INVALID_DATA chưa đủ bằng chứng để quan sát.
b. Level khác edge
Level là trạng thái một điều kiện đang đúng, ví dụ fast line vẫn cao hơn slow line. Edge là khoảnh khắc điều kiện đổi từ sai sang đúng, ví dụ fast vừa đi từ thấp hơn hoặc bằng sang cao hơn slow.
Hãy nghĩ tới chuông cửa. Nút đang bị giữ là level; khoảnh khắc vừa bấm là edge. Gia chủ cần một tiếng chuông cho một lần bấm, không cần hàng trăm tiếng vì nút còn bị giữ.
Hình 1 — Level có thể kéo dài nhiều tick; edge chỉ xuất hiện tại lần chuyển điều kiện.
c. Không ôm việc của engine khác
Signal Engine không kiểm giờ giao dịch, tin tức, mức rủi ro, ký quỹ hoặc quyền gửi yêu cầu. Filter Engine ở bài #8 kiểm bối cảnh; Risk Engine ở bài #9 kiểm chính sách rủi ro; bộ phận thực thi mới gửi yêu cầu giao dịch.
Trong sơ đồ, order là yêu cầu gửi tới hệ thống thực thi; candidate chưa phải order.
2. Pipeline sáu bước từ snapshot đến candidate
a. Bước 1 — Khóa hợp đồng snapshot
Snapshot ghi symbol, timeframe, thời gian dữ liệu, quy tắc chọn bar và phiên bản chiến lược. Symbol là mã sản phẩm; timeframe là khoảng tạo một bar (nến dữ liệu).
Tài liệu MQL5 cho biết index 0 trong timeseries là bar thuộc khoảng thời gian chưa hoàn tất. Vì vậy, “bar 0” có thể đổi trước khi đóng; “bar 1” thường là bar vừa hoàn tất khi đọc theo kiểu timeseries. Timeseries and Indicators Access
Đọc bar 0 không tự động sai; sai là ghi quy tắc “bar đã đóng” nhưng lại dùng bar đang chạy.
b. Bước 2 — Kiểm dữ liệu và tính feature
Indicator handle là mã tham chiếu tới bộ tính chỉ báo. iMA() trả handle hoặc INVALID_HANDLE khi thất bại; handle không phải giá trị chỉ báo. iMA
Buffer là vùng dữ liệu đầu ra của chỉ báo. Trước khi dùng, engine kiểm:
- handle hợp lệ;
BarsCalculated()cho biết đã tính đủ dữ liệu;CopyBuffer()trả đúng số phần tử yêu cầu;- mọi giá trị là số hữu hạn;
- dấu thời gian khớp quy tắc chọn bar.
CopyBuffer() dùng start_pos=0 từ bar hiện tại, trả số phần tử đã sao chép hoặc -1 khi lỗi. Lịch sử chưa sẵn thì chưa tạo candidate. CopyBuffer, BarsCalculated
c. Bước 3–4 — Kiểm rule rồi tìm edge
Rule demo dùng hai đường fast và slow:
prev_fast ≤ prev_slow AND last_fast > last_slow
Vế đầu chứng minh điều kiện chưa đúng ở bar trước; vế sau chứng minh nó đúng ở bar vừa đóng. Cần cả hai mới gọi là CROSS_UP.
d. Bước 5–6 — Chống trùng và đóng gói evidence
Dedupe, hay chống trùng, kiểm một signal ID — mã nhận diện duy nhất cho sự kiện. Demo:
demo-v1:X:M5:10:05:CROSS_UP
Mã ghép phiên bản chiến lược, symbol, timeframe, thời gian bar nguồn và event. Mã đã phát thì trả WAIT_ALREADY_EMITTED. Candidate mới ghi các giá trị, phiên bản, ID, thời điểm và reason code (mã lý do) để tái hiện quyết định.
Hình 2 — Candidate chỉ xuất hiện sau khi dữ liệu sẵn, rule tạo edge và signal ID chưa tồn tại.
3. Case demo: hai bar, ba tick và một signal
a. Hai bar đã đóng
Giả sử quy tắc demo chỉ đánh giá bar đã đóng:
| Source bar | Fast | Slow | Quan hệ |
|---|---|---|---|
| 10:00 | 100 | 101 | fast ≤ slow |
| 10:05 | 102 | 101 | fast > slow |
Hai vế của rule đều đúng, nên event là CROSS_UP. Engine tạo ID demo-v1:X:M5:10:05:CROSS_UP và output CANDIDATE.
Phép so chỉ chứng minh crossover trong snapshot demo, không chứng minh hướng giá hoặc lợi nhuận.
b. Tick kế tiếp không phải signal mới
Tick sau vẫn là 102/101, bar nguồn không đổi. Dedupe thấy ID cũ nên trả WAIT_ALREADY_EMITTED, giống máy chấm công không tạo thêm ca khi đọc lại cùng thẻ.
c. Bar 0 có thể đổi ba lần
Trong bar đang chạy, fast có thể đi 100,8 → 102,2 → 100,7 khi slow là 101. Với quy tắc bar đã đóng, engine chờ. Chiến lược dùng intrabar (ngay trong bar đang chạy) phải ghi nguồn tick, cách chống trùng và điều kiện hủy; bar đã đóng không phải luật chung.
d. Điều chắc và điều có điều kiện
Có thể nói chắc hai dòng demo thỏa phép so. Candidate chỉ hợp lệ nếu handle, buffer count, timestamp, rule version và dedupe state đều đúng. Phát hiện timestamp lệch thì phải nhận sai và trả INVALID_DATA.
4. Sáu lỗi phổ biến và giới hạn phải nhớ
a. Gọi level là crossover
fast > slow chỉ cho biết quan hệ hiện tại. Thiếu cặp giá trị trước/sau thì chưa chứng minh lần chuyển.
b. Đọc bar 0 nhưng ghi nhãn closed bar
Bar 0 có thể đổi trước khi hết timeframe. Dùng bar 1 thì phải khóa index và source bar time trong evidence.
c. Copy thiếu mà vẫn dùng
Yêu cầu hai giá trị nhưng copy được một là chưa đủ. Không dùng ô cũ hoặc zero mặc định; trả INVALID_DATA.
d. Quên vòng đời handle
Tạo handle mỗi tick làm khó theo dõi readiness, tức trạng thái dữ liệu đã sẵn sàng. Hãy tạo ở giai đoạn khởi tạo, kiểm lỗi và giải phóng khi thôi dùng.
e. Phát lại trên mọi tick
Không có signal ID, một bar có thể tạo hàng trăm candidate. Khóa chống trùng phải gắn với nguồn và khôi phục được sau khi EA khởi động lại.
f. Signal tự biến thành yêu cầu
Candidate chưa qua bộ lọc, kiểm tra rủi ro và quyền thực thi. Gửi yêu cầu tại đây sẽ trộn phát hiện với hành động.
Giới hạn: chỉ báo biến đổi dữ liệu quá khứ/hiện tại. Pipeline nhất quán không chứng minh rule có lợi thế hay bảo đảm tương lai.
5. Checklist và Signal Evidence Card 15 phút
a. Mười hai câu kiểm tra
- Snapshot lấy symbol và timeframe nào?
- Policy dùng bar đang chạy hay bar đã đóng?
- Source bar time có được lưu không?
- Handle có hợp lệ không?
BarsCalculated()đã đủ chưa?CopyBuffer()trả đúng số lượng không?- Giá trị trước và sau có hữu hạn không?
- Rule mô tả level hay edge?
- Strategy version đã khóa chưa?
- Signal ID gồm đủ nguồn và event chưa?
- ID đã từng phát chưa?
- Output là candidate, wait hay invalid; bộ phận nhận tiếp là ai?
Điểm dừng rất rõ: thiếu một trong các bằng chứng 3–7 thì trả INVALID_DATA. Rule không có edge mới hoặc ID đã tồn tại thì WAIT. Signal Engine không tự sửa bằng cách lấy số cũ.
Hình 3 — Evidence Card cho biết candidate đến từ dữ liệu nào và engine nào nhận tiếp.
b. Bài tập miễn phí, chưa dùng tiền thật
Dùng giấy hoặc Google Sheets trong 10–15 phút. Không mở MetaTrader, không gửi yêu cầu và không dùng tiền thật.
c. Mẫu đối chiếu
| Field | Demo value |
|---|---|
| Strategy version | demo-v1 |
| Symbol/timeframe | X / M5 |
| Previous closed bar | 10:00 · fast 100 · slow 101 |
| Last closed bar | 10:05 · fast 102 · slow 101 |
| Rule | prev_fast ≤ prev_slow AND last_fast > last_slow |
| Event | CROSS_UP |
| Signal ID | demo-v1:X:M5:10:05:CROSS_UP |
| Duplicate check | NEW |
| Output | CANDIDATE |
| Next owner | Filter Engine |
Tự làm hai biến thể:
- giữ cùng source bar và đánh dấu ID đã tồn tại: output
WAIT_ALREADY_EMITTED; - giả sử buffer chỉ trả
1/2giá trị: outputINVALID_DATA.
Kết quả bài tập là một card đã điền và hai mã lý do. Nó không phải “signal tốt” cho giao dịch thật.
6. Tổng kết: signal là candidate, không phải order
a. Năm ý chính
- Signal Engine biến snapshot thành candidate có bằng chứng.
- Level là điều kiện đang đúng; edge là lần chuyển từ sai sang đúng.
- Bar 0 đang chạy có thể đổi; quy tắc chọn bar phải được ghi trong hợp đồng dữ liệu.
- Handle, độ sẵn sàng, số phần tử buffer và dấu thời gian phải đạt trước khi đánh giá rule.
- Signal ID chống phát trùng; candidate vẫn phải đi qua Filter, Risk và Execution.
Bài trước là Money Management Engine trong EA. Bài tiếp theo là Filter Engine trong EA #8.
b. Câu hỏi tự kiểm tra
- Vì sao
fast > slowchưa đủ chứng minh crossover? WAITkhácINVALID_DATAở đâu?- Vì sao bar 0 cần được ghi rõ trong quy tắc?
- Signal ID nên chứa những gì?
c. Gợi ý đáp án
Xem gợi ý câu 1
Cần cả quan hệ ở bar trước và bar sau để chứng minh lần chuyển. → xem mục 2.
Xem gợi ý câu 2
WAIT đã đủ dữ liệu nhưng không có event mới; INVALID_DATA chưa đủ bằng chứng. → xem mục 1.
Xem gợi ý câu 3
Bar 0 chưa hoàn tất nên giá trị có thể đổi trước khi đóng. → xem mục 3.
Xem gợi ý câu 4
Nên có phiên bản chiến lược, symbol, timeframe, thời gian bar nguồn và event. → xem mục 2.
d. Thuật ngữ cần nhớ
| Thuật ngữ | Giải thích ngắn |
|---|---|
| Snapshot | Bản chụp dữ liệu tại một thời điểm |
| Feature | Giá trị dẫn xuất từ dữ liệu nguồn |
| Rule | Quy tắc kiểm điều kiện |
| Candidate | Ứng viên tín hiệu chờ bước sau |
| Level | Trạng thái điều kiện đang đúng |
| Edge | Lần điều kiện chuyển từ sai sang đúng |
| Buffer | Vùng dữ liệu đầu ra của chỉ báo |
| Dedupe | Cơ chế chống phát trùng |
| Signal ID | Mã nhận diện một sự kiện tín hiệu |
e. Nguồn tham khảo
- MetaQuotes — Timeseries and Indicators Access
- MetaQuotes — CopyBuffer
- MetaQuotes — BarsCalculated
- MetaQuotes — iMA
- MetaQuotes — SymbolInfoTick
Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. EA có thể lỗi dữ liệu, logic và thực thi; thị trường luôn có rủi ro mất vốn.
Bài tiếp theo