恭喜,你发布的帖子
发布于 2024-06-20 22:44:38
16楼
谢谢版主的回答。
关于我和本帖:西门子已经意识到,先前的产品研发策略还不够以用户与客户为中心,所以现在要求更进一步倾听用户声音。我是负责国内新产品趋势调研和不限于国内的新技术开发的工作人员之一。我最近通过多种渠道意识到,TIA Portal在追踪Trace和调试Debug功能上确实已经无法满足当前的用户习惯,我个人认为的不合适之处有:
1,追踪Trace的追踪数量不足,尤其是1200系列。1500系列尽管支持更多更长记录,但带来的性能降低可能会影响用户已有程序的运行。
2,追踪Trace的追踪需要提前设置,但很多用户很可能无法预计到哪些输入信号或变量会导致错误
3,追踪Trace的记录数据总量有限,某些故障缘由可能很早便出现
4,调试Debug页面停留在VB6时代,缺乏现代化调试界面和功能,比如“下一步”,“逐过程”
5,监视WatchTable需要手动拉取,应当自动展示全部变量
6,交叉引用Cross Reference自动汇总被多方引用的变量和模块,类似Visual Studio,无需手动设置
7,已有的大量产品尽管能解决部分问题,但售价过高,集成度低,不方便使用,所以准备以极低的成本做一个通用类满足基本需求的产品,或者在现有的某个产品(例如分布式输入输出模块)上改进。
8,追踪Trace和模拟以及调试Debug功能打通,方便用实际数据进行模拟并纠错。
以上内容均为初步思路,需要得到用户的认同后才能进行改进。按照总部要求,我们不能直接提出非常详细的改进建议,因为这样存在诱导用户的嫌疑,导致用户无法表达其他诉求,所以只能宽泛地询问一些问题或可能的场景询问用户意见。
1,追踪Trace的追踪数量不足,尤其是1200系列。1500系列尽管支持更多更长记录,但带来的性能降低可能会影响用户已有程序的运行。
这是必然的,会占用更多的资源,并且这些资源的动态分配并不是很方便
2,追踪Trace的追踪需要提前设置,但很多用户很可能无法预计到哪些输入信号或变量会导致错误
没错,尤其是先研发设备,一切都是未知的。
另外,研发,调试,维护三个阶段的工程师对该功能的使用需求也是不同的。
3,追踪Trace的记录数据总量有限,某些故障缘由可能很早便出现
不清楚,记录数据量有限与故障的出现早晚,这两者之间的逻辑关系
4,调试Debug页面停留在VB6时代,缺乏现代化调试界面和功能,比如“下一步”,“逐过程”
DEBUG界面,不清楚,在博途里是指工艺对象的调试界面吗?
5,监视WatchTable需要手动拉取,应当自动展示全部变量
少了还行,多了反而是噩梦,一个大项目几千个上万个变量,也这么做?智能匹配智能查询可能更好,但占用系统资源,系统反应慢,效率是否一定就高?尤其是结构化编程后有许多多层的结构变量
6,交叉引用Cross Reference自动汇总被多方引用的变量和模块,类似Visual Studio,无需手动设置
只能是对于全局变量吧?对于间接寻址,隐式访问的变量有用吗?
7,已有的大量产品尽管能解决部分问题,但售价过高,集成度低,不方便使用,所以准备以极低的成本做一个通用类满足基本需求的产品,或者在现有的某个产品(例如分布式输入输出模块)上改进。
为什么一定要做成硬件,不能是纯软件吗?
这个产品的产生,是目前的博途软件以及PLC会升级固件及性能来配合的吗?如果是,成本不会低,如果不是,功能性能堪忧,有可能
8,追踪Trace和模拟以及调试Debug功能打通,方便用实际数据进行模拟并纠错。
数据追踪可以理解,模拟是啥?仿真的代名词吗?与debug打通又是什么样的一个场景?还要纠错?谁纠错,AI软件?还是靠人的判断?这不是数字化双胞胎的场景了吗?要下沉到博途了吗?
这一打通了,成本还能低吗?
总的来说,我还是觉得最重要的是先定义出明确的应用场景
请填写推广理由:
分享
只看
楼主