device escape code 产生的原因 点击:947 | 回复:4



dongyeye

    
  • 精华:0帖
  • 求助:0帖
  • 帖子:8帖 | 7回
  • 年度积分:0
  • 历史总积分:31
  • 注册:2004年10月20日
发表于:2004-12-30 10:38:00
楼主
请问:是什么原因能够产生device escape code ? 如果是连续不断的产生这种device escape code ,又可能是什么原因? 谢谢!



zw76812

  • 精华:0帖
  • 求助:0帖
  • 帖子:9帖 | 567回
  • 年度积分:0
  • 历史总积分:654
  • 注册:2001年7月18日
发表于:2004-12-31 09:57:00
1楼
作为广播报文 code在不同的节点重复使用就会出现escape... 换个编码得了 0--62 够用了。

dongyeye

  • 精华:0帖
  • 求助:0帖
  • 帖子:8帖 | 7回
  • 年度积分:0
  • 历史总积分:31
  • 注册:2004年10月20日
发表于:2004-12-31 16:57:00
2楼
谢谢风云前辈!

dongyeye

  • 精华:0帖
  • 求助:0帖
  • 帖子:8帖 | 7回
  • 年度积分:0
  • 历史总积分:31
  • 注册:2004年10月20日
发表于:2005-01-04 09:47:00
3楼
还是不行

zw76812

  • 精华:0帖
  • 求助:0帖
  • 帖子:9帖 | 567回
  • 年度积分:0
  • 历史总积分:654
  • 注册:2001年7月18日
发表于:2005-01-06 12:12:00
4楼
Question Why are some LonWorks devices propagating "device escape codes 0x7D" to the network ? Question Detail Why are some LonWorks devices propagating "device escape code 0x7D" after power up? These escape codes can be seen in the protocol analyzer. Solution Devices which include the remote debug kernel will notify the debugger about each reset by making use of "device escape" messages. In NodeBuilder 1.5, the debug kernel is added to a device's Neuron C application by using the library #include <netdbg.h>. In NodeBuilder 3.0 and newer, the debug kernel is added automatically to the Development Target. This is a desirable thing to have for debugging, but it is also a dangerous thing to have in production devices, especially since the debugger is not available on-site. In NodeBuilder 1.5, you should make sure to remove the #include <netdbg.h> directive from your device's source code prior to generating a production build. In NodeBuilder 3.0 and newer, you should make sure to use the Release Target for your production builds. It is also possible to leave the debug kernel in and selectively disable the reset message by using #pragma debug no_reset_event. You can also turn off all event notification using #pragma debug no_event_notify. There is nothing special about these messages, they should show up as normal messages in a LonTalk Protocol Analyzer. However, the debug kernel uses a message image which resides in EEPROM and this EEPROM space is the same space as the application data so it is not checksummed. Thus, it is possible for one to modify this memory (application bug, corruption or Network Management write message) such that the message image contents get corrupted. Certain forms of corrupted messages (specifically, illegal protocol version number) are not displayed by LonTalk Protocol Analyzers. This solution applies to the following products: Control Module FT 3120/FT 3150 LonManager Protocol Analyzer 1.0 LTM-10A Network Architecture Neuron C Neuron Chips NodeBuilder 1.5 NodeBuilder 3.0 NodeBuilder 3.1 PL 3120/PL 3150 PSG-3/PSG-20 Last Modified:

热门招聘
相关主题

官方公众号

智造工程师