**2021-6-16 ~2021-6-18 工作计划及完成情况**

1. 周五下班前需要部署完成，doff_client可以下周再改代码。
2. ~~jumpserver 找滕俊开账号~~
3. 加入到盛波5号线的群，群内有各台机器的aoi向日葵、tv的账号密码
4. 连接之前，必须找村长或者现场系统工程师确认，是否可以连上去。
5. 部署到盛波现场
6. 查看客户端的mysql为什么连不上（目前已经连上，可以安排后续观察）``
7. ~~由于之前程序有问题，因此，现场数据库已经清空了。~~ 
8. ~~需要重新把表结构导入进去。表结构在83，  192.168.7.83~~
9. 配置基本的产线信息。
10. 有 预处理、延伸段、涂布段、SED 四个段，因此要配置4个, 4个都需要调通
11. json文件能访问，lia_edge_serve 需要在客户端启动（应该是做了自动启动的，如果没有启动，需要查原因）
12. 缺陷卡片的图片能访问（同上）
13. 找现场系统工程师，要一台AOI 工控机的远程，上去验证4个段是否都已连网能看到web页面。



-----

page（全数据）  site(第二条) cube_config（全数据） cube_shift（全数据）  config_flow_type（全数据）





1,  doff_client 的断网是指 aoi工控机断网吗？

2，断网导致的是远程的doff_client内存溢出吗  还是说部署到aoi工控机上的doff_client 的机器内存溢出?

​	- 我认为是断网导致的是工控机上部署的doff_client 内存溢出

3，换卷后，找了到这个卷或其他错误就换下一卷，



代理：开发的时候跨域

上线：



地址 --->  ip  nginx -->  服务 页面 （请求服务代理） 和服务

代理：

开发阶段：发情求：  端口不一样   代理的东西

devServer

~~~
  proxy: {
            '/rts': {
                target: 'http://127.0.0.1:3010/', // 代理地址，这里设置的地址会代替axios中设置的baseURL
                changeOrigin: true, // 如果接口跨域，需要进行这个参数配置
                //ws: true, // proxy websockets
                //pathRewrite方法重写url
                pathRewrite: {
                    '^/rts': '/'
                    //pathRewrite: {'^/api': '/'} 重写之后url为 http://192.168.1.16:8085/xxxx
                    //pathRewrite: {'^/api': '/api'} 重写之后url为 http://192.168.1.16:8085/api/xxxx
                }
            },
            '/api': {
                target: 'http://115.236.65.98:12001/api', // 代理地址，这里设置的地址会代替axios中设置的baseURL
                changeOrigin: true, // 如果接口跨域，需要进行这个参数配置
                //ws: true, // proxy websockets
                //pathRewrite方法重写url
                pathRewrite: {
                    '^/api': '/'
                    //pathRewrite: {'^/api': '/'} 重写之后url为 http://192.168.1.16:8085/xxxx
                    //pathRewrite: {'^/api': '/api'} 重写之后url为 http://192.168.1.16:8085/api/xxxx
                }
            }
        }
~~~



win10 的host文件路径

C:\WINDOWS\system32\drivers\etc



#### 关于rts的缺陷问题的探讨研究

1，job工作卷列表无md和cd方向标识，无法判断到底卷是怎样走的，以及判断缺陷在卷的位置上的认知。

2，建议换车成echarts散点图类型，第一美观，第二，好计算某个缺陷的位置，第三，可以放大卷任意位置，第四，有坐标，可以直接换算成数据库的实际数据。

3，现在的后端查询某个缺陷在一个job 上的卷位置逻辑：一个job的总长度/当前缺陷位置 返回，cd方向同理





#### 有关rts  缺陷信息误报的容错方案

- **错误来源**：譬如：cd 或者md的值大于 卷的最大值，或者小于0

  容错方案如下:

  >1，有不正常的点，直接影藏，譬如：cd 或者md的值大于 卷的最大值，或者小于0
  >
  >优点：导航图运行轨迹，尺寸都正常
  >
  >**缺点**：如果存在多个误报的点，直接忽略的话，**会影响检测质量，对客户来说，这是不愿意看到的**
  >
  >-- 不推荐

  >2，不正常的依然显示在导航中，（由于宽度和高度定死，所以超出的点无法显示，小于0 的点可以显示）---现在的逻辑
  >
  >-- 有问题

  > 3，首先综合方案一，在导上面只显示正常的点，如果出现误报，则把误报的点的信息单独拎出来，在某个地方显示出来，
  >
  > **这个查询不正常的点的操作在后端完成，查询当前job下 < 0 and >最大值 的点的集合，返给前端，提示给用户，这样就不用遍历整个缺陷数组，优化了效率，又能处理误报，又能在前端导航正常显示**
  >
  > -- 冥思苦想（哈哈）