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

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

本來這個問題是沒有被發(fā)現(xiàn)的，因?yàn)槲业囊曈X部分只寫了切割器位置標(biāo)定，切割精度的視覺模塊還沒上，而這天我正好開始測試我新寫好的切割精度檢測模塊，于是就讓小高和老常配合我，做了下切割。

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

我這邊早就和老常測試好了切割器位置標(biāo)定這個功能，是沒有問題的，也就是說，切割器的安裝偏移老常這邊應(yīng)該是已經(jīng)補(bǔ)正過的了，重新做了下位置標(biāo)定，發(fā)現(xiàn)切割器的位置是非常準(zhǔn)的，位置精度能達(dá)到小數(shù)點(diǎn)后三位。

而切割后的產(chǎn)品，我們拿高精度卡尺卡了一下，發(fā)現(xiàn)我的檢測結(jié)果也非常準(zhǔn)，而且檢測結(jié)果也能到小數(shù)點(diǎn)后三位。

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

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

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

老常很斬釘截鐵得說，他所使用的運(yùn)動控制模塊根本就不存在精度問題，因?yàn)榍懊婊旧弦呀?jīng)拿我的視覺系統(tǒng)驗(yàn)證過了。

最后，還是老常發(fā)現(xiàn)了問題。

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

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

其實(shí)事情到這里，結(jié)果已經(jīng)很明顯了，明顯是小高在設(shè)置精度的時候采取了四舍五入的方式，導(dǎo)致原本的81.818在取小數(shù)點(diǎn)后兩位數(shù)時四舍五入成了81.82。

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

一看之下，才發(fā)現(xiàn)小高使用的方法有問題。

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

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

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

但是，這兩種方法在默認(rèn)情況下都有一個弊端，那就是默認(rèn)情況下，轉(zhuǎn)換后的數(shù)字都是四舍五入的。

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

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

最后，解決問題的方法當(dāng)然是使用Math.Round，且忽略小數(shù)點(diǎn)后兩位后面的數(shù)字并且不四舍五入啦！

最后經(jīng)過驗(yàn)證，問題解決！不得不說，有時候僅僅只是一個小問題，就能撬動一個研發(fā)團(tuán)隊整體去排除問題，所以，寫代碼一定要細(xì)心吶！