(零)引用:例程和论述

smart200标准化实践20221120.smart.zip

从”技术”上:

(一)前三点都在说跳站和恢复,而跳站和恢复其实是一回事:就是主动检测到掉站的那个任务,主动通知所有和自己相同站号的站点:”你们被跳站了,原因是XXX,你们可以在XXX时刻尝试恢复通讯,在这期间,你们可以选择沉默,但你们说的每一句话都会被跳过忽略以及作为"逻辑程序"出问题的呈堂证供而记录下来”,这样即使有N个相同站号的任务掉站,也只有一个任务在尝试恢复通讯,节省时序和调度.而楼主的例程中没有这样比较合适的处理方式.

(二)后四点都在说自己的通讯程序”干预逻辑程序发过来的新数值的安全性,以及写”老区”数值的合理性.这应该是有问题的,"老区人民"是不需要楼主这么热心的问候,光顾的.具体原因摘抄旧贴回复如下:

(1)在PLC上电启动后，若从站的通信状态良好，那么楼主的程序里的写操作是做什么样的动作？是直接把数据写给从站还是把从站上写寄存器里的数值读回来？有没有什么安全方面的考虑？

答:没理解:

A:有的从站(非标的)某个数据约定好只写,怎么读;即使按您说的写"老数据"直接用本例程现实数据区后面的历史数据区不行吗,还要再去回读?通讯程序(非逻辑程序)怎么能左右要写什么数据呢?触摸屏写给SmartPLC变频数据,难道SmartPLC的逻辑程序(非通讯程序)检测到掉站又恢复后的第一次写就不加判断/不分青红皂白的直接将触摸屏的频率及启动等数据写给变频器从站,让变频器启动了?从站如果没有断线保护,错误机制,心跳超时,......怎么都解决不了您"关心"的安全隐患.

B:如果您指的是回读数据地址Data_Ptr里面的内容,通讯程序只负责投递写数据区的数据.至于上电刚启动该写什么数据:那是用户的逻辑程序部分决定的,逻辑程序要考虑初始化时/出错时的瞬间应该向写数据区赋什么值,这可能和通讯程序关系不大.

C:ModbusRTU应用例程都是通讯程序,只负责数据投递;逻辑程序部分才会考虑初始化时/正常运行时/出现错误时该写什么数据,和通讯程序关系不大

(2)、在PLC上电启动后，若从站的通信状态还没好，那么楼主的程序里的写操作是做什么样的动作？

这时上位机改变了参数后，这参数又是怎么变化的？从站的通信状态又变好了，

那么楼主的程序里的写操作是做什么样的动作？有没有什么安全方面的考虑？

答:帖子的例程里都考虑了,从站没好,就跳站并重新置位#从变才写,并定期尝试再写安全数据;这个重新置位#从变才写是很有逻辑性的,非常必要的,因为掉站没写成功重新置位#从变才写=1就报证恢复后该写任务立马就有机会把掉站瞬间已经重新赋值的/安全的数据写到从站里去了,写的数据恰恰不是之前没写成功的数据,而是安全的数据;至于此时该写什么数据才是安全的应结合具体从站说明定义,并且由逻辑程序而非通讯程序决定.请参见(1)-C,所有的通讯程序绝不能干涉逻辑程序写过来的数据.无论逻辑程序写过来的数据有多么”不安全”,通讯程序必须没有任何折扣100%的执行,这样即使真的因为例程出问题导致事故倒查,也不会是封装好的通讯程序的问题,而是倒查到逻辑程序里面去.

(三)楼主说有变化写入,就楼主的例程看这是不现实的,用户甚至都不知道新增加的可变长度的写任务数据的历史值往哪里存储,比较合理的是存储方式是存储在现实数据区后面,即历史数据紧跟着现实数据存储---因为历史数据就像紧紧的跟着现实数据的影子一样,如影随形,密不可分,而且可变的长度,数据格式都是近似的.楼主的例程既没有合理的变化写入的机制和处理手段,又缺乏合理的数据安排方式,是不可能合理的实现变化写入的.

(四)具体针对例程中:

(1)每个私有的First引脚本质应该由一个公共全局变量来调度,而非私有变量.

(2)用SM0.5一般不会有问题,但作为跳站和恢复超时用是不合适的,因为它的间隙是1秒.

(3)官方恢复AC,我们也照猫画虎恢复AC?

(4)"错误信息"#sMbusMsgError同一个比较指令多处重复书写,大概有十三个地方重复书写#sMbusMsgError的比较,类似其它变量这样的比较很多,俯拾皆是,这难道不比到处用SET/RESET的问题还严重?

(5)例程空间偏大,前三点跳站和恢复有问题,后四点部分代码占用较多(而且出发点都是错的).

(6)实测主帖例程全部掉站如下图

      监控到的状态表里:所有从站站号里只有1号,2号从站在不合理的尝试通讯(无法将信息主动传递给剩余相同站号的1/2站),报错误码3;其余所有站号既没主动的尝试恢复通讯,也没有报错信息(就是状态图表其余站号从站的错误引脚没任何错误信息),这些都是没法恢复通讯的,读者随意下载验证便知。

      如何相对合理的处理所有从站掉站的故障，请翻以前思路二的帖子,里面既有原理分析,又有实测动图.摘抄原帖所有从站全部掉站后,每个从站都尝试恢复通讯的实测动图如下,以下两张动图清楚的表明,在所有从站都掉站后,通讯程序该如何既省时,又相对合理的尝试恢复通讯的情况.

      如上所述:当所有从站都掉站后,实测楼主的例程除1/2号站外,其余站号的从站既没主动的尝试恢复通讯,也没有报错信息.

      总体评价:西门子官方库原本是简洁的,完整的,合理的;从技术角度直白一点说:主帖例程代码虽然敲得辛苦,劳动成果值得尊重,但是和官方库比起来是相反的,即主帖例程真真切切的针对官方库做了无用功.

(五)除去"技术"的问题

在楼主过去,现在异或将来的的文字中:

欢迎拿出漂亮的程序来PK我;MobusRTU已经被我终结了;悬赏1万;Modbus上还没怵过谁;别怪我怼你等等......这些”黑涩会”习气的用语在楼主敲出的文字中是俯拾皆是.

(六)现有机电自动控制方面有”技术”而言的不太多,楼主在论坛积累几年的文字基本都在谈”技术”-暨几十年前的”昨日黄花”-ModbusRTU轮询技术,而且都是带有严重违反论坛版规的”兜售”,各个论坛帖二维码,明示联系方式,”自大”绕过西门子授权等字眼.根据这些事实说你搞笑和兜售冤枉了?人身攻击了?这一桩桩一件件的文字痕迹,图片信息,哪一件不是有据可查,有实可依?这些难道不是板上钉钉的事实?这难道没有吃西门子的饭,砸西门子锅的嫌疑?(2022-11-19:以来仅就第(六)点陆续又增加此地无银三百两的佐证如下图) ;(这些事实清楚既无法洗白,亦非抹黑.Moreover,Who cares about several concerns ?give the thumbs-up by hand slide)

(七)看楼主以前的帖子内容基本都在研究早已被莫迪康终结的,不是问题的问题------如何标准化ModbusRTU轮询,并且多次声称贴出了终结ModbusRTU的例程,但后续检查测试基本都是可以忽略的,并且有很多BUG的例程,而例程的作用除了楼主亲自承认的"蹭热度"兜售外没任何作用(如下图):

敲出的大量代码(劳动成果)虽然可敬,仍不免唏嘘.仅且仅仅在"勇气"这一点上,类似于在征服庞加莱猜想过程中的帕帕.

(八)年轻人喜欢的是充分的自由和丰富的想象或者是别人稍微有点”技术”的心得,而不是营销性质,毫无技术可言的,纯口水仗性质的”标准化”,连命名都是违规,何谈标准化,优雅?

......

(九)评论摘抄:佐证第(五)点.

十:关于楼主主动提出别人的思路一二是"piaoqie"的摘抄:

       虽然窃书不能算偷,但楼主涉嫌"piaoqie"基本算是证据确凿,并且有客观的人证,时间节点证据,对"函数指针"这种简单到不能再简单的技巧,别人的上锁帖程序两年前就有涉及,截至2022-12-01楼主既不知道,帖子更是没有用到这种最简单的技巧,而且又没有早于别人看出来(连楼主自己都承认),还倒打一耙说别人"piaoqie",并煞有介事地"piaoqie"别人早期帖子思路和方法,换个包装兜售标准化,并罗列出来,这些都是无可争辩的事实!,虽然所谓的"piaoqie"根本就不是什么事,况且把它写作汉语拼音本身说明它是无关紧要的,模棱两可的事,但关键是楼主把"它"作为兜售的工具,还倒打一耙.楼主在MobusRTU所谓的轮询上无论是数据结构/逻辑调度/空间紧凑等都是有技术上无法修复必须重写的问题的,吹过的牛(掉站跳过,变化写入等)都被别人的思路二实现了,还倒打一耙说别人的思路是"piaoqie"的......