<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>盈泰德</title>
		<link>https://www.intsoftsop.com/</link>
		<description>盈泰德（深圳）科技有限公司专注 AI 视觉 SOP 系统研发，用工业机器视觉在产线工位实时识别作业动作，实现 SOP 合规检测、工序防错、漏工序报警与生产追溯。</description>
		<language>zh_CN</language>
		<lastBuildDate>Wed, 21 Oct 2026 03:59:52 +0800</lastBuildDate>
		<atom:link href="https://www.intsoftsop.com/rss.xml" rel="self" type="application/rss+xml"/>
		<item>
			<title>视觉供应商怎么评估</title>
			<link>https://www.intsoftsop.com/blog/visual-sop-vendor-evaluation.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/visual-sop-vendor-evaluation.html</guid>
			<pubDate>Tue, 06 Oct 2026 17:55:00 +0800</pubDate>
			<description>视觉方案供应商之间的差别，很难从宣传材料和报价单上看出来。案例清单谁都有，技术名词谁都会说，报价单上的差异往往只反映配置高低，而不反映能力高低。真正能分辨的场合是技术交流——通过提问看对方怎么回答，尤其是看他会不会主动说出方案的风险与边界。回避困难、什么都能做的供应商，通常意味着他还没真正遇到过困难。</description>
		</item>
		<item>
			<title>光源老化与照度衰减</title>
			<link>https://www.intsoftsop.com/blog/lighting-aging-and-degradation.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/lighting-aging-and-degradation.html</guid>
			<pubDate>Tue, 06 Oct 2026 17:50:00 +0800</pubDate>
			<description>光源在方案阶段是重点，装好之后就被当成耗材。但它的变化会直接影响成像，而且变化方式比大多数人以为的复杂：不是缓慢线性变暗，而是先快后慢；不只是亮度下降，光谱也会漂移；不只是整体变暗，阵列上各颗灯珠的衰减速度还不一样。这些变化合起来，会让一个曾经好用的光照方案在两年后悄悄失效。</description>
		</item>
		<item>
			<title>视觉项目的风险清单</title>
			<link>https://www.intsoftsop.com/blog/vision-project-risk-register.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/vision-project-risk-register.html</guid>
			<pubDate>Tue, 06 Oct 2026 17:45:00 +0800</pubDate>
			<description>视觉项目的失败模式高度重复。把它们列成清单，在立项和方案评审时逐条对照，比事后复盘有用得多。这份清单里的每一条都不是罕见情况，而是多数项目都会碰到、只是严重程度不同的东西。真正的区别在于：有的项目提前识别并安排了应对，有的项目等它发生时才第一次讨论。</description>
		</item>
		<item>
			<title>视觉项目里各部门谁干什么</title>
			<link>https://www.intsoftsop.com/blog/cross-department-roles.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/cross-department-roles.html</guid>
			<pubDate>Tue, 06 Oct 2026 17:40:00 +0800</pubDate>
			<description>一个视觉项目从立项到稳定运行，会经过工艺、质量、设备、生产、IT、采购这几个部门，外加外部供应商。技术上的困难通常有明确的解法，真正拖住项目的是职责上的空白——某件事大家都以为别人在做，直到某个节点上需要有人签字或下结论时才发现没人能做主。这三件事里最典型的是判据的定义权、参数的控制权、验收的签字权。</description>
		</item>
		<item>
			<title>样本库怎么管</title>
			<link>https://www.intsoftsop.com/blog/sample-library-management.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/sample-library-management.html</guid>
			<pubDate>Tue, 06 Oct 2026 17:35:00 +0800</pubDate>
			<description>样本库是视觉系统的地基：验收时用它证明系统做得到，日常用它监测系统还在做得到，争议时用它判断到底是谁错了。但它同时是一项最容易被忽略的资产——它没有编号就进了某个工程师的抽屉，没有清单就散落在几个文件盒里，没有人负责就随着人员流动而失去意义。等到要用的时候，才发现既不知道哪个是哪个，也不知道还能不能代表当初的状态。</description>
		</item>
		<item>
			<title>客户稽核时怎么拿出证据</title>
			<link>https://www.intsoftsop.com/blog/audit-evidence-preparation.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/audit-evidence-preparation.html</guid>
			<pubDate>Tue, 06 Oct 2026 17:30:00 +0800</pubDate>
			<description>稽核员看视觉系统时，通常不评价技术方案是否先进，而是沿着一条固定的线索追问：判据是谁定的、依据是什么、系统是不是真按这个判据在做、有没有人定期确认它还在按判据做、判据改过几次、改动前后怎么验证。这些问题几乎都能用现成的记录回答，前提是这些记录当初就留下来了。最难受的情形不是做得不好，而是做了却没有证据。</description>
		</item>
		<item>
			<title>判据一致性怎么培训</title>
			<link>https://www.intsoftsop.com/blog/criteria-alignment-training.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/criteria-alignment-training.html</guid>
			<pubDate>Tue, 06 Oct 2026 17:25:00 +0800</pubDate>
			<description>把判据写下来并不难，难的是让每个人在实际操作时都按同一个尺子判。培训的常见做法是念一遍文件、签个字，这种做法几乎不产生效果，因为判据的难点从来不在于文字，而在于遇到那个「说不上来合不合格」的件时该怎么办。有效的培训必须把这些人放到一起，让他们对同一批难件分别作出判断，然后把分歧摆到桌面上。</description>
		</item>
		<item>
			<title>视觉工位的日常点检</title>
			<link>https://www.intsoftsop.com/blog/daily-check-and-maintenance.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/daily-check-and-maintenance.html</guid>
			<pubDate>Tue, 06 Oct 2026 17:20:00 +0800</pubDate>
			<description>视觉系统出故障有两种形态。一种是突然的：相机掉线、软件报错、程序退出，这类故障会立刻被产线发现，不需要点检。另一种是渐变的：光源一点点变暗、视窗一点点变脏、夹具一点点磨损、标定一点点漂移，系统始终在运行、始终在出结果，只是结果在慢慢偏。多数现场抱怨的「以前能检出来，现在检不出了」都属于第二种，而它们本来是可以被一个简单的日常动作拦住的。</description>
		</item>
		<item>
			<title>模型部署与推理耗时优化</title>
			<link>https://www.intsoftsop.com/blog/inference-deployment-and-optimisation.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/inference-deployment-and-optimisation.html</guid>
			<pubDate>Tue, 06 Oct 2026 17:15:00 +0800</pubDate>
			<description>模型在开发机上跑得快，不代表装到工位上够用。中间隔着一整套工程问题：图像从相机到内存的搬运、预处理、推理、后处理、结果发布，每一段都在消耗节拍预算。最常见的意外是发现推理本身只占了一小部分，真正的时间花在了缩放、归一化、色彩转换这些看起来不起眼的步骤上。要优化，第一步不是换模型，而是把整条链路的耗时测出来。</description>
		</item>
		<item>
			<title>视觉引导定位与检测的分界</title>
			<link>https://www.intsoftsop.com/blog/vision-guided-positioning.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/vision-guided-positioning.html</guid>
			<pubDate>Tue, 06 Oct 2026 17:10:00 +0800</pubDate>
			<description>「用相机找一下这个零件在哪」和「用相机看看这个零件合不合格」，在外行听来是同一件事，在工程上是两个专业。前者的输出是一个坐标，送给机器人去执行动作；后者的输出是一个判定，决定工件放行还是拦截。它们的精度定义、失败后果、节拍压力和安全等级都不一样。把两者当成一件事来谈，最常见的后果是需求收不准，报价和方案都跟着偏。</description>
		</item>
		<item>
			<title>多相机坐标系对齐</title>
			<link>https://www.intsoftsop.com/blog/multi-camera-coordinate-alignment.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/multi-camera-coordinate-alignment.html</guid>
			<pubDate>Tue, 06 Oct 2026 17:05:00 +0800</pubDate>
			<description>单相机工位只需要一次标定。一旦变成两台以上相机，就多出一个问题：它们的读数在各自的坐标系里都正确，但放在一起看时相差一个变换。这个变换需要靠公共点或者公共机构建立起来。对齐本身的数学不难，难的是它失效时的表现——每台相机各自看都正常，只有把它们的读数放在一起比较时才会发现对不上，而这种比较往往不是每天的例行工作。</description>
		</item>
		<item>
			<title>手眼标定怎么做</title>
			<link>https://www.intsoftsop.com/blog/hand-eye-calibration.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/hand-eye-calibration.html</guid>
			<pubDate>Tue, 06 Oct 2026 17:00:00 +0800</pubDate>
			<description>相机看到的是像素，机器人需要的是毫米和角度，两者之间靠一次标定建立的变换来连接。这一次标定是视觉引导类项目里最关键、也最不容易察觉出错的一环：标定参数不对，系统不会报任何错误，机器人照样动，只是每次都差那么一点，误差在整个工作空间里还不均匀。用一批点拟合出一个变换，再用这批点自己去检验它，是最常见的错误做法。</description>
		</item>
		<item>
			<title>频闪与常亮怎么取舍</title>
			<link>https://www.intsoftsop.com/blog/strobe-and-continuous-lighting.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/strobe-and-continuous-lighting.html</guid>
			<pubDate>Tue, 06 Oct 2026 16:55:00 +0800</pubDate>
			<description>常亮光源接上电就亮，简单、便宜、没有同步问题。频闪光源只在曝光的瞬间点亮，因此可以在极短的时间里给出远高于自身额定功率的亮度——这一条特性解决的正是「曝光时间被运动速度压得很短、光给不够」这个矛盾。代价是多一个控制器、一条同步链路，以及一条会以间歇性黑帧形式暴露的故障路径。要不要为它多花这笔钱，取决于光与节拍这一对矛盾有多紧。</description>
		</item>
		<item>
			<title>相机的防护、清洗与视窗污染</title>
			<link>https://www.intsoftsop.com/blog/camera-protection-and-cleaning.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/camera-protection-and-cleaning.html</guid>
			<pubDate>Tue, 06 Oct 2026 16:50:00 +0800</pubDate>
			<description>在洁净室里表现完美的工位，搬到机加车间可能三周就出问题，而且出问题的方式很不显眼：画面不会突然变糊，只是整体压暗一点、对比度降一点，直到某天开始零星漏判。这种渐进式失效最难排查，因为所有硬件都是好的，只是镜头前面多了一层东西。防护、清洗和视窗污染是同一个问题的三面，它们的共同点是必须在设计阶段安排，而不是等到判据不稳了再回头补。</description>
		</item>
		<item>
			<title>线扫描相机怎么用</title>
			<link>https://www.intsoftsop.com/blog/line-scan-camera-basics.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/line-scan-camera-basics.html</guid>
			<pubDate>Tue, 06 Oct 2026 16:45:00 +0800</pubDate>
			<description>线扫描相机与面阵相机的差别不只是形状。面阵相机是「一次拍一张」，线扫描只有一行像素，必须靠工件相对运动一行一行拼出一整幅图。这意味着它的图像质量与运动系统绑死：走多快、行频给多少、两者比例是否恒定，直接决定图像是被拉伸、被压缩还是正常。它的优势也正来自这个结构——连续材料可以做得极宽极高分辨率，圆柱面可以展开成平面。</description>
		</item>
		<item>
			<title>景深与光圈怎么选</title>
			<link>https://www.intsoftsop.com/blog/depth-of-field-and-aperture.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/depth-of-field-and-aperture.html</guid>
			<pubDate>Tue, 06 Oct 2026 16:40:00 +0800</pubDate>
			<description>工件不是一个绝对平的平面：来料厚度有公差、定位有重复性、夹具会磨损。景深回答的就是「这些高度差加起来有多少时画面还够清楚」。它由光圈、放大倍率和容许弥散圆共同决定，其中最反直觉的一条是放大倍率越高景深越浅——也就是说精度要求越高，容许的高度波动越小。这一组矛盾在现场被处理成什么样子，基本决定了这个工位能不能长期稳定。</description>
		</item>
		<item>
			<title>检测记录留几年、留什么</title>
			<link>https://www.intsoftsop.com/blog/inspection-record-retention.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/inspection-record-retention.html</guid>
			<pubDate>Tue, 06 Oct 2026 16:30:00 +0800</pubDate>
			<description>记录留存有两个维度：留多久，和留什么。留太短，出了客诉查不到当时的判定依据；留太全，存储成本、检索成本和维护成本会一起失控。把这两个维度分开看，问题就清楚多了：年限由客户合同与行业法规决定，而内容的分级——哪些必须长期留、哪些留中短期、哪些只在异常时留——由你自己的复盘需求决定。算一遍存储量会发现，真正占地方的是图像，不是记录。</description>
		</item>
		<item>
			<title>检测数据怎么接进 SPC</title>
			<link>https://www.intsoftsop.com/blog/inspection-data-to-spc.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/inspection-data-to-spc.html</guid>
			<pubDate>Tue, 06 Oct 2026 16:00:00 +0800</pubDate>
			<description>SPC 的前提是数据本身可信。把视觉系统的判定结果直接丢进控制图，如果这个「结果」只是合格与不合格两个值，做出来的图基本反映不了过程波动——它只能告诉你这批的坏品率是多少，看不出趋势、看不出漂移、看不出设备正在往哪个方向走。要看到这些，系统必须输出数值。而要不要输出数值、输出哪一个数值，必须在方案设计阶段就定，事后补不上。</description>
		</item>
		<item>
			<title>缺陷样本太少，模型还做不做</title>
			<link>https://www.intsoftsop.com/blog/defect-sample-scarcity.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/defect-sample-scarcity.html</guid>
			<pubDate>Tue, 06 Oct 2026 15:30:00 +0800</pubDate>
			<description>真实的视觉项目里，缺陷样本往往是最缺的东西。产线良率越高，缺陷越少，而这是好事——但它意味着你手上可能只有十几张真实的缺陷图，要判别的缺陷类型却有五六种。这个矛盾几乎每个项目都会遇到，处理方式决定了项目是卡死在收集样本上，还是绕过去先把系统跑起来。本文给出一条可持续的收集流程和四条样本不足时可行的路径，也说明合成样本真正能解决什么、不能解决什么。</description>
		</item>
		<item>
			<title>规则算法与深度学习怎么选</title>
			<link>https://www.intsoftsop.com/blog/deep-learning-vs-rule-based-vision.html</link>
			<guid isPermaLink="true">https://www.intsoftsop.com/blog/deep-learning-vs-rule-based-vision.html</guid>
			<pubDate>Tue, 06 Oct 2026 15:00:00 +0800</pubDate>
			<description>这两类方法不是新旧关系，是适用范围不同。规则算法把人的判断写成一串明确的步骤——先找边缘、再量距离、再比阈值；深度学习从样本里把这串步骤自己找出来。前者可解释、样本需求低、边界清楚；后者能处理规则描述不清的特征，但依赖样本、难以解释、边界往往说不清。选哪一种，取决于任务本身能不能被规则描述清楚，而不是哪种技术更新。</description>
		</item>
	</channel>
</rss>
