故事作者:东方红一红

最近创作

看看TA的故事

【征文】CP341手册里的3964R漩涡

已锁定

东方红一红

西门子1847工业学习平台

  • 帖子

    6594
  • 精华

    50
  • 被关注

    131

论坛等级:至圣

注册时间:2003-07-12

钻石 钻石 如何晋级?

【征文】CP341手册里的3964R漩涡

1550

3

2019-08-12 22:17:31

        人们都说书中自有黄金屋,书中有女颜如玉。没听说书中还有漩涡的。确实,要不是我调试中的那个晕延续至今,现在还有点晕,或许就没有了这词不达意的题。其中缘由,看官请瞧下文分解。

        连铸火焰切割机S5改造升级S7的项目,上位机ABB的DCS古董级AC400通过串口下辖文物级115U+CP524。上位机维持不变,PLC升级为315-dp+CP341。串口RS232C运行的3964R+RK512。

        串口通讯,咱是老手。虽然不敢自夸业精,好歹232、422、485、modbus、自定义协也练过了。CP341也是快长胡子了的老产品,资料多多。问题不大。可来的问题确实不大,但很晕。

        从客户存档资料了解到,AC400的串口通过fetch和send两条指令下发指令和获取数据。Fetch的原理和编程方法在CP341手册里说明清晰,CP341还有示例,通讯实验很顺,一蹴而就。

        接续就是Send通讯实验,照理顺利是自然的事了。可是,云彩(晕菜)来了。晕晕乎乎的… …

        手册里的最高指示,发送端要求是,


 接收端的状态要求是:


        可见红宝书清晰指明,在前进路上发送端FB P_SND_RK只需要搞定发生数据源的DB_NO和DBB_NO,接收端搞定接收目的地DB_NO和DBB_NO,就应该是数据过来,万事大吉。逻辑上和常理上,参数填写不就应该如此吗?!可是实验台上的CP341就是冷冰冰的不通不顺,致我的一脸茫然不顾。

        碰钉子了,就想办法吧。估计是我理解文档不到位,继续研读……1遍,2遍,都五遍了,测试依然不通。见鬼了!

        鬼在哪里?中文翻译不准?可能,…,找来2006,2002的文档,解释与前文2011版的完全一样。敢问路在何方?

        对了,上“Industry Online Support”在线提交问题寻求帮助。… …

        在线回复来了:“... cp341模块仅调用FB7/8即可。 如果您采用RK512的FETCH/SEND方式,您侧是被动站,仅需要调用FB7即可(FB7仅需要填写EN_R=true,LADDR填写),对方直接对本测的M或DB操作(这些具体在主站侧)。 顺祝商祺!…”。回复基本是手册的口吻,按手册上的指示做,手册要求主站侧该做的都做了呀。只是回复中“对方直接对本测的M或DB操作(这些具体在主站侧)”,好像与手册某个地方的强调说明相悖,可怎么理解?怎么做?惜字如金,不得要领。

        在没有清晰明确的理解,也就没有激发出试机实验的举动。再进“Industry Online Support”溜达,查关键字“CP341”。东东太多,晕,没新发现。转到咱们熟悉的中文下载中心,翻来翻去,找到《SIMATIC S7-300 CP 341点到点通讯、安装和参数分配点到点通讯、安装和参数分配设备手册》,主题贴近,直奔主题。查得:


        这段文字,我如获至宝,终于找到了救命仙草。同时我又有冬日被静电电击的诧异感觉和难受,怎么会有黑白不同的说法呢?先不管这些疑问,咱不是搞学问的,搞定应用要紧。上机测试,一切如《SIMATIC S7-300 CP 341点到点通讯、安装和参数分配点到点通讯、安装和参数分配设备手册》所说,通讯发出的源数据悦目地展现在我眼帘,顺利通关。

        通关测试后的轻松,首先让我感激西门子中国CS工程师的工作。是他们让我走出了漩涡和迷茫。同时,我又掉进另一个漩涡。那就是西门子的严谨,产品技术状态不应该是这样的结果。产品使用手册里强调的内容怎么会有错呢,而且是完全相反的状态?!发送端定义数据源,接收端定义目的地,这是一种常态呀,我相信很多工程师与我有这一样的直观感觉。是不是那个地方的参数或状态我还没有捋顺。到现在,我依然有这么一种心有不甘的情结。晕!希望能有人给我这晕车的解药。

        临近收笔,静思而言,虽说这种情结多少有点是对自己调试期间盲目执着的懊悔。可从产品的用户友好性而言,个人认为产品说明书里描述的状态更友好。因为通讯中发送方定义数据源地址,收取方定义接收数据的存储地址,更符合应用工程师的基于通讯原理的直观理解。FETCH通讯方式的所有参数由fetch的发起方单方面定义,从通讯的原理机制上理解是合理的。Send方式如果在让发送端包揽发和收的数据地址定义则有越俎代庖的味道。这只是一管之见,仅着眼于产品使用的友好性而言。至于根据3964R通讯机制,在send侧定义收和发双向的数据地址,是否会带来纠错性能的提高,是否能有更高的海明距离(Hamming distance)?这要做更进一步的研究才知晓,这里不敢妄言。

        题外话,没事来论坛逛逛,有事来搜搜。论坛和西门子全球资源库,真的是营养丰富。这是我学习提高的亲身感受。寻求技术支持时,如果你不是急于没火,而是着眼于积累和提高的话,建议尝试通过https://support.industry.siemens.com/cs/start?lc=en-CN在线提交,这里不仅解决你的问题,而且还记录下你不断进阶的足迹。


【征文】CP341手册里的3964R漩涡 已锁定
编辑推荐: 关闭

请填写推广理由:

本版热门话题

网友专栏

共有3227条技术帖

相关推荐

热门标签

相关帖子推荐

guzhang

恭喜,你发布的帖子

评为精华帖!

快扫描右侧二维码晒一晒吧!

再发帖或跟帖交流2条,就能晋升VIP啦!开启更多专属权限!

top
您收到0封站内信:
×
×
信息提示
很抱歉!您所访问的页面不存在,或网址发生了变化,请稍后再试。