恭喜,你发布的帖子
发布于 2017-10-19 00:34:32
16楼
T400属于工艺应用,我们把它简化到极致,就是一个PID算法,这个PID是有采样周期的,应该与CU的电流环-速度环-位置环的采样周期的倍数是同步的;
同理,把T400的应用编程CU320-2里的DCC功能块,其采样周期也应该是该CU的轴的电流环-速度环-位置环的采样周期的整数倍,但是现在工艺算法和轴运算分别在2个CU里,这两个CU还不能直接数据交互,必须通过第三者PLC来转发数据,通讯的滞后,PLC扫描周期的延迟,导致工艺运算无法与轴控制采样同步,并且迟滞还是不确定的,波动,这个延迟是有可能造成信号与调节量完全反向,导致系统震荡的;
如果楼主只是用一个独立的CU做一个虚拟轴来产生主指令给定,做点逻辑控制,我觉得无可厚非,没毛病,甚至钱多钱少也不是问题;但,做一个工艺算法,所谓体外循环,不同步体内循环,上面我提到的问题是需要考虑一下的,除非延迟对采样周期的大小来说可以忽略不计。
因此,上述问题不解决,而且不通过SINAMICS-LINK或OALINK来实现CU间得数据交互(也有延迟,只是延迟相对确定),那该方案就只是纯粹玩玩和噱头了,或沦为事实上的低端应用了。
Zane考虑得没错,我是这么来解决这个问题的。从性能和成本两方面考虑,T400是插在传动装置中应用的,它和传动装置采用双口RAM通讯,通讯周期是多少没有相关资料。同时T400和传动装置应该不是所谓等时同步的,因为T400的扫描周期可以自定义,传动装置的不能调整且T400推出的时间较早。
SINAMICS-LINK可以选择确定通讯周期,但DCM不支持等时同步。且DCM需要高级CUD并配置CBE20通讯板,性能较高成本也较高。
OALINK通讯周期更快,DCM需要高级CUD,且需要授权2K多。OALINK通讯的时钟在各自装置运行,没有同步措施,我测试过大约7-8分钟就会由于时钟的不同步造成短暂的通讯冲突,由于内部机制保证冲突时保持未冲突时的值,实际使用不会有影响。也不支持等时同步。
我采用的方案是profibus-DP直接数据交换,DCM基本CUD就行,数据在从站中直接交换,不需要经过PLC中转,因此通讯速度极大提高,在我的应用1.5M波特率情况下中实测通讯延时约1.5ms,会有一点波动。如果需要更快的通讯速度,可以采用CP342-5扩展一路DP用于远距离的现场IO(较低波特率),和装置的通讯采用6M波特率,通讯延时缩短到0.5ms。性价比最优。
精华帖版主置评:有干货。这不就是利用S120的从-从通讯么?嘿嘿。-yming
请填写推广理由:
分享
只看
楼主