演算我也在做, 之前就舉例一個先空轉跑檢測後幫操作者先抓上下限跟列表.
只是那個到上限時要檢出的元件, 到下限檢出的元件, 中間讀取間隔的元件.
送去一個單元用window base然後自己跑公式找最佳曲線然後顯示建議給操作者.
機械擺動是弧線但計算上要簡易就是線性, 總總規劃與構思要越接近真實越好.
講到這裡就知道一個組織的力量有窮時, 有時候並不是要不要自己做的問題.
window base人機我就沒辦法自己做, 要找專門的來配合.
開發出來我當然會去壟斷, 只要給的分紅很好, 配合廠商也開心, 而不是反過來.

希望說明到這個程度夠清楚明白了, 元件設計與結構設計的不同.
B兄講的其實也OK, 只是那不是絕大多數, 再者新加入的"元件"也是外購的.
如果要說開發, 我是真的認為從原料才是開發, 目前本人也在努力這一點.
跟配合廠商回報使用訊息, 協助其開發特製給我用的物料.
要願意花時間跟配合廠商的人開技術研討, 給他們利潤(動力).
但, 這樣來說就不能算是自己開發了, 至少以我的標準來說就不算.

我回應只是路過突然想到那句玩笑話而已，其實那是我做軟體開發的一個觀點，既然你這麼在意我就花點時間講一下，雖然有上過正式自動控制課程與實習，但是我認為我不懂這行業，所以我會用我比較熟的軟體來比喻，當然我不清楚這想法是否能套用到自控，參考看看吧。
在軟體開發上，我們也大多會傾向於使用現成元件或函式庫，因為大多數元件跟函式庫都是經過千鎚百煉與最佳化過，如一個最簡單的 quicksort，自己寫一個很難會比現成的好，因為那些東西大都有一個團體或是廠商投入許多人力在維護的。
但是軟體開發的迷人之處，就在於你可以打造自己想要的東西，今天如果一個函式甚至是開發工具不符需求，你可以自己打造特定函式或工具來使用，這也就是我說的 make your own tools，但是相對的，你也要能夠承擔自己開發所帶來的風險，因為用自己寫的，可能符合特定需求，但是執行效率也很可能不如現成的，這就是 eat your own shit。(我怕被誤會在酸人，所以之前在這句加上是開玩笑，其實只能算是半開玩笑)
所以到底哪一種方法好，是用現在的東西好？還是用自己做的東西好？很明顯的沒有標準答案，而是要依照真正的需求來做決定。
有時候不同的意見，可能只是看東西角度不同而已，並沒有誰對誰錯或是誰是絕對正確的，這也正是網路的可愛之處，只要不是惡意攻擊或謾罵，每個人都有表達自己觀念跟想法的權利，先不要急著否定別人，也許別人可以提供你不同的思考方向。
別人的 bala bala 不見得是 ear storm，能靜下心來看也很可能是 brain storm
當然，我也不認為我的想法是正確的，只是從我的角度來看是這樣的。

其實我一直強調的概念是：「當買不到某個元件時，該怎麼辦？」
這時候，未必找的到技轉單位來幫你的忙！
如果老闆又很在意這個案子，不容許你兩手一攤怎麼辦？
有的人就會自動在腳下畫紅線，不敢跨過去。
有的人則開始翻書、找論文，積極面對問題，試圖解決之。
我只不過是建議當個後者罷了！

這裡講的「元件」，可能是一個電路、一個機構、一個控制器，
也可能是一段程式，或是一個演算法。擴大而言，當然也可以
適用於其他領域的「元件」。

幾篇下來，我想我已經說的夠多了，
我從來都沒有意思要說：「要會做每一個元件！」
能看懂的，應該都懂了；看不懂的，我也無能為力。
能認同的，就謝謝您的認同；不認同的，還是謝謝您的閱讀。
連佛都只能度有緣人，我何德何能可以取悅所有人？
只不過在「自控」領域裡打滾了多年，與大家分享一些經驗罷了！