The system installment is "locked before expiration", while the custom installment is "locked upon expiration" - this is more in line with real-life leasing scenarios. This article is encapsulated using Lua metatables to achieve precise timing triggering + dynamic passwords (the algorithm is externalized, without pre-stored static passwords).
1. Differences between the two schemes
| Dimensions | System scheme (pre-locked) | Custom scheme (locked upon expiration) |
|---|---|---|
| Trigger timing | Takes effect immediately after configuration | Locks only when current time ≥ deadline |
| User perception | Locked in advance | Locked just upon expiration |
2. Design points
- Dynamic Password: calculated in real-time by the external function password_func(date) (such as year + month + day), not pre-stored, to prevent reverse engineering
- Super Password: a single uint32, one-click global unlock, with on-site operation and maintenance as a backup
- Self-checking Hot Update: initiates detection of date changes, automatically rewrites and stores after configuration modifications
- State Persistence: time/switch/unlock progress stored in VT_RW non-volatile area, not lost during power loss
3. Instantiation (main.lua)
Stage.new(base_addr, stage_dates, password_func, super_password):
-- base_addr: VT_RW 起始地址，连续存储所有配置
-- stage_dates: 3期截止日期列表，必须递增
-- password_func: 密码计算函数
-- super_password: 超级密码
dofile("stage.lua")
g_stage = Stage.new(0x1000,
{{2023,11,1},{2023,12,1},{2024,1,1}},
function(d) return d[1]+d[2]+d[3] end,
123456)The module is implemented using closures + metatables OO, supporting 1~10 stages, with states fully stored in the RW area. The core decision-making function get_eligible_stage() strictly compares system time with the deadline, and only locks the screen if now ≥ deadline.
Compiled from Guangzhou Dacai Technology VisualHMI development documentation (hmi-doc.gz-dc.com) and other technical tutorials "Staged Application (RW-Custom)", copyright belongs to Dacai Technology.
Leave a Reply