Profibus产品开发与开发包4的应用之四 点击：1693 | 回复：17
发表于：2005-12-01 09:35:00
楼主
Profibus产品开发与开发包4的应用之四
海维深科技研发中心 王晟磊
4 主站设计
主站的设计同样有两种方式，一是利用众多的主站板卡进行二次开发，一是用ASPC2进行深层次开发，但是由于主站芯片ASPC2的开发是另一个开发包的内容，在这里我们就不多谈了，下面我们就利用开发包4带的主站接口板IM180进行二次开发进行一些探讨。
与IM180配套的有一块PC接口卡——IM181，IM181是一块ISA卡，它能将IM180与PC方便的相联，当然如果你的开发不是用PC当主站也是一样的。IM180上有一块主站芯片ASPC2一块16位单片机80C165以及双口RAM、 FlashRam等，单片机负责ASPC2的管理和控制，也就是说所有与通信有关的事情都不占用主CPU机时，两块8K的双口RAM用于与用户的接口，通过它们将指令和数据送给ASPC2。对IM180的接口定义在它的说明书内有着详细的描述。
与IM180的通信实用可靠，在IM180的器件手册中有所有的定义，看过它的定义，你会对它工作在复杂环境的能力深信不疑。
用户与IM180之间的任何通信都是基于可靠性考虑的，整个双口RAM分为三大块。
1）从站数据区
IM180为每个从站分配了三块最大244字节的缓存。
一块是输入缓存；
一块是输出缓存；
一块是诊断缓存；
3） 通道诊断区
主要用显示主站状态、数据抟输列表、通道错误、从站状态、从站信息、系统状态、其它信息等。
4） 命令区
所有给IM180的命令与命令数据均通过这儿送入，它包括命令数据、命令数据长度、开门狗、回复区、信号灯。
如果要送数据给相应的从站，则先将数据填入对应的从站数据输入缓存，然后将对应从站地址的寄存器修改并通过信号灯通知IM180作相应的工作，IM180传输成功后返回一个信号灯，同时所有送给IM180的数据或命令IM180都会送回来，以证实功能完成。同样从从站传上来的数据也都会实时的放入相对应的缓存内。IM180里一个硬件看门狗，如果在指定时间内没有得到令牌或从站的回应，它会进行相应处理或复位。所以要根据总线的轮巡时间来设置它。在开发包中有与IM180接口的例子程序，用户可以通过修改和学习它们来加快自已的开发。
5 总结：
现场总线正当群雄割据的时代，多年实践经验告诉我们，每种现场总线在制定协议时都是针对某一个或几个明确的领域，也就是说我们有充足的理由相信，在近几年内不可能由某种现场总线或工业以太网一统天下，如何选择现场总线，讨论这方面的论文相当多，关键是根据您对性能的要求。如果开发是一种对实时性可靠性要求较高的分布式或混合型的系统，那么选择Profibus将不会因为通信是否可靠而大伤脑筋。起码西门子的系列分布式PLC就是成功的典范。
海维深科技研发中心 王晟磊
4 主站设计
主站的设计同样有两种方式，一是利用众多的主站板卡进行二次开发，一是用ASPC2进行深层次开发，但是由于主站芯片ASPC2的开发是另一个开发包的内容，在这里我们就不多谈了，下面我们就利用开发包4带的主站接口板IM180进行二次开发进行一些探讨。
与IM180配套的有一块PC接口卡——IM181，IM181是一块ISA卡，它能将IM180与PC方便的相联，当然如果你的开发不是用PC当主站也是一样的。IM180上有一块主站芯片ASPC2一块16位单片机80C165以及双口RAM、 FlashRam等，单片机负责ASPC2的管理和控制，也就是说所有与通信有关的事情都不占用主CPU机时，两块8K的双口RAM用于与用户的接口，通过它们将指令和数据送给ASPC2。对IM180的接口定义在它的说明书内有着详细的描述。
与IM180的通信实用可靠，在IM180的器件手册中有所有的定义，看过它的定义，你会对它工作在复杂环境的能力深信不疑。
用户与IM180之间的任何通信都是基于可靠性考虑的，整个双口RAM分为三大块。
1）从站数据区
IM180为每个从站分配了三块最大244字节的缓存。
一块是输入缓存；
一块是输出缓存；
一块是诊断缓存；
3） 通道诊断区
主要用显示主站状态、数据抟输列表、通道错误、从站状态、从站信息、系统状态、其它信息等。
4） 命令区
所有给IM180的命令与命令数据均通过这儿送入，它包括命令数据、命令数据长度、开门狗、回复区、信号灯。
如果要送数据给相应的从站，则先将数据填入对应的从站数据输入缓存，然后将对应从站地址的寄存器修改并通过信号灯通知IM180作相应的工作，IM180传输成功后返回一个信号灯，同时所有送给IM180的数据或命令IM180都会送回来，以证实功能完成。同样从从站传上来的数据也都会实时的放入相对应的缓存内。IM180里一个硬件看门狗，如果在指定时间内没有得到令牌或从站的回应，它会进行相应处理或复位。所以要根据总线的轮巡时间来设置它。在开发包中有与IM180接口的例子程序，用户可以通过修改和学习它们来加快自已的开发。
5 总结：
现场总线正当群雄割据的时代，多年实践经验告诉我们，每种现场总线在制定协议时都是针对某一个或几个明确的领域，也就是说我们有充足的理由相信，在近几年内不可能由某种现场总线或工业以太网一统天下，如何选择现场总线，讨论这方面的论文相当多，关键是根据您对性能的要求。如果开发是一种对实时性可靠性要求较高的分布式或混合型的系统，那么选择Profibus将不会因为通信是否可靠而大伤脑筋。起码西门子的系列分布式PLC就是成功的典范。
发表于：2006-02-05 23:03:00
3楼
好久没来论坛了，过年想换个工作。
偶然上来和楼主讨论一下。
LONWORKS我还没有了解。CAN本身是一个物理标准，基于这个标准的协议我知道有DEVICENET、CONTROLNET、CANOPEN、1939等等。它主要用于分散控制，物理层决定它天生处理节点突发信息的能力较强。在较低速率情况下，它的传输距离远比485下的PROFIBUS长，资料上据说能达10KM5KBPS（我没有实践考证）。CAN的物理层上就决定了CAN的节点数“那是相当得多”（套用宋丹丹的话，呵呵）。
PROFIBUS是令牌网，一般工业现场的实时控制是基于485的，如果几百米远，速度一般也就选187.5K，太高了不敢选。如果节点过多，显而易见，速率当然就上不去了－－但是CAN不是令牌而是竞争的，所以无论有多少个节点，有优先权的节点速率总能够得到保证。而且，由于令牌网的天生特点，PROFIBUS的任一节点，不能整批传输大量数据（印象中，大概最多也不会一次传到200字节）。当然PROFIBUS针令牌的一些缺点也采取了一些解决办法。
偶然上来和楼主讨论一下。
LONWORKS我还没有了解。CAN本身是一个物理标准，基于这个标准的协议我知道有DEVICENET、CONTROLNET、CANOPEN、1939等等。它主要用于分散控制，物理层决定它天生处理节点突发信息的能力较强。在较低速率情况下，它的传输距离远比485下的PROFIBUS长，资料上据说能达10KM5KBPS（我没有实践考证）。CAN的物理层上就决定了CAN的节点数“那是相当得多”（套用宋丹丹的话，呵呵）。
PROFIBUS是令牌网，一般工业现场的实时控制是基于485的，如果几百米远，速度一般也就选187.5K，太高了不敢选。如果节点过多，显而易见，速率当然就上不去了－－但是CAN不是令牌而是竞争的，所以无论有多少个节点，有优先权的节点速率总能够得到保证。而且，由于令牌网的天生特点，PROFIBUS的任一节点，不能整批传输大量数据（印象中，大概最多也不会一次传到200字节）。当然PROFIBUS针令牌的一些缺点也采取了一些解决办法。
发表于：2006-02-22 20:28:00
9楼
應該是用主站芯片來進行開發吧？不是設計那顆主站芯片吧？
就我的感覺而言，從技術上而言，CAN總線是可靠性最高的一種總線，我想不應該將CAN與Profibus來進行比較，本來就不是一個層面上的東西，應該把CAN與RS485進行比較，把Profibus與DeviceNet，CANopen進行比較，這樣才有可比性。
對於當今的現場總線而言，Profibus與DeviceNet的應用場合相當，但從市場占有率來說，Profibus是絕對的老大，不過這並不表示Profibus的技術是最優秀的，我想一個產品成功與否的約定因素不一定是技術本身；而CANopen與前兩者的應用場合並不一樣，主要用於伺服控制，位置控制，運動控制等real time的控制場合。Lonwork的定位並非在工業控制領域，樓宇自動化才是它的強項，因此較適合用在一些互聯性好，速度低的場合，如污水處理，大橋燈光，樓宇控制，隧道通風等。
剛好上述四種總線，我都有開發過其通訊設備，主要是變頻器和PLC的總線模塊，所以亂講一通，僅供參考。
如有興趣討論，歡迎來DND網站：http://www.dndev.com
就我的感覺而言，從技術上而言，CAN總線是可靠性最高的一種總線，我想不應該將CAN與Profibus來進行比較，本來就不是一個層面上的東西，應該把CAN與RS485進行比較，把Profibus與DeviceNet，CANopen進行比較，這樣才有可比性。
對於當今的現場總線而言，Profibus與DeviceNet的應用場合相當，但從市場占有率來說，Profibus是絕對的老大，不過這並不表示Profibus的技術是最優秀的，我想一個產品成功與否的約定因素不一定是技術本身；而CANopen與前兩者的應用場合並不一樣，主要用於伺服控制，位置控制，運動控制等real time的控制場合。Lonwork的定位並非在工業控制領域，樓宇自動化才是它的強項，因此較適合用在一些互聯性好，速度低的場合，如污水處理，大橋燈光，樓宇控制，隧道通風等。
剛好上述四種總線，我都有開發過其通訊設備，主要是變頻器和PLC的總線模塊，所以亂講一通，僅供參考。
如有興趣討論，歡迎來DND網站：http://www.dndev.com
发表于：2006-02-23 11:32:00
10楼
晕，网络有问题，发了几次都没发上去，只好重写。
TO遠方：
我以前确是开发主站芯片，因为ASPC2的主站芯片可以买到，但是没有接口资料，如果要开发主站要与德国西门子签一个许可和行业限制协议，所以我们用了两年时间用FPGA开发了一个主站芯片，但没有流片，主要用于我们当时开发的大型控制系统内。不流片的原因有二，一是国内主站开发的公司很少，大多数都是买5611或5613卡在PC上开发，用芯片一级开发的基本没有，好像和利时有用，但不大清楚他们是如何做的。
你说的CAN与RS485是一级是有问题的，因为RS485是物理层协议，只定义物理层的特性，而CAN包括数据链路层，PROFIBUS-DP也只包括物理层、数据链路层和用户接口层。所以CAN与PROFIBUS是同一层次的协议。
DeviceNet是在CAN协议上开发的，主要定义了规约和具体的工控行业应用的接口与PROFIBUS的行规有些相似。
PRFIBUS在大型控制系统的应用比CAN的可靠性要高，原因如下：
CAN是竞争型多主协议，所以时延不稳定，在工控现场这是很麻烦的，所以DeviceNet主要的工作就是对这一部分的约束。而PRFIBUS是令牌网，所有的时间都是可以确定的，这对于高可靠和高实时性的大型控制系统来说更适合。
CAN的开销相对而言比较大，因为CAN的开发是为宝马车上的传感器开发的，所以对于点数要求较大，对于单帧数据量比较小，而站地址和功能码的开销相对比较大，而PROFIBUS是针对替代MODBUS之类的过程控制协议，所以在这方面比较经济。
总的来说各种现场总线的应用范围是不同的。这在我的前几个文档中有说明。
另外优秀与否取决于您对协议的理解，比方说LONWORKS协议很优秀，但是实现很垃圾，特别是他们宣称的坚持型脉冲监听协议实际上根本没有在FFT-10A里面实现，而是简单的发三帧不管对错，1.25M的最大包速也是800包/秒，原因就在这里。
CAN在国内的用户应该说是最多的，主要是开发容易，而PROFIBUS在这一方面的推广相当差，德国人的思维习惯也很不合中国人的胃口，不说主站，全国开发从站的公司都不超过50家。
当然我并不是说PROFIBUS比其它协议优秀多少，而是它在过程控制这个领域应该说是相当棒的，FF的许多的思想就是从PROFIBUS中吸取的。
TO遠方：
我以前确是开发主站芯片，因为ASPC2的主站芯片可以买到，但是没有接口资料，如果要开发主站要与德国西门子签一个许可和行业限制协议，所以我们用了两年时间用FPGA开发了一个主站芯片，但没有流片，主要用于我们当时开发的大型控制系统内。不流片的原因有二，一是国内主站开发的公司很少，大多数都是买5611或5613卡在PC上开发，用芯片一级开发的基本没有，好像和利时有用，但不大清楚他们是如何做的。
你说的CAN与RS485是一级是有问题的，因为RS485是物理层协议，只定义物理层的特性，而CAN包括数据链路层，PROFIBUS-DP也只包括物理层、数据链路层和用户接口层。所以CAN与PROFIBUS是同一层次的协议。
DeviceNet是在CAN协议上开发的，主要定义了规约和具体的工控行业应用的接口与PROFIBUS的行规有些相似。
PRFIBUS在大型控制系统的应用比CAN的可靠性要高，原因如下：
CAN是竞争型多主协议，所以时延不稳定，在工控现场这是很麻烦的，所以DeviceNet主要的工作就是对这一部分的约束。而PRFIBUS是令牌网，所有的时间都是可以确定的，这对于高可靠和高实时性的大型控制系统来说更适合。
CAN的开销相对而言比较大，因为CAN的开发是为宝马车上的传感器开发的，所以对于点数要求较大，对于单帧数据量比较小，而站地址和功能码的开销相对比较大，而PROFIBUS是针对替代MODBUS之类的过程控制协议，所以在这方面比较经济。
总的来说各种现场总线的应用范围是不同的。这在我的前几个文档中有说明。
另外优秀与否取决于您对协议的理解，比方说LONWORKS协议很优秀，但是实现很垃圾，特别是他们宣称的坚持型脉冲监听协议实际上根本没有在FFT-10A里面实现，而是简单的发三帧不管对错，1.25M的最大包速也是800包/秒，原因就在这里。
CAN在国内的用户应该说是最多的，主要是开发容易，而PROFIBUS在这一方面的推广相当差，德国人的思维习惯也很不合中国人的胃口，不说主站，全国开发从站的公司都不超过50家。
当然我并不是说PROFIBUS比其它协议优秀多少，而是它在过程控制这个领域应该说是相当棒的，FF的许多的思想就是从PROFIBUS中吸取的。
发表于：2006-02-24 22:39:00
11楼
CAN的数据链路层本来包含在硬件里，而我们所说的485也是硬特性的描述。我认为，在这个角度上，CAN和485相提并论没有问题。
而王版主从开放系统接口的7个通讯层次来看，CAN与485不能并提，也没有错。我觉得这只是一个不同观察角度的问题。
CAN芯片本身支持多主竞争，但是，并不是所有的高层协议都用了它支持多主这一特性。DEVICENET是主从协议，它的时延也是完全可以控制的。所以，这一点上，不能说明PROFIBUS比CAN或DEVICENET的可靠性高。
当然，从开销上来说，CAN的天生特点的确是浪费了一些资源。但这并不会盖过它的优点和灵活性，不能阻止它成为一种优秀的现场总线。
而王版主从开放系统接口的7个通讯层次来看，CAN与485不能并提，也没有错。我觉得这只是一个不同观察角度的问题。
CAN芯片本身支持多主竞争，但是，并不是所有的高层协议都用了它支持多主这一特性。DEVICENET是主从协议，它的时延也是完全可以控制的。所以，这一点上，不能说明PROFIBUS比CAN或DEVICENET的可靠性高。
当然，从开销上来说，CAN的天生特点的确是浪费了一些资源。但这并不会盖过它的优点和灵活性，不能阻止它成为一种优秀的现场总线。
发表于：2006-02-27 11:18:00
12楼
想起时正是忘记：
您说得没有错，DEVICENET正是将ＣＡＮ总线实现了一个软件令牌环，但这就与工业以太网的许多实现方式一样，是通过软件来将一个多主的总线改成一个令牌网．这从开销和实时性上来说要差许多，因为如果数据链路层能在硬件里面处理，那么帧间死区时间将是固定的，可以做到很小，比方说1ms以下，但是如果要通过软件来实现令牌网，则数据包要进入单片机软件内处理，一般的时延为数ms以上，如果没有在中断内实现则可能是数十ＭＳ的开销．＼
反之ＰＲＯＦＩＢＵＳ天生则是在硬件内实现的．这里有几个特点，如果大家是从事通信软硬件开发的则可以发现这是相当重要的．
１、每个从站内有多块数据缓存，比方说发送和接收各有三块，每块为255字节，对主站发来的请求，都是在硬件芯片内处理的，不需要CPU的干涉，大家可以看一看SPC3芯片的资料。
2、主站芯片内为每个从站开了N块缓存，同样，对从站的发送和接收都不需要主站的干涉。
3、所有CPU都通过双口RAM与通信芯片接口，通过标志声明CPU占用的数据缓存块，这时ASIC芯片不再更新CPU占用的缓存块，而是对另外两块缓存进行更新。
4、所有的接口均为异步的，不存在等待的任何节点。
5、先天硬件支持的逻辑令牌网，不需要CPU干涉任何通信的报文。
反之CAN与工业以太网，因为设计时不是为了过程控制设计的，他们在节点数和使用方便上更为注重，所以从协议角度来说不适合过程控制。
当然在通过软件的干涉后，他们一样可以完成所有的工作，只是效率要低很多。
说这么多不是说PROFIBUS比CAN优秀，而是设计的用途不一样，CAN是为小系统多节点的传感器总线设计的，而PROFIBUS是为过程控制设计的，双方的定位不同。
最后补充一句，CAN的数据链路层只有一半在硬件内，另一半是要在软件内实现的，这可以参见SJA1000的手册。而反之PROFIBUS-DP的数据链路层和用户接口层均在硬件内，所以不能通过这一点来说明CAN与PROFIBUS不是在同一层。事实上两者均是同一层的，所以不能因此来确定两者不是在同一层。
您说得没有错，DEVICENET正是将ＣＡＮ总线实现了一个软件令牌环，但这就与工业以太网的许多实现方式一样，是通过软件来将一个多主的总线改成一个令牌网．这从开销和实时性上来说要差许多，因为如果数据链路层能在硬件里面处理，那么帧间死区时间将是固定的，可以做到很小，比方说1ms以下，但是如果要通过软件来实现令牌网，则数据包要进入单片机软件内处理，一般的时延为数ms以上，如果没有在中断内实现则可能是数十ＭＳ的开销．＼
反之ＰＲＯＦＩＢＵＳ天生则是在硬件内实现的．这里有几个特点，如果大家是从事通信软硬件开发的则可以发现这是相当重要的．
１、每个从站内有多块数据缓存，比方说发送和接收各有三块，每块为255字节，对主站发来的请求，都是在硬件芯片内处理的，不需要CPU的干涉，大家可以看一看SPC3芯片的资料。
2、主站芯片内为每个从站开了N块缓存，同样，对从站的发送和接收都不需要主站的干涉。
3、所有CPU都通过双口RAM与通信芯片接口，通过标志声明CPU占用的数据缓存块，这时ASIC芯片不再更新CPU占用的缓存块，而是对另外两块缓存进行更新。
4、所有的接口均为异步的，不存在等待的任何节点。
5、先天硬件支持的逻辑令牌网，不需要CPU干涉任何通信的报文。
反之CAN与工业以太网，因为设计时不是为了过程控制设计的，他们在节点数和使用方便上更为注重，所以从协议角度来说不适合过程控制。
当然在通过软件的干涉后，他们一样可以完成所有的工作，只是效率要低很多。
说这么多不是说PROFIBUS比CAN优秀，而是设计的用途不一样，CAN是为小系统多节点的传感器总线设计的，而PROFIBUS是为过程控制设计的，双方的定位不同。
最后补充一句，CAN的数据链路层只有一半在硬件内，另一半是要在软件内实现的，这可以参见SJA1000的手册。而反之PROFIBUS-DP的数据链路层和用户接口层均在硬件内，所以不能通过这一点来说明CAN与PROFIBUS不是在同一层。事实上两者均是同一层的，所以不能因此来确定两者不是在同一层。
发表于：2006-02-28 18:24:00
14楼
所谓硬的协议处理芯片常规的说法，其实也是一个状态机，该状态机根据接收到的报文进行处理，因为不需要做成通用的CPU结构，可以很快的处理各种报文，处理完后的数据有两种处理方式，一种是放在双口RAM内，通过信号与主CPU之间进行交互，这也包括队列、FIFO等N种处理方式，而第二种是接收到数据后通过中断交与CPU处理。
大多数通信芯片都是这两种实现的组合，大家可以看一看以太网芯片的接口定义就是一个共享内存结构，在其中分成了很多块缓存，通过缓存队列来解决一致性和异步的问题。
而SJA1000相对于SPC3来说，处理的层次相对要低，对CPU的依赖性相对较高，包括集成CAN控制器的MCU在内。她没有将数据链路层在芯片内完整实现，当然这主要是成本和一个使用用户的固定程度问题，因为SPC3的设计定位很固定，没有考虑那么多的点数和应用范围，而且对成本不是很敏感，所以可以做得很复杂，将数据链路层和用户接口层均在硬件内实现了。
大家可以这样理解PROFIBUS的芯片相当于一颗带双口RAM的专用CPU，比方说SPC3内有1.5K字节的双口RAM，大家如果买过IDT7171~IDT7174的双口RAM就知道为什么它的价格这么高，而性能这么好了。这都是成本压出来的。
软件来实现硬件的功能差别在于速度，同样的功能用硬件实现比方说定点乘法器，用软件可能要数百个周期，而用硬件则只需要一个周期。所以你用软件来实现同样的性能在CPU的性能上就要求更高了。
前两年大家都强调用软件来实现硬件的功能来解决灵活性和成本的问题，但现在IC设计和流片的成本大降，己不能再死守原来的设计思想了，国外现在软硬结合的开发方式越来越常见，正于您说的软硬之间的边界也越来越模糊了，现在开发IC也用C语言了，只是在实现层时还使用VHDL或者画图。
如果要实现一个SJA1000估计只需要5000门就可以了，而实现一个SPC3需要50000门以上，因为我以前在选现场总线时对各家的协议有过比较深的研究，也做过PROFIBUS主站和LONWORKS协议芯片，所以是有一定根据的。
大多数通信芯片都是这两种实现的组合，大家可以看一看以太网芯片的接口定义就是一个共享内存结构，在其中分成了很多块缓存，通过缓存队列来解决一致性和异步的问题。
而SJA1000相对于SPC3来说，处理的层次相对要低，对CPU的依赖性相对较高，包括集成CAN控制器的MCU在内。她没有将数据链路层在芯片内完整实现，当然这主要是成本和一个使用用户的固定程度问题，因为SPC3的设计定位很固定，没有考虑那么多的点数和应用范围，而且对成本不是很敏感，所以可以做得很复杂，将数据链路层和用户接口层均在硬件内实现了。
大家可以这样理解PROFIBUS的芯片相当于一颗带双口RAM的专用CPU，比方说SPC3内有1.5K字节的双口RAM，大家如果买过IDT7171~IDT7174的双口RAM就知道为什么它的价格这么高，而性能这么好了。这都是成本压出来的。
软件来实现硬件的功能差别在于速度，同样的功能用硬件实现比方说定点乘法器，用软件可能要数百个周期，而用硬件则只需要一个周期。所以你用软件来实现同样的性能在CPU的性能上就要求更高了。
前两年大家都强调用软件来实现硬件的功能来解决灵活性和成本的问题，但现在IC设计和流片的成本大降，己不能再死守原来的设计思想了，国外现在软硬结合的开发方式越来越常见，正于您说的软硬之间的边界也越来越模糊了，现在开发IC也用C语言了，只是在实现层时还使用VHDL或者画图。
如果要实现一个SJA1000估计只需要5000门就可以了，而实现一个SPC3需要50000门以上，因为我以前在选现场总线时对各家的协议有过比较深的研究，也做过PROFIBUS主站和LONWORKS协议芯片，所以是有一定根据的。
热门招聘
相关主题
- 请大家来比比PLC的速度
[13112] - 西门子S7-200 Smart PLC如何...[10237]
- 请教各位大神，关于PLC设置定...[7686]
- 休闲一下，请大家画个闪烁灯的...[9767]
- 请大家使用我开发的软件PLC软...[16298]
- 欧姆龙PLC如何使用MSKS指令编...[8101]
- 一位老工程师收藏的3018套PL...[10712]
- 子程序与中断程序的区别[10972]
- 求助：横河PLC编程软件Widefi...[7230]
- 松下PLC跟串口调试助手如何通...[9693]
官方公众号
智造工程师
-
客服
-
小程序
-
公众号
工控网智造工程师好文精选
