產品切割誤差0.01毫米，原來是程序員代碼沒有控制好小數點精度

公司有個項目，需要在軟件上預設圖形，然后需切割圖形，切割精度為0.01毫米，最后根據切割出來的圖形對應到實體材料進行切割，但是，最后發現切割總是會出現些許誤差，當時沒注意，只是覺得這個誤差精度大約為0.01毫米左右，最開始，我們以為是用來切割器的切割精度有問題，但切割器廠家跟我們打包票，他們的切割器精度絕對沒有問題，那問題出在哪呢？

這個項目由三個人負責，分別是負責圖形定義和圖形切割的小高以及運動控制以及給切割器發命令的老常以及用來視覺標定切割器以及檢測切割精度的我。

本來這個問題是沒有被發現的，因為我的視覺部分只寫了切割器位置標定，切割精度的視覺模塊還沒上，而這天我正好開始測試我新寫好的切割精度檢測模塊，于是就讓小高和老常配合我，做了下切割。

結果，切割出來的產品精度差了0.01毫米，但是不是每次都這樣，有時候就是好的，精度一點不差。

我這邊早就和老常測試好了切割器位置標定這個功能，是沒有問題的，也就是說，切割器的安裝偏移老常這邊應該是已經補正過的了，重新做了下位置標定，發現切割器的位置是非常準的，位置精度能達到小數點后三位。

而切割后的產品，我們拿高精度卡尺卡了一下，發現我的檢測結果也非常準，而且檢測結果也能到小數點后三位。

這就排除了我機器視覺這塊的問題，然后我們就開始一個一個排除其他因素。

就像文中開始說的那樣，切割器廠家表示他們的切割器精度也不會存在問題，并且我們用切割器廠家原廠的軟件試了一下，的確如他們所說，切割精度是能保證0.01毫米這個精度的。

硬件問題排除了，那么問題只能出現在小高和老常這邊了。

老常很斬釘截鐵得說，他所使用的運動控制模塊根本就不存在精度問題，因為前面基本上已經拿我的視覺系統驗證過了。

最后，還是老常發現了問題。

我們的產品寬度是1800毫米，需要切割成22塊，那么通過計算，我們可以得出每塊的寬度約為81.8181毫米，那么，去小數點后兩位，此時小高應該傳給老常的切割寬度就是我81.81毫米才對，但是老常收到的卻是81.82毫米。

也就是說，是小高傳給老常的切割寬度出了問題。

其實事情到這里，結果已經很明顯了，明顯是小高在設置精度的時候采取了四舍五入的方式，導致原本的81.818在取小數點后兩位數時四舍五入成了81.82。

所以，具體就得看小高是怎么寫的了。

一看之下，才發現小高使用的方法有問題。

在代碼中，指定數字小數點位數有很多種方式，常用的有ToString方法先將數字格式化成2位小數的字符，再轉換成類型為浮點型的數字。

還有Math.Round方法，可以指定小數位數。

當然，除了這兩種方法，還有許多其他方法，這里咱不一一贅述。

但是，這兩種方法在默認情況下都有一個弊端，那就是默認情況下，轉換后的數字都是四舍五入的。

小高使用的就是Math.Round方法，用法是這樣的∶Math.Round(81.818,2)，結果就成了81.82。

其實，Math.Round方法還有第三個參數，小高在寫的時候沒注意，第三個參數可以決定指定小數點后面的值是直接忽略還是四舍五入的。

最后，解決問題的方法當然是使用Math.Round，且忽略小數點后兩位后面的數字并且不四舍五入啦！

最后經過驗證，問題解決！不得不說，有時候僅僅只是一個小問題，就能撬動一個研發團隊整體去排除問題，所以，寫代碼一定要細心吶！