寫 PLC 程式時，在規劃 FB (Function Block) 或 FC (Function) 前，我主要會考慮以下 3 個因素。
1. 要解決什麼問題
先把問題定義出來，這個問題描述的越具體越好，而且一次解決一個問題就好。把大問題拆成小問題，再各個擊破。有時候大問題看起來很難，但把問題拆開之後就知道程式要怎麼寫了。
如果這個 FB 只能輸出一個變數的話，那是什麼？
例如：獲取 AI 模組當前接收到的工程數值。白話文是想要知道這個 PH 計現在的數值是多少。
我個人的習慣是會再加入 [斷線設定值] 和 [斷線警報]，然後會另外做段位警報。因為每個專案需求的警報數量都不一樣，或是有的會把警報點 (HH, H, L, LL) 和控制點 (H1, H2, M1, M2, L1, L2) 分開，警報歸警報，控制歸控制。
2. 重複性高
這是建立 FB / FC 最大的優點，相同的功能可以重複呼叫使用。寫 FB 有點像是在刻印章，如果只有一本聯絡簿要簽，手寫簽完就好了，還比較快；如果每天都有 30 本作業簿要看，花一點時間刻個印章會更有效率。重複使用超過 3 次以上的功能，我就會考慮做成 FB / FC。
另一個好處是方便修改。假設同類型的馬達有 20 個，不包成 FB 就要寫 20 次，後續要刪減功能的話，每一次都要改 20 遍；做一個 FB 的話，雖然前期要花一點時間規劃，但之後的修改只要針對 FB 修改就好，新功能就會套用到 20 個馬達上。好比在中文章下方新增刻了英文，之後蓋出去的印就都會有中英文。
3. 變動性低
重複性高，變動性低的功能，會優先考慮做成 FB / FC。因為各家 PLC 廠商線上修改 FB 都有限制。因此 FB 的規劃和測試越完善，就能夠減少後期修改 FB 的頻率和次數。
以 AB PLC ControlLogix, CompactLogix 系列來說，他們的 FB 叫做 AOI (Add-On Instructions)，而且沒有 FC，就是只能用 FB 的意思。AOI 的其中一個限制就是不能線上修改，要修改就要停機重新下載程式。
Siemens 的 PLC 可以線上修改 FB，但要注意如果內部變數的數量或型態有變化，Instance DB 的變數位址會移動。常見的解決方式是在規劃 FB 時會預留各種型態的內部變數在 STAT (Spare Bool, Int, Real)，或是一開始就專門規劃一個 Global DB 給其他的 PLC, HMI 讀取資料，多一道 Mapping 的工，但修改上會更有彈性。
下一篇《建立 FB / FC 的三個考量-舉例》會舉 Pump 的控制做範例，進一步說明我的想法。
