据日本经济新闻报导称,村田福井厂因连日大雪而停工,虽然业界预期,村田应有库存因应,但该厂是以MLCC、EMI产品为主力业务,MLCC产能比重达25%,是村田在日本境内最大的工厂,大雪导致的停工仍被MLCC厂高度关注。
村田为全球第一大MLCC厂,其MLCC业务占集团营收比重约36%,是营收比重最高的产品线,该工厂停工会对全球MLCC供应陷入紧张境况。台湾厂商表示,该厂是村田在日本境内最大的工厂,若停工太久,将会冲击被动元件出货。
此前,供应链透露,因应供给不足的状况,村田继去年11月先通知客户交期至少要98天,12月再发通知延长2周,最少要等112天,慢则要等到180天,以特殊高容的交期最长。太阳诱交期原本至少84天,进一步拉长24天至112天。
最近一段时间以来,被动元件主要生产地日本、马来西亚因疫情陆续进入紧急状态、叠加华新科大朗厂周三火灾“点火”,刺激客户大举下单,昨日旺诠、国巨先后因大批订单涌入应接不暇而宣布暂停厚膜电阻接单;如今村田福井厂在传出因罕见大雪导致生产中断,一系列事件持续为被动市场和供应链带去冲击,引发业者担忧。
业内人士分析认为,此次村田旗下工厂在被爆出停工,短期内恐进一步让被动元件供应吃紧状况加重,交期再度被拉长。
责任编辑:lq
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。
举报投诉
原文标题:村田MLCC厂停工!
文章出处:【微信号:CSF211ic,微信公众号:中国半导体论坛】欢迎添加关注!文章转载请注明出处。
相关推荐
电子发烧友网报道(文/吴子鹏)2月19日,有高合汽车工厂员工接受媒体采访时表示,自今日(2月19日)起,高合汽车工厂已经禁止进入。该员工还称,自今年1月份起,其所在工厂已进入半停工状态,至今未生产
发表于 02-20 00:13
•5187次阅读
来源:满天芯,谢谢 编辑:感知芯视界 Link 3月6日,有外媒报道称,在行业放缓的情况下,高塔半导体计划对其美国纽波特海滩市的大部分业务进行为期三周的停工,此举将使近700名员工休假。高塔半导体
发表于 03-11 09:15
•163次阅读
近日,关于高塔半导体计划对其美国纽波特海滩市工厂进行为期三周的停工报道引发了业界关注。面对这一传闻,高塔半导体近日正式发布声明,详细解释了停工的计划和其对晶圆交付的影响。
发表于 03-07 18:21
•857次阅读
2月18日市场消息透露,高合于此次内部会议上宣布自当日起进入停工停产期达六个月。此外,根据市场消息,2月18日前高合已如常支付员工薪酬,然而至3月15日,留任员工的薪资将视地区基本水平调整。
发表于 02-28 16:42
•584次阅读
近期,中国出现了多家公司开工即停工的消息,其中包括AI初创企业竹间智慧科技(上海)有限公司。据21世纪经济报道,竹间智能因为业务需求减少,面临现金流压力和挑战,宣布将停工停产6个月,从2024
发表于 02-27 18:07
•439次阅读
瓦尔塔公司表示,由于需全面评估IT系统所受到的损害,生产环节在短时间内临时停工。他们在官方申明中强调,“为保障整体安全性,本司IT系统及生产活动已主动进行短暂性关停,并执行孤立步骤”。目前,公司正在积极核实受损情况。
发表于 02-18 09:54
•202次阅读
电容MLCC
芯广场
发布于 :2024年01月29日 11:39:27
富港(昆山)有限公司最近发布的公告引起了广泛关注,宣布由于公司面临经营困难,将安排部分员工自1月19日起停工放假半年,而在此期间,员工只能获得每月约1800元的最低保障生活费。当地不少台资企业
发表于 01-23 10:47
•684次阅读
近期,由于销售额急剧下滑,Microchip公司不得不宣布在3月份暂时关闭其位于美国格雷沙姆的工厂两周。该公司正在考虑在6月份再次进行类似的停工措施。这一决定显然给公司带来了不小的压力,也给员工带来了很大的困扰。
发表于 01-16 14:58
•415次阅读
Microchip执行长GaneshMoorthy也提到:疲弱的经济环境,让客户和经销商要求 Microchip 减少出货量,以降低库存风险。许多客户也在季末延长停工时间。受这些相关因素影响,微芯在2023年11月2日发布财测时预估出货的部分积压订单并未在2023年12月季度末之前运送给客户。
发表于 01-15 16:23
•762次阅读
来源:今日芯闻,谢谢 编辑:感知芯视界 Link 综合多家媒体报道,日本石川县能登地区1月1日发生7.6级强震,波及福井县、石川县、富山县及新潟县,环球晶、信越、新唐、东芝、国际电气等多家半导体
发表于 01-04 09:53
•427次阅读
生产,安田新材料为智能卡制造商提供芯片表面密封剂和芯片粘合粘合剂。
01芯片封装胶为了保护智能卡芯片,使用粘合剂作为密封剂。这样可以防止敏感䗈触点和芯片本身因刮擦、灰尘和湿气而损坏。安田
发表于 08-24 16:40
我一直在从事一个项目,该项目涉及在 esp8266 nodeMCU 板上使用 micropython 控制 4 通道继电器。我一直在使用 esptool 将最新的 micropython 固件 bin 文件刷入板子。一开始一切都很顺利,我继续将我的代码文件上传到板子上。那时事情开始对我不利。我的问题与 com3 端口繁忙有关。于是,我再次使用esptool擦除原来的flash,然后重新烧写板子。但是这次我在esptool开始写板子几秒后收到一个串口超时异常。我用另外两个相同(和全新)的板再次尝试,但每次我仍然遇到相同的错误。下面是从命令行参数开始的 esptool 输出。
(base) PS C:\\development\\python> esptool --port com3 --baud 9600 write_flash --flash_size detect --flash_mode dio -z 0x0000 esp8266-20210902-v1.17.bin esptool.py
v3.2
串口com3
正在连接...
设备 PID 识别仅在 COM 和 /dev/ 串行端口上受支持。
.
Detecting chip type... 不支持的检测协议,切换并重试...
Connecting...
设备PID识别只支持COM和/dev/串口。
.
正在检测芯片类型... ESP8266
芯片是 ESP8266EX
特性: WiFi
Crystal 是 26MHz
MAC: 44:17:93:0d:50:04
正在上传存根...
正在运行存根...存根
正在运行...
正在配置闪存大小...
自动检测到的闪存大小:4MB
闪存将从 0x00000000 擦除到 0x0009afff...
闪存参数设置为 0x0240
压缩 633688 字节到 416263...
写入 0x00000000...(3 %)回溯(最后一次调用):
文件“c:\\users\\billa\\anaconda3\\lib\\runpy.py”,第 193 行,在 _run_module_as_main
“__main__”,mod_spec)
文件“c:\\users\\billa\\anaconda3\\lib\\runpy.py”,第 85 行,在_run_code
exec(code, run_globals)
文件“C:\\Users\\billa\\Anaconda3\\Scripts\\esptool.exe\\__main__.py”,第 7 行,在
文件“c:\\users\\billa\\anaconda3\\lib\\site -packages\\esptool.py\",第 5136 行,在 _main
main()
文件“c:\\users\\billa\\anaconda3\\lib\\site-packages\\esptool.py”中,4602行,主要
operation_func(esp, args)
文件“c:\\users\\billa\\anaconda3\\lib\\site-packages\\esptool.py”,第 3873 行,在 write_flash
esp.flash_defl_block(block, seq, timeout=timeout)
文件“c:\\ users\\billa\\anaconda3\\lib\\site-packages\\esptool.py\",第 154 行,在内部
return func(*args, **kwargs)
File \"c:\\users\\billa\\anaconda3\\lib\\site-packages\\esptool .py\", line 919, in flash_defl_block
self.ESP_FLASH_DEFL_DATA, struct.pack(\' esptool --port com3 --baud 9600 erase_flash
esptool.py v3.2
串行端口 com3
正在连接...
设备 PID 识别仅在 COM 和 /dev/ 串行端口上受支持。
.
正在检测芯片类型... 不支持的检测协议,切换并重试...
正在连接...
设备 PID 识别仅在 COM 和 /dev/ 串行端口上受支持。
.
正在检测芯片类型... ESP8266
芯片是 ESP8266EX特点
: WiFi
Crystal 是 26MHz MAC: 44:17:93 : 0e
:3f: ce一会儿)...芯片擦除在 4.7 秒内成功完成通过 RTS 引脚硬重置... (基础)PS C:\\development\\python> esptool --port com3 --baud 9600 write_flash --flash_size detect --flash_mode dio -z 0x0000 esp8266-20210902-v1.17.bin esptool.py v3.2 Serial port com3 Connecting...设备PID识别只支持COM和/dev/串口。.
发表于 05-25 06:32
通富微电一季度净利润同比下降97% 根据通富微电披露的一季报,一季度归母净利润455万元,同比下降97.24%。 纬创泰州正式停工停产 4月26日,纬创通资(泰州)有限公司正式停工停产,而据消息人士
发表于 04-27 15:41
•3161次阅读
我有一个具有以下流程的应用程序(使用 esp8266):
- 设置 wifi 静态 IP
- 读取许多传感器(ow,i2c)
- 等待 wifi GOT_IP(使用空闲应用程序注册 eventmon)
- 向服务器发送报告
这曾经很好地工作,“等待”部分约为 60 毫秒。今年早些时候我更新了固件,等待时间上升到大约 800 毫秒。这是一个重要的问题,因为设备使用电池供电。
我现在决定调查这个问题,并注意到当 ow 连接不好时,“读取”速度很快(80 毫秒),等待时间为 60 毫秒,但是当 ow 读取工作(需要 220 毫秒)时,等待时间更长(800 毫秒) .
我启用了日志记录,看到在“等待”期间实际发生的是断开连接(原因 AUTH_EXPIRE),然后快速重新连接(GOT_IP)。似乎如果应用程序保持忙碌(读取 ow 和 i2c 设备),wifi 引擎会遇到某种内部超时。
是否有可能占用 CPU 导致 wifi 失败?如果是这样,一笔交易如何避免失败?
发表于 04-27 07:35
评论