对于卡内基梅隆大学计算机系删除基础课程中的面向对象编程课程，如何理解他们提到的「面向对象编程既是反模块化的又是反并行的」？
对于该问题，Quora上已经有人询问，但是总是觉得未能真正理解这句话。 附：
按投票排序
这里的反应该理解为，面向对象编程不适合模块化、并行化。或者说OOP必然在模块化和并行化方面遇到一些障碍。但我觉得这并不是说OOP有什么不好，因为任何一种编程范式都有自己的局限。这事儿不能去较真成OOP不能模块化和并行化。就像你不能去较真C语言没办法OOP一样，你愿意的话可以自己搞出很多特性比如说私有（静态局部变量）、多态（函数指针）之类。这里的反的意思就是不适合，不好用的意思。说起来，现在的编程语言都是多范式的，OOP不适用于这，不适用于那其实也没啥问题。适合的场景使用适合的范式。OOP作为一门编程的基础课程被删除我还是比较赞成的，OO的优势桌面应用主要在于GUI，企业开发主要在于领域建模。而这些都与编程的基础课程没有什么太多的关系，换言之OOD是OO的骨，先学会设计和建模再运用OOP来实现这些理念才是最好的，而设计建模显然又不是基础课程的领域。所以不如在基础课程中废除OOP。照猫画虎不如先练好本领去画真老虎，否则只能反类犬。有些人用物理定律来打比方，是不合适的。OO是为了解决特定问题而被发明的范式，所以不去了解那些特定的问题，把OOP当作基础教学，是有问题的。就像绕开光速不变去谈狭义相对论一样，只能听个云山雾绕。事实上OO这个范式是非常年轻的，与大家所了解的不同的是，目前看起来是突然兴起的函数式啥的才是真正的元老和基础中的基础。其实我倒是觉得及早的让学生接触多范式语言，认识到编程不是一招鲜吃遍天的，会比较好，就这一点上，我觉得C#比C更适合用来教学。从这个反字里面我倒是嗅到了万能范式的味道，好像存在一种万能的编程方式，学会了就能快速NX的开发各种程序，这样说来的话，也许不是个好事。顺便说一下OOP怎么去做高并发。事实上OOP做高并发是很正常而且一点儿也不恐怖的事情，虽然说函数式在多线程的情况下会有先天的优势，但是上面一群人把OOP的多线程未免也抹的太黑了。首先抛弃对象的状态是扯淡的，这就不是OOP了。对象因有状态而成为对象，否则就是个函数集（Function Set），写出来的代码不叫做OOP，而是FP。并不是说，用OO的语言写出来的代码就都是OOP的。其次，由于状态的存在，所以所有的实例方法都应当假定是线程不安全的。说白了不必看源代码，如果一个方法不依赖于对象的状态，直接静态好了（否则就是糟糕的设计）。仅为了重写而专门写成实例方法的不依赖于对象状态的做法也是dirty的。所以，OOP的所有方法都是基于状态的，这个问题似乎无解了？怎么可能！那互联网还开发个球啊。所以OOP中多线程的方案就是不要跨线程共享非只读对象，就这么简单，是不怎么优美，但还能用。把状态局限在一个线程内，就啥事儿也没有了。什么？这样你就只能开一个线程了，那你干吗非要OOP来的。
这个问题的根本在于 OOP 是基于状态的。每个对象都维护着自己的状态，暴露给外界的是一些可以改变对象状态的方法。一个对象的状态里可以有对其他对象的引用，一个对象的方法也可以调用其他对象的方法来改变其他对象的状态，所以这些状态还是关联的。很多人提到的线程安全与效率的取舍之类其实都是细枝末节，即使是有办法把所有方法都能高效地实现并且全都是线程安全的，只要状态存在，状态带来的问题就存在。在一个复杂的并发系统中，你调用 foo.bar(42)，几个指令之后再调用 foo.bar(42)，两次调用的结果很可能是不一样的，因为在这中间 foo 的状态可能已经改变了，或者 foo 引用的某个对象的状态可能改变了，不去看 bar() 的实现根本不知道结果依赖于什么。同样一段程序多次运行因为时序的不确定性可能结果也不一样。不管 OOP 也好，过去说的过程式编程也好，理论基础都是图灵机模型，而图灵机就是依靠对状态的记录和改变来进行运算的。图灵机里的纸带和状态寄存器用来记录状态，而读写头用来访问和改变状态。想象一下一个并行的图灵机（多个有独立状态寄存器和不同速度的读写头加上一条共享的纸带）就不难理解在这个模型下并发带来的复杂度。而目前很多人因为并发的需求所崇尚的函数式编程是基于 Lambda Calculus 的计算模型。计算由层层嵌套的函数调用完成；每个函数调用的结果只依赖于函数和它的参数。如果 f(4, 5) = 10，那么无论你在什么时候调用 f(4, 5)，它的结果都是 10。相对而言，这是一个比较干净，比较容易推理和确保正确性的模型。OOP 的程序通常有很多隐藏的数据依赖，函数式编程把这些数据依赖都明确化了。但函数式编程最大的一个问题是，函数是一个数学抽象，在现实世界中不存在，它必须被模拟出来。目前为止被广泛使用的计算机还是基于图灵机模型，计算机的寄存器、缓存、内存就是用来记录状态的。要真正懂得程序设计，必须知道没有状态的函数是如何在充满状态的计算机上实现的，所以还是绕不开非函数式的编程。另外绝大部分的函数式程序设计语言都不是纯函数式的，出于实用性考虑都夹杂着其他语言的一些特点，并没有完全排斥状态。Haskell 号称纯函数式语言，用 Monad 来抽象状态，理论上可以自圆其说，但在实际使用中其实还是带来了很多不便（于是又发明了 Monad Transformer...）。从某种程度上说，状态是绕不过去的，毕竟人感知到的宏观世界就是由各种各样有各自状态的对象构成。函数式编程可以帮我们避免很多用其他方式容易犯的错误，在很多情况下写出更高质量的程序，但并发带来的复杂度并不会从根本上消失。各种编程风格一定是互相影响推动程序设计语言的进化，没有绝对的好坏，从 C++ 和 Java 最新标准里引入的函数式方面的功能就很容易看出这一点。比较有意思的是，OOP 最早是在 LISP 里实现的，而 LISP 也被很多人看做函数式编程的起始。同样，好的程序员也会根据具体情况使用合适的编程风格。OOP 不失为一种比较容易理解的在计算机程序里对现实世界的抽象，在很多场合的应用是非常成功的，至少我没发现以图形用户界面为中心的程序里有比 OOP 更行之有效的抽象方式。把 OOP 从程序员的教育中去掉过于片面和激进了。如果是从基础课程调整为选修课程则是可以理解的，我上本科时记得也是那样设置的。
这个问题我在stackexchange上问过，有很多很好的回答，可供参考。
说实话，用面向对象的手法来写并发程序真的是难爆了。我最近在里面添加一个“从EBNF自动生成智能提示”的算法（写得差不多了，代码一直在 上更新），就遇到了这个问题。我们都知道，唯一可以给UI建模建的好用起来又爽的也就只有面向对象了，但是写智能提示又怎能不并发呢，于是我只好把OO和Actor这两种风格在C++里面混合了起来。幸好OO是鼓吹封装的，于是我把那些不需要给别人操作的Actor们也装在了另一个大类里面，用户只需要单线程的操作这个类就可以了。多线程的部分就在这个类的内部。于是当你操作不当的时候，不可避免的会遇到racing condition。什么是racing condition呢？就是多个函数同时运行之后的结果，跟他们挨个运行之后的结果不一样。你可以想象一下我同时对一个变量+1两次，如果你加的方法不对，有时候就会发生racing condition——结果只加了1，不是2。于是你就会慢慢明白OO跟并发到底抵触在哪了。防止racing condition，写出一个正确的并发程序，是需要你小心翼翼（对大部分流行语言都有是，除了Haskell）的处理一些状态变量，而OO却是希望你通过释放接口来阻止你对状态变量的认识（嗯， 说得对，面向对象他妈就是个祸害。而且祸害就算了，面向对象本来应该用interface oriented programming（认真学习COM就会得到这一点，但是这里的interface并不一定需要是语法上的interface。所以说很多不学无术的人除了喷COM难用以外根本没办法从她身上学到任何东西，这些程序员都是a piece of shit）来做，结果那帮人竟然鼓吹什么is-a啊，has-a这些伤天害理的知识，绝对是计算机科学教育的第一大祸害）。于是你现在开始写代码的时候就会遇到这个问题了：这个类的这个方法到底能不能并发呢？ 呵呵，如果没有文档，也没有源代码，你永远也回答不出这个问题。这是不是意味着我们必须把每一个method都做成线程安全的呢？这当然不是，线程安全是会损耗性能的，而且不能忽视。那是不是为了性能就全部都做成线程不安全的呢？当然也不是，正确性永远都是第一位的。那到底要怎么做呢？当你用OO和并发一起做的时候，你除了付出痛苦来单独思考每一个method是不是需要做成线程安全以外，没有任何指导方法或者科学依据来减轻你的负担。当然对于工程师来讲，只要公司多给点钱，那我们自然可以把程序写得更好，于是这点小问题还是无所谓的。但是对于那帮做学术的人来讲，那就不一样了。他们眼中只有行跟不行，于是自然就说出这句话了。不过我认为这句话说的也是有道理的，我并不是在说他们说的不对，我是在同意他们。OO和并行你想做的好，除了看Jeffrey Richter的书以外，没有任何办法。但是我们知道，很多懒惰的人根本连教程都不愿意仔细看，怎么会学到正确的并发程序的设计方法呢？
流行的面向对象编程其实是对这一概念的误解，更像是市场推广。我觉得首先要正确理解这一概念才能谈是否是反模块化和反并行的。面向对象编程这一概念是由Smalltalk的发明人Alan Kay（不了解的人请Google）首先提出的。按Alan Kay的看法，面向对象最重要的一点是消息传递OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.见面向对象就是为了解决大规模编程的复杂性问题提出的，用消息传递的方式降低模块之间的耦合。目前最流行的并发编程语言就数Erlang和Go了。根据Erlang之父Joe Armstrong，Erlang其实也是面向对象编程语言，在小的方面来讲又是函数式编程语言，所以面向对象和函数编程并不矛盾。（见)Erlang建立在Actor Model之上，而Go建立在Communicating Sequential Process之上，这两个计算模型都跟Alan Kay的消息传递模型有相通之处。所以说，消息传递模型也能很好地解决并发编程的问题。虽说纯粹的函数式编程语言没有状态，也就不存在竞争问题，适合并发，可那只是美好的愿望罢了，更像是书呆子的意淫，在现实世界中怎么可能完全消除状态，就连Haskell也要发明复杂的Monad来解决状态问题，所以说函数编程并不是解决并发问题的灵丹妙药。编程语言的发展过程可以看作不断远离图灵机模型而接近人脑思维模型的一个过程，最开始是汇编语言，直接操作图灵机的状态；然后是过程化编程范式，用各种更有局限的控制语句替代过于灵活的go to，现在则是面向对象和函数式编程语言的天下。简单地讲，就是要解决如何摆脱赋值语句的问题。面向过程和面向对象都没完全摆脱赋值语句，但是施加了更多的限制，防止赋值语句滥用。函数式编程企图使用数学意义上的函数概念完全消除赋值语句，但是没有成功，只得用更隐晦的方式加以保留。PS. 另外吐槽一下，在知乎上编辑文字真麻烦，排版又难看，既然要抄袭stackoverflow，为啥不全抄过来！
基于状态做多线程一点问题都没有。现在的 OOP 的问题在于，这些语言都尝试把对象之间的消息传递重新嫁接在过程调用上，这是一切的原罪。正如 FP 如果直接用 C 的 calling convension 和 stack 的话一样会死，必须发明另外的组织方法一样。解法很简单：Actor。一个完美的体现 OO 精髓、完美表现对象之间“消息通信”，完美解决竞争状态和死锁可能，同时比函数式编程直观。Actor 的模型更从设计行提供了更多优化和扩展的可能性：，如 M:N 线程调度（"~2.5 million actors per GB of heap." with Java / Scala [3]），以及分布式调度 [3]。所有真正的高并发库都是基于 Actor 模型的，从古老的 Erlang 到 Ada 和 Go（mk chan），以及 Scala 和某个 Clojure 1.5 新加的 Actor 库（找到了 [1]），以及 JVM 平台的 Kilim [2] ……真的不需要多说什么了。如果略微没有概念，推荐每个人去看 [4]：Rob Pike 介绍自己在 Plan 9 发明的 Newsqueak 语言的演讲。我自己看过之后对很多之前看 Golang 中云里雾里的疑惑都得到了清晰的来龙去脉的解答。[1] [2] [3] [4]
人家只不过是把OO的东西放到二年级去选修了。作为大一新生，先掌握基本编程技术进而学习数据结构和算法才是重要的，所以人家开了两门基础编程课程，一个函数式编程，一个指令式编程。没仔细看是不是这两门选一个修，还是都要修。我上大学的时候有一些兄弟是学scheme作为入门编程的，多数人都是java，到了下学期数据结构也是用java讲的，scheme的兄弟们就比较痛苦。。。课程设置不合理害死人啊
各位不要把因为自己没有找到好的方法，就埋怨语言的支持不好，语言层面的支持如果做到完美，那还要这么多高级的软件工程师干嘛，OOP是一种思想而已，就看你怎么用，面向事件驱动的设计模型当然可以很好的做到一个线程内支持大量并发的问题，关键就是看你如何去设计你的程序，如何去封装和定义你的事件，没有人让你再设计程序的时候一个劲的什么地方都使用OOP思想，才是遵循了OOP，一个复杂的软件里面，会同时存在这多种思想，只是在不同的角度和层次上看看，不同的思想会有一个主流的概念，比如在系统底层的通信机制和并发领域，可以使用基于事件驱动的设计，此处不是OOP的，但是对于系统服务层面的支撑模块，完全可以使用OOP的思想，毕竟OOP带给了软件行业非常大的发展，是有他的很大价值的。王根这哥们说的太偏激了，软件编程不光是给高级工程师的，那些大量存在的中间或者底层的开发人员需要面向对象的思维方式来工作，高级工程师的需要做的就是把难题隐藏起来，对于底层难题，没有人告诉你一定要用什么思想去实现，没有人要求你的代码在这个层面也需要拥有非常好的可读性，如果你非要跟OOP去较真儿，说他的什么什么方面做的不够好，那谁也没有办法。
开发有三种类型，或者程序员有三种类别。写框架的，写库的，和写功能的。面向对象之所以被很多人诟病的原因之一，是在框架和库的层次（如果这两个一起开发的话），他会形成巨型的继承树，一旦这颗树的设计出现问题，做细节的微调还可以，比如功能函数的上推下拉，局部重构等等，但是如果做大的调整很容易造成重大兼容性问题。面向对象之所以被很多人诟病的原因之二，是在写功能的层次，很多程序员都试图做出更大更深层次的抽象，不停的做抽象类和接口，在代码中生成大量的粘合层，而这些内容应该放到框架和库的层次去做，而不是在做功能开发时为了未来可能有的功能埋下大量的代码接口而忽略了开发功能的本质工作。面向对象之所以被很多人喜欢的原因之一，是适合描述世界。在进行编码的时候，需要做问题空间到解空间的映射，这个时候面向对象方式最接近人类的思维方式，这就是面向对象的东西总是相对的容易理解和使用。在过程式编程的时代，人们认为程序=数据结构+算法。而在面向对象时代则认为，对象=数据结构+算法，程序=对象+对象+...+对象。多了一层“封装"之后，对接口的理解更容易了，但是也付出了性能，维护，设计等等问题上的代价。并且对很多底层知识的理解，其实是不利的。我也曾经认为面向对象可以解决一切问题，设计模式可以解决一切问题，但事实证明如果一个东西被认为是万能神药，基本上就是骗人的。当我在编码中越来越痴迷于如何抽象和形成扩展可维护性，而耽误了正常功能进度时，我总是怀疑是否自己面向对象的功力还不够……现在我认为，面向对象也只是编程范式的一种，也只是一种解决问题的工具。适当的运用，还是很有必要的。对面向对象缺乏信心的人，可以看Qt的接口。Qt证明了面向对象也能做的非常出色，即使是在C++这种复杂的语言怪物上。不客气的讲，中国程序员偏重归纳总结和细节上的奇技淫巧，不擅长抽象和设计，而这些恰恰是面向对象系统最需要的素质。国内项目的话，如果做设计，常见的情况是，把其他人验证过的抽象，重做一次，这样最保险，但如果需要自己做抽象和设计的时候，往往会卡壳。面向对象系统的设计，如果没有大把的时间金钱和精力，不要做过渡尝试，因为只有不停的重构提炼，抽象才能越来越精确。对于中小公司的中小型项目，如果非要自己做框架和库的话，继承层次不要超过三到五层为好。也可以玩一玩组件式，那东西扩展性不错。
我们知道，命令式编程相当于在管理状态机。而其中的面向对象编程则相当于同时管理多个状态机，还要让它们之间交互，显然很难啊，也体现不出良好的划分啊。这就可以解释面向对象编程为什么是反模块化和反并行的。但是经过长期的发展，在各种设计思想和模式的帮助下，我们通过在一些经过充分研究的场景采用特定的编程模式，能相当程度地hold住多个状态机，从而在开发效率、运行效率、正确性、可靠性等方面取得一个较好的折中。我对函数式编程了解不深，但是对Closure, CPS, Functional Data Structure这些东西看着挺喜欢的。如果函数式编程的生态环境能发展到接近面向对象编程的程度，那也挺好啊。话说回来，我最喜欢的是类型系统，至于我擅长的OOP，还是我不擅长的FP，都不重要了。它们的大部分东西在我眼中没有区别。
已有帐号？
无法登录？
社交帐号登录写了两个FPGA程序，是两个模块，如何将这两个模块连接到... - FPGA|CPLD|ASIC论坛 -
中国电子技术论坛 -
最好最受欢迎电子论坛!
后使用快捷导航没有帐号？
写了两个FPGA程序，是两个模块，如何将这两个模块连接到...
13:40:07　　
写了两个FPGA程序，是两个模块，如何将这两个模块连接到一起进行编译仿真。应该如何操作。
14:20:24　　
每个模块都生成symbol，然后建一个原理图文件 调入symbol进行连接 这个最简单了
22:52:26　　
正在学习，膜拜楼上
22:44:29　　
除了symbol，还有原件例化语句！不过原理图更直观简单！
08:08:21　　
原件例化语句 可以由原理图直接生成的 所用还是原理图方便 做testbenth 的时候还是要用.v文件的
20:55:53　　
我觉得还是例化好吧，模块多了信号多了原理图就有点复杂
22:20:52　　
用顶层.v对这两个模块例化就可以啊。
09:28:57　　
生成Symnbol最简单直观，链接好后，还可以再生成Verilog代码保存，便于兼容
22:06:48　　
例化没试过，不过原理图倒是明白，学习中
Powered by后使用快捷导航没有帐号？
&&&全站 说: 5天前全站 说: 7天前全站 说: 27天前全站 说: 石化区“我在节能你在哪里”7月底活动结束，8月份公布获奖选手。未参与人员尽快参加。
全站 说: 全站 说: 全站 说: 全站 说: 全站 说: 全站 说:
查看: 2517|回复: 13
请教高手cs3000程序的两个问题
(537053号)
收到鲜花 朵
阅读权限30
主题好友积分
签到天数: 16 天连续签到: 1 天[LV.1]海川新人&
本帖最后由 jlshnlhj 于
14:28 编辑
你得多看手里的IM资料.你的是CS3000系统?版本是多少?
1.R3.09版本在LINK BLOCK里没有SIO-8和PIO-8.只有PIO和AREAIN,AREAOUT.估计SIO-8就是AREAIN/OUT.
2.sio-21的输入不是IN,是Q01和Q02.
3.&SV25501-O，SV25501-C只是定义了地址但程序中没有出现。&不知所云.看不明白.
4.在PIO中这样填用户TAG ID,编译能通过?
又及:看明白了,sio-21:SV25501-O连Q01,SV25501-C连Q02.就是两个输入信号.
积极参与交流
积极参与交流
(532841号)
收到鲜花 朵
阅读权限60
签到天数: 118 天连续签到: 0 天[LV.4]海川常住居民I&
第二个图中端子错了
(291353号)
收到鲜花 朵
阅读权限85
主题好友积分
签到天数: 5 天连续签到: 0 天&
申领前提条件为5威望，对海川热心参与的会员
TA在日20时41分获得了这枚徽章。 []
第一个问题是早期的版本吧，第二个问题，一般都是卡件里面同样的阀门两个信号物理位置是相邻的，一般只需要将第一个的地址写在通道里就行，系统会自动的读到第二个DI，一般组态都是只连接一个。
帮助他人解决问题,互助方可提高
(153523号)
收到鲜花 朵
阅读权限20
主题好友积分
该用户从未签到&
你得多看手里的IM资料.你的是CS3000系统?版本是多少?
1.R3.09版本在LINK BLOCK里没有SIO-8和PIO-8.只有PIO ...
jlshnlhj 发表于
& & 先谢谢您的指点。
1.我这里版本是R3.07，我想问下SIO和PIO在什么情况下使用？
2.Q1和Q2在sio-21中没找到
sv25501.JPG (47.33 KB, 下载次数: 0)
14:44 上传
4.请教您那里是如何定义地址的？
(153523号)
收到鲜花 朵
阅读权限20
主题好友积分
该用户从未签到&
第二个图中端子错了
xyhunter 发表于
& & 先谢谢您的指点。
怎么错了？可以编译，而且开关正常啊。
(153523号)
收到鲜花 朵
阅读权限20
主题好友积分
该用户从未签到&
第一个问题是早期的版本吧，第二个问题，一般都是卡件里面同样的阀门两个信号物理位置是相邻的，一般只需要 ...
hallon520 发表于
& & 谢谢您的指点。
(537053号)
收到鲜花 朵
阅读权限30
主题好友积分
签到天数: 16 天连续签到: 1 天[LV.1]海川新人&
本帖最后由 jlshnlhj 于
16:36 编辑
&问下SIO和PIO在什么情况下使用？&.最好ONLINE HELP查一下,印象中PIO是不同FCS和CONTROL DRAW页中的数据LINK.SIO则是不同AREA FCS 数据LINK.
&Q1和Q2在sio-21中没找到& MOUSE点中IN端子,右键,在弹出的菜单中选Q01.Q02.或双击IN.改为Q01.Q02.
帮助他人解决问题,互助方可提高
(153523号)
收到鲜花 朵
阅读权限20
主题好友积分
该用户从未签到&
&问下SIO和PIO在什么情况下使用？&.最好ONLINE HELP查一下,印象中PIO是不同FCS和CONTROL DRAW页中的数据LIN ...
jlshnlhj 发表于
& & 双击连线改q1报错，右键改还是没有QI和Q2
IN.JPG (57.23 KB, 下载次数: 0)
16:48 上传
收到鲜花 朵
阅读权限40
主题好友积分
签到天数: 19 天连续签到: 1 天[LV.1]海川新人&
本帖最后由 summeredge 于
20:17 编辑
SIO-21输入不是Q1和Q2吧
应该就是IN
QQ截图未命名.jpg (36.38 KB, 下载次数: 0)
20:16 上传
QQ截图未命名2.jpg (44.29 KB, 下载次数: 0)
20:17 上传
第二张图没什么问题
对于CS3000的功能块来说，同一个功能块相邻输入或输出物理地址一般只写一个，其他的按地址顺延
积极参与交流
积极参与交流
收到鲜花 朵
阅读权限40
主题好友积分
签到天数: 19 天连续签到: 1 天[LV.1]海川新人&
AREAOUT 用于不同FCS之间的站间数据通讯
AREAIN 用于同一个FCS内不同Conrol Drawing图之间的数据通讯
积极参与交流
(537053号)
收到鲜花 朵
阅读权限30
主题好友积分
签到天数: 16 天连续签到: 1 天[LV.1]海川新人&
本帖最后由 jlshnlhj 于
14:26 编辑
简略查了SIO-21,SIO-21: Switch Instrument Block with 2 Inputs, 1 Output.2个Inputs应是:
IN:Answerback input terminal
4楼仁兄说得对:第一个的地址写在通道里就行，系统会自动的读到第二个DI，一般组态都是只连接一个。&
引自: IM 33S01B30-01E&&D3-176
*1: n in the table indicates the connection destination element of the open answerback signal specified to the answerback input terminal. n+1 is the connection destination lement of the close answerback signal, indicating the next element that follows the element specified to n.
(421156号)
收到鲜花 朵
阅读权限20
签到天数: 2 天连续签到: 0 天&
哇，这里高手很多啊
(421156号)
收到鲜花 朵
阅读权限20
主题好友积分
签到天数: 2 天连续签到: 0 天&
哇，这里高手很多啊，呵呵，以后多多来这里学习
(153523号)
收到鲜花 朵
阅读权限20
主题好友积分
该用户从未签到&
1.在程序制作中输入的模块有两种形式SIO-8和PIO-8不知有何区别？
io.JPG (84.42 KB, 下载次数: 0)
11:01 上传
2.仪表控制块sio-21是两个输入信号一个输出信号吧？可为什么实际只能连接一个输入模块？我这边控制阀门的输入信号是两个一个是开另一个是关，只用了一个SV25501-O，SV25501-C只是定义了地址但程序中没有出现。
sio.JPG (9.59 KB, 下载次数: 0)
11:01 上传
深入讨论内容
海川化工论坛网化工技术交流第一站，共同学习 共同提高!
QQ：合作活动 QQ：
违规贴举报删除请联系邮箱：
丰行天下-海川化工论坛 版权所有--- Powered by