- 浏览: 29335 次
- 性别:
- 来自: 广州
-
最新评论
2 The Eight Myths of Erlang Performance
项目现在终于有点空闲时间了,看看erlang doc,觉得不错,就自己尝试看看,怕不是很理解就翻译出来。自己总结,感觉点很多,要成一个系统的去学习去不断的尝试才能理解这些原则和设计。慢慢去尝试吧。
注:【】内是我自己加的哦】
Here we try to kill the old truths (or semi-truths) that have become myths.
现在我们来粉碎那一些已是神话(过时)的真理或半真理吧。
2.1 Myth: Funs are slow
2.1 funs非常慢【我认为:错60%对40%比MFA还是慢的多,在频繁调用里用MFA好】
2.2 Myth: List comprehensions are slow
2.2 列表解析很慢【错】
2.3 Myth: Tail-recursive functions are MUCH faster than recursive functions
2.3 尾递归比递归快得多【错50%对50%】
So which is faster?
那么。那一个更快?
2.5 "++"总是非常坏的一种选择【错50%对50%】
On the other hand, using ++ like this
但是另一方面:下面这种用法就好了:
OK
Of course, experienced Erlang programmers would actually write
当然,最佳实践还是下面这种:
DO
2.5 Myth: Strings are slow
2.5 字符串很慢【对70%错30%,如果你选择错了,那就会非常痛苦】
2.6 Myth: Repairing a Dets file is very slow
2.6 修复一个dets文件是非常慢【对90%】
2.7 Myth: BEAM is a stack-based byte-code virtual machine (and therefore slow)
2.7 Beam文件是一个基于堆栈的字节虚拟机(所以很慢)【错100%】
2.8 Myth: Use '_' to speed up your program when a variable is not used
2.8 在一个不使用的变量时使用 "_"来加速效率【错】
新一代的影帝!!!
项目现在终于有点空闲时间了,看看erlang doc,觉得不错,就自己尝试看看,怕不是很理解就翻译出来。自己总结,感觉点很多,要成一个系统的去学习去不断的尝试才能理解这些原则和设计。慢慢去尝试吧。
注:【】内是我自己加的哦】
- Some truths seem to live on well beyond their best-before date, perhaps because "information" spreads more rapidly from person-to-person faster than a single release note that notes, for instance, that funs have become faster.
- 一些真相似乎已还是如同从前那么真,因为人人口头留传远比版本上说明快得多,(但不是口口相传并不能记录所有的改变),比如说:匿名函数fun变得更快。
Here we try to kill the old truths (or semi-truths) that have become myths.
现在我们来粉碎那一些已是神话(过时)的真理或半真理吧。
2.1 Myth: Funs are slow
2.1 funs非常慢【我认为:错60%对40%比MFA还是慢的多,在频繁调用里用MFA好】
- Yes, funs used to be slow. Very slow. Slower than apply/3. Originally, funs were implemented using nothing more than compiler trickery, ordinary tuples, apply/3, and a great deal of ingenuity.
- 是的,以前funs是慢,非常慢,比apply/3还慢,是因为最开始时,funs只要为了通过编译(我的理解设计来让编译器不报错,好解释一点),通过最原始的元组,apply/3,和其它的一些新东西来实现的。【由apply/3来实现,固然比apply/3慢一点啦】。
- But that is ancient history. Funs was given its own data type in the R6B release and was further optimized in the R7B release. Now the cost for a fun call falls roughly between the cost for a call to local function and apply/3.
- 但是那已是非常久远的历史了,funs在R6B release(注意不是R16B...)已是一种数据结构了,同时在R7B也做了一些优化,现在fun 的消耗在本地调用和apply/3之间
- 附:目前比较准确的消耗统计:

2.2 Myth: List comprehensions are slow
2.2 列表解析很慢【错】
- List comprehensions used to be implemented using funs, and in the bad old days funs were really slow.
- 列表解析以前用funs实现的,所以在那funs慢的时代自然也很慢啦。
- Nowadays the compiler rewrites list comprehensions into an ordinary recursive function. Of course, using a tail-recursive function with a reverse at the end would be still faster. Or would it? That leads us to the next myth.
- 现如今,编译器用递归重写了列表解析,当然用一个尾递归和一个lists:reverse来实现依然是非常快的。直的嘛,让我们来看看下一个神话。【所以不要用lists:foldr/3而是用lists:foldl/3+reverse/1来做好的多】
2.3 Myth: Tail-recursive functions are MUCH faster than recursive functions
2.3 尾递归比递归快得多【错50%对50%】
- According to the myth, recursive functions leave references to dead terms on the stack and the garbage collector will have to copy all those dead terms, while tail-recursive functions immediately discard those terms.
- 根据尾递归比递归快得多的神话,递归函数把不需要的terms留在栈中并让垃圾回收器来copy这些不需要的数据,而尾递归则是直接把不需要的terms丢弃
- That used to be true before R7B. In R7B, the compiler started to generate code that overwrites references to terms that will never be used with an empty list, so that the garbage collector would not keep dead values any longer than necessary.
- 这在R7B运行是这样的,在R7B,编译器开始用一个空列表来覆盖那些不需要的terms并用这空间来写代码,所以垃圾回收不用再保存那些不必要的值了。
- Even after that optimization, a tail-recursive function would still most of the time be faster than a body-recursive function. Why?
- 那么经过这些优化,一个尾递归是不是还是比一个body-recursive function快一点呢?
- It has to do with how many words of stack that are used in each recursive call. In most cases, a recursive function would use more words on the stack for each recursion than the number of words a tail-recursive would allocate on the heap. Since more memory is used, the garbage collector will be invoked more frequently, and it will have more work traversing the stack.
- 这要看有多少栈空间被用于递归,在大多数情况下,一个递归在栈上使用的空间会比尾递归分在堆上的空间多的多,空间多,自然会触发垃圾回收器更加频繁地遍历这些栈。
- In R12B and later releases, there is an optimization that will in many cases reduces the number of words used on the stack in body-recursive calls, so that a body-recursive list function and tail-recursive function that calls lists:reverse/1 at the end will use exactly the same amount of memory. lists:map/2, lists:filter/2, list comprehensions, and many other recursive functions now use the same amount of space as their tail-recursive equivalents.
- 在R12B及以后的版本中,还有一个优化:使用一个body-recursive 的空间消耗和使用尾递归+lists:reverse/1一样的。list:map/2,lists:filter/3.列表解析及其它的recursive function使用的空间和尾递归是几乎相同的。
So which is faster?
那么。那一个更快?
- It depends. On Solaris/Sparc, the body-recursive function seems to be slightly faster, even for lists with very many elements. On the x86 architecture, tail-recursion was up to about 30 percent faster.
- 这要看情况:在Solaris/Sparc,body-recursive 函数似乎快一点,即使对于一个是非常长的list,在x86结构里,尾递归比body-recursive快30%。
- So the choice is now mostly a matter of taste. If you really do need the utmost speed, you must measure. You can no longer be absolutely sure that the tail-recursive list function will be the fastest in all circumstances.
- 所以现在选择使用那一个,完全是一种个人喜好,如果你真的非常在意速度,你必须要权衡一下,现在请不要相信尾递归在所有的环境下是最快了。
- Note: A tail-recursive function that does not need to reverse the list at the end is, of course, faster than a body-recursive function, as are tail-recursive functions that do not construct any terms at all (for instance, a function that sums all integers in a list).
- Note:一个不需要反转的尾递归绝对比body-recursive function快的!因为尾递归真的是不产生任何多余的数据项,(以上说的消耗来自于lists:reverse/1)
2.5 "++"总是非常坏的一种选择【错50%对50%】
- The ++ operator has, somewhat undeservedly, got a very bad reputation. It probably has something to do with code like
- ”++“ 一直有一个非常不好的声誉,可能原因:你的用法不正确,比如:
naive_reverse([H|T]) -> naive_reverse(T)++[H]; naive_reverse([]) -> [].
- which is the most inefficient way there is to reverse a list. Since the ++ operator copies its left operand, the result will be copied again and again and again... leading to quadratic complexity.
- 这是最没效率去反转一个list,”++“会复制左边的元素,这个会使复制多次,导致平方倍的复杂度。
On the other hand, using ++ like this
但是另一方面:下面这种用法就好了:
OK
naive_but_ok_reverse([H|T], Acc) -> naive_but_ok_reverse(T, [H]++Acc); naive_but_ok_reverse([], Acc) -> Acc.
- is not bad. Each list element will only be copied once. The growing result Acc is the right operand for the ++ operator, and it will not be copied.
- 这并不是一个是非常坏的尝试,每个列表元素只被copy一次,那增长的Acc是在++的右边的,他不会每次都被copy的
Of course, experienced Erlang programmers would actually write
当然,最佳实践还是下面这种:
DO
vanilla_reverse([H|T], Acc) -> vanilla_reverse(T, [H|Acc]); vanilla_reverse([], Acc) -> Acc.
- which is slightly more efficient because you don't build a list element only to directly copy it. (Or it would be more efficient if the the compiler did not automatically rewrite [H]++Acc to [H|Acc].)
- 这比上面的还要高效一点点,你根本不用去建造一个list元素,直接copy他就可以了(或者:如果编译器不把[H]++Acc重写为[H|Acc] ,那就更高效啦)。
2.5 Myth: Strings are slow
2.5 字符串很慢【对70%错30%,如果你选择错了,那就会非常痛苦】
- Actually, string handling could be slow if done improperly. In Erlang, you'll have to think a little more about how the strings are used and choose an appropriate representation and use the re module instead of the obsolete regexp module if you are going to use regular expressions.
2.6 Myth: Repairing a Dets file is very slow
2.6 修复一个dets文件是非常慢【对90%】
- The repair time is still proportional to the number of records in the file, but Dets repairs used to be much, much slower in the past. Dets has been massively rewritten and improved.
- 修复仍然取决于文件中reocord的数量,但是比dets重写后比以前快多了。
2.7 Myth: BEAM is a stack-based byte-code virtual machine (and therefore slow)
2.7 Beam文件是一个基于堆栈的字节虚拟机(所以很慢)【错100%】
- BEAM is a register-based virtual machine. It has 1024 virtual registers that are used for holding temporary values and for passing arguments when calling functions. Variables that need to survive a function call are saved to the stack.
- BEAM 是一个基于寄存器的虚拟机,它有1024的虚拟寄存器来保存临时变量和使用函数。在函数调用后存放的变量放在栈中。
- BEAM is a threaded-code interpreter. Each instruction is word pointing directly to executable C-code, making instruction dispatching very fast.
- BEAM 是一个threaded-code 翻译器,每一个指令都指向对应的c代码,这使得它的调试快的一B。
2.8 Myth: Use '_' to speed up your program when a variable is not used
2.8 在一个不使用的变量时使用 "_"来加速效率【错】
- That was once true, but since R6B the BEAM compiler is quite capable of seeing itself that a variable is not used.
- 这以前是真的,但是自从R6B【为什么讲的都是那么老的版本,感觉这文档是不是过时了呀】,编译器可以自己判断变量是不是没有使用,而做相应的优化。
新一代的影帝!!!

发表评论
-
Erlang 简单的节点互连
2014-03-19 23:41 600自己写的游戏跨服初步构架,以后再一点点完善,先记下时间线哈。 ... -
简单erlang节点互连实验
2014-03-10 15:53 796如果erlang:节点test1,test2互连接: 1.节点 ... -
Erlang OTP gen_event (1)
2014-02-26 15:06 1098演示gen_event的运行过程: mod_event_ma ... -
Erlang OTP gen_event (0)
2014-02-26 14:30 1215原英文文档:http://www.erlang.org/erl ... -
erlang efficient guide 3
2013-08-19 22:19 1136* 3 Common Caveats * 3常见 ... -
fun还是如以前一样狂跩吊么?
2013-08-16 22:26 627fun这么好用。为什么老大在最近都说不要用? gen:cal ... -
emacs 的erlang-flymake
2013-08-14 15:15 1479emacs 设置erlang-flymake erlang- ... -
erlang ets
2013-07-22 23:08 1904参见:http://www.cnblogs.com ... -
erlang的编程规范
2013-03-26 17:17 1981Programming Rules and Conventio ... -
Erlang------Mnesia
2013-03-25 12:49 1727读erlang编程指南Mnesia笔记: 1.mnesia 是 ... -
进程环
2013-03-18 16:48 840编写一个程序,它生成N ... -
匿名函数fun
2012-12-15 16:12 849lists:map(fun/1,[1,2,3]). 小试匿名函 ... -
并发编程实战otp--open telecom platform 二
2012-10-10 23:17 1175第二章:Erlang语言精要。 shell 的启动参数h ... -
并发编程实战otp--open telecom platform 一
2012-10-10 23:16 12601.erlang 的进程模型: 并发的基本单位是进程, ... -
learn some erlang
2012-10-09 22:54 742Erlang has this very pragm ... -
erlang语句块的简洁使用
2012-09-25 22:48 702begin end语句块的简洁使用:问题描述:将一堆人 ... -
命令式编程语言的标杆
2012-09-25 09:47 747命令式编程语言的标杆: 1.进程必须是语言的核心; 2.任何进 ... -
emacs与erlang的完美结合
2012-09-23 22:48 13071.在emacs中使用c+x c+z 启动erlang she ...
相关推荐
RabbitMQ is an efficient, highly scalable, and easy-to-deploy queue that makes handling this message traffic virtually effortless. Offered under an open source license and language neutral, RabbitMQ ...
RabbitMQ is an efficient, highly scalable, and easy-to-deploy queue that makes handling this message traffic virtually effortless. Offered under an open source license and language neutral, RabbitMQ ...
RabbitMQ is an efficient, highly scalable, and easy-to-deploy queue that makes handling this message traffic virtually effortless. Offered under an open source license and language neutral, RabbitMQ ...
内容概要:0欧姆电阻在电路设计中有多种重要作用。它不仅可以在PCB上为调试提供便利,还能用于跳线、替代不确定参数的元件以及测量电路的耗电流。此外,在布线困难时可作为应急解决方案。在高频信号环境下,它能充当电感或电容,有助于解决EMC问题。对于地线处理,0欧姆电阻可用于实现单点接地,避免模拟地和数字地直接大面积相连带来的互相干扰问题。在跨接电流回路方面,它可以提供较短的回流路径,减少干扰。同时,0欧姆电阻还适用于配置电路,防止用户误操作跳线或拨码开关,并且在布线、调试、测试、温度补偿等方面有着广泛应用,尤其在EMC对策中表现突出。; 适合人群:电子工程师、硬件设计师以及对电路设计感兴趣的爱好者。; 使用场景及目标:①在PCB设计阶段,利用0欧姆电阻进行灵活的电路调试与优化;②解决高频信号下的EMC问题,确保电路稳定性和抗干扰能力;③实现单点接地,避免不同地线间的相互干扰;④提高电路的可维护性和可靠性,降低生产成本。; 阅读建议:本文详细介绍了0欧姆电阻在电路设计中的多种应用场景,读者应结合具体项目需求来理解和运用这些知识,特别是在面对复杂的电路布局和电磁兼容性问题时,要充分考虑0欧姆电阻的独特优势。
mysql安装教程 一个基于SpringBoot+Mybatis+Mysql+Html实现的页面登录案例.
在探索智慧旅游的新纪元中,一个集科技、创新与服务于一体的整体解决方案正悄然改变着我们的旅行方式。智慧旅游,作为智慧城市的重要分支,旨在通过新一代信息技术,如云计算、大数据、物联网等,为游客、旅游企业及政府部门提供无缝对接、高效互动的旅游体验与管理模式。这一方案不仅重新定义了旅游行业的服务标准,更开启了旅游业数字化转型的新篇章。 智慧旅游的核心在于“以人为本”,它不仅仅关注技术的革新,更注重游客体验的提升。从游前的行程规划、信息查询,到游中的智能导航、个性化导览,再到游后的心情分享、服务评价,智慧旅游通过构建“一云多屏”的服务平台,让游客在旅游的全过程中都能享受到便捷、个性化的服务。例如,游客可以通过手机APP轻松定制专属行程,利用智能语音导览深入了解景点背后的故事,甚至通过三维GIS地图实现虚拟漫游,提前感受目的地的魅力。这些创新服务不仅增强了游客的参与感和满意度,也让旅游变得更加智能化、趣味化。 此外,智慧旅游还为旅游企业和政府部门带来了前所未有的管理变革。通过大数据分析,旅游企业能够精准把握市场动态,实现旅游产品的精准营销和个性化推荐,从而提升市场竞争力。而政府部门则能利用智慧旅游平台实现对旅游资源的科学规划和精细管理,提高监管效率和质量。例如,通过实时监控和数据分析,政府可以迅速应对旅游高峰期的客流压力,有效预防景区超载,保障游客安全。同时,智慧旅游还促进了跨行业、跨部门的数据共享与协同合作,为旅游业的可持续发展奠定了坚实基础。总之,智慧旅游以其独特的魅力和无限潜力,正引领着旅游业迈向一个更加智慧、便捷、高效的新时代。
内容概要:本文详细介绍了如何通过PLC程序实现模拟量滤波防抖,确保电流、电压和热电阻等信号的准确采集。核心算法采用掐头去尾平均法,即去掉一组数据中的最大值和最小值后取剩余数据的平均值,以消除因环境干扰导致的异常值。文中提供了详细的代码实现步骤,包括数据结构定义、主程序逻辑、间接寻址方法以及参数配置。此外,还讨论了如何通过死区判断和上升率限制进一步优化滤波效果,提高系统的稳定性和响应速度。 适合人群:从事工业自动化领域的工程师和技术人员,尤其是熟悉PLC编程和模拟量信号处理的专业人士。 使用场景及目标:适用于需要高精度模拟量信号采集的工业控制系统,如电力、化工、制造业等领域。主要目标是提升数据采集的准确性和稳定性,减少外部干扰带来的误差。 其他说明:文中提供的代码示例基于西门子S7-1200/1500系列PLC,但相关原理和方法同样适用于其他品牌的PLC。建议在实际应用中根据具体情况调整参数设置,以达到最佳效果。
内容概要:本文详细介绍了大模型的发展现状与未来趋势,尤其聚焦于DeepSeek这一创新应用。文章首先回顾了人工智能的定义、分类及其发展历程,指出从摩尔定律到知识密度提升的转变,强调了大模型知识密度的重要性。随后,文章深入探讨了DeepSeek的发展路径及其核心价值,包括其推理模型、思维链技术的应用及局限性。此外,文章展示了DeepSeek在多个行业的应用场景,如智能客服、医疗、金融等,并分析了DeepSeek如何赋能个人发展,具体体现在公文写作、文档处理、知识搜索、论文写作等方面。最后,文章展望了大模型的发展趋势,如通用大模型与垂域大模型的协同发展,以及本地部署小模型成为主流应用渠道的趋势。 适合人群:对人工智能和大模型技术感兴趣的从业者、研究人员及希望利用DeepSeek提升工作效率的个人用户。 使用场景及目标:①了解大模型技术的最新进展和发展趋势;②掌握DeepSeek在不同领域的具体应用场景和操作方法;③学习如何通过DeepSeek提升个人在公文写作、文档处理、知识搜索、论文写作等方面的工作效率;④探索大模型在特定行业的应用潜力,如医疗、金融等领域。 其他说明:本文不仅提供了理论知识,还结合实际案例,详细介绍了DeepSeek在各个场景下的应用方式,帮助读者更好地理解和应用大模型技术。同时,文章也指出了当前大模型技术面临的挑战,如模型的局限性和数据安全问题,鼓励读者关注技术的持续改进和发展。
内容概要:本文详细比较了四种基于最小二乘支持向量机(LSSVM)的短期电力负荷预测算法:原始LSSVM、SSA-LSSVM、VMD-LSSVM以及VMD-SSA-LSSVM。通过对这些算法的具体实现和性能评估,展示了每种方法的优势和局限性。实验结果显示,随着算法复杂度的增加,预测精度显著提高,特别是VMD-SSA-LSSVM在RMSE和MAPE等评价指标上表现出色,达到了接近真实值的预测效果。然而,这也伴随着计算成本的大幅上升。 适合人群:从事电力系统调度、数据分析、机器学习领域的研究人员和技术人员。 使用场景及目标:适用于需要进行短期电力负荷预测的研究项目或实际应用,旨在提高预测准确性,减少因天气变化、节假日等因素带来的不确定性影响。 其他说明:文中提供了详细的Python代码片段,帮助读者理解和复现相关算法。同时提醒,在选择模型时需综合考虑预测精度与计算效率之间的平衡。
内容概要:本文详细介绍了一种基于Python和Django框架构建的电影推荐系统。该系统不仅涵盖了用户端的基本功能(如登录、搜索、浏览、评论、评分、收藏),还包括管理端的增删改查操作。后端使用Python和Django框架,结合MySQL数据库,前端采用HTML、CSS和JavaScript实现交互界面。推荐算法方面,利用机器学习和深度学习技术,特别是协同过滤和内容过滤相结合的方式,确保推荐结果的多样性和精准性。此外,文中还讨论了一些常见的技术挑战及其解决方案,如用户冷启动问题、前端交互效果优化、数据库配置错误等。 适合人群:具有一定编程经验的Web开发者和技术爱好者,尤其是对Django框架、机器学习和深度学习感兴趣的读者。 使用场景及目标:适用于希望深入了解并实现一个完整的电影推荐系统的个人或团队。主要目标是掌握如何整合前后端技术,运用机器学习和深度学习算法提升用户体验。 其他说明:文中提供了大量代码片段和实践经验,帮助读者更好地理解和实施各个技术细节。同时强调了系统优化的重要性,如通过Redis缓存提高查询效率,使用AJAX实现无缝加载等。
内容概要:本文探讨了基于MATLAB平台的V2G(车辆到电网)光储充一体化微网多目标优化调度策略。该策略旨在通过建立光伏微网中以经济性和并网负荷波动率为双目标的蓄电池和V2G协同调度模型,利用粒子群优化(PSO)算法求解模型。文中详细介绍了模型搭建、核心算法实现、运行模式对比以及算例分析。结果显示,V2G模式能够显著提高系统的经济性和稳定性,减少蓄电池的需求量,优化三方(电网、微网调度中心、电动汽车用户)的利益。 适合人群:从事电力系统优化、智能电网研究的专业人士,尤其是对MATLAB编程有一定基础的研究人员和技术人员。 使用场景及目标:适用于需要优化光储充一体化微网调度策略的研究机构和企业。目标是在保证系统经济运行的同时,稳定并网负荷,减少波动,从而提升整体性能。 其他说明:代码注释详尽,包含并行计算框架、电池寿命模型和可视化模块等多个亮点。通过实际案例验证,证明了V2G模式的有效性。
内容概要:本文详细介绍了三菱FX3U五轴钻孔机的PLC程序和威纶通触摸屏配置,涵盖梯形图编程、IO分配表、参数设置、自动补偿机制以及异常处理等方面。文章通过具体的代码实例展示了如何实现加工循环、参数动态调整、安全防护等功能,并分享了调试过程中遇到的问题及解决方案。此外,还提供了完整的工程文件,便于读者快速理解和应用。 适合人群:从事工业自动化领域的工程师和技术人员,尤其是对三菱PLC和威纶通触摸屏有一定了解的人群。 使用场景及目标:帮助读者掌握五轴钻孔机的控制系统设计方法,提高编程效率和设备稳定性,适用于类似机床控制系统的开发和维护。 其他说明:文中提到的许多技巧和注意事项来源于作者的实际工作经验,对于初学者来说非常有价值。同时,提供的完整工程文件可以作为参考模板,节省开发时间和成本。
matlab开发相关资源
a383d-main.zip
智慧小区解决方案.pptx
Seafile 基于 Qt 的 GUI 客户端
内容概要:本文详细介绍了无人驾驶车辆在局部路径规划中的两种经典算法——Astar和RRT的Matlab实现及其优化。首先,文章解释了Astar算法的核心思想,即通过启发函数进行路径搜索,并针对U型障碍等问题提出了双向搜索策略和动态权重调节。接着,文章探讨了RRT算法的特点,如随机生长特性和路径平滑处理,解决了路径过于曲折的问题。此外,还提出了一种混合算法HRA*,通过改进OPEN集的维护方式,提高了算法效率。最后,通过对不同场景的仿真测试,展示了两种算法在复杂环境中的性能差异,并提供了详细的调参经验和优化建议。 适合人群:对无人驾驶技术和路径规划感兴趣的科研人员、工程师以及有一定编程基础的学习者。 使用场景及目标:适用于研究无人驾驶车辆在复杂环境中的路径规划问题,帮助研究人员理解和优化Astar和RRT算法,提高路径规划的效率和准确性。 其他说明:文中附有大量Matlab代码片段和仿真结果图表,便于读者理解和复现实验。同时,提供了关于栅格地图分辨率、车辆动力学参数等方面的实用建议,有助于实际系统的部署和优化。
选择
内容概要:本文详细介绍了西门子200Smart PLC与维纶触摸屏在某疫苗车间控制系统的具体应用,涵盖配液、发酵、纯化及CIP清洗四个主要工艺环节。文中不仅展示了具体的编程代码和技术细节,还分享了许多实战经验和调试技巧。例如,在配液罐中,通过模拟量处理确保温度和液位的精确控制;发酵罐部分,着重讨论了PID参数整定和USS通讯控制变频器的方法;纯化过程中,强调了双PID串级控制的应用;CIP清洗环节,则涉及复杂的定时器逻辑和阀门联锁机制。此外,文章还提到了一些常见的陷阱及其解决方案,如通讯干扰、状态机切换等问题。 适合人群:具有一定PLC编程基础的技术人员,尤其是从事工业自动化领域的工程师。 使用场景及目标:适用于需要深入了解PLC与触摸屏集成控制系统的工程师,帮助他们在实际项目中更好地理解和应用相关技术和方法,提高系统的稳定性和可靠性。 其他说明:文章提供了大量实战经验和代码片段,有助于读者快速掌握关键技术点,并避免常见错误。同时,文中提到的一些优化措施和调试技巧对提升系统性能非常有帮助。
Prosemirror 是一个基于 ContentEditable 的所见即所得 HTML 编辑器,功能强大,支持协作编辑和自定义文档模式Prosemirror 库由多个单独的模块