完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
|
本帖最后由 sushu 于 2017-1-14 11:25 编辑
--------------------------------------主贴----------------------- sushu---LabVIEW基本介绍 --------------------------------------正贴----------------------- 这里仅仅是介绍了一种Actor Framework的使用方式。 仅作为各位了解AF的一个参考。看看是否可以得到一些灵感。 有位苏州的坛友催了好几次，额都不好意思了。仅仅做交流介绍之用。 发帖带图片感觉不方便，就直接上PDF了。不是和有条理，还请谅解。 这个项目例子还有些没有介绍，其实和这个一系列的帖子都有关系的，自己也是一种使用这个项目层次结构。 一直改进框架， 一直学习新东西。 一直在融合，取长补短每种接触到框架的思路 最终集合到现在使用的修改后的AF框架上来 额是一步步整合的，估计大家有点不理解 仅仅当作一种参考吧 毕竟自己研究的时候没多少参考 以下是PDF的部分文字内容： ------------------------------时间：2016-02-27------------------------------ 在未使用AF之前做了一个ERP系统，新建了一个顶层类ERP.lvclass. 从13年就知晓Actor Framework 断断续续研究，一直不得要领。 通过类比普通的队列状态机（或者各种二次封装形式的状态机） 有几个问题。 怎么保证各个状态一直循环往复执行？ 怎么启动？ 怎么停止？ 一个框架如果做到启动，停止，循环执行。大概基本可以拿来使用了。 15年是看到了这篇帖子： http://digital.ni.com/public.nsf/allkb/50AE3B095FB9059186257D5C001DC417 其中这段话给了灵感。因为我以前就是有一个顶层类，这样的话，顶层类继承一下AF的类，下面所有的子类都可以调用AF了。 而我可以更改这个中间的类。 故创建了一个中间的顶层类，命名为：Actor Breage.lvclass 这里面仿照JKI的队列状态机的各个Case名称创建了不同的VI（俗称类的方法） 原因：AF的一个很大的改变就是化普通状态机的Case为不同VI。这一点一定要明白。 之所以为JKI状态机的每个Case名称创建VI，是因为，我是一步步学习过来的，得到新的东西，最好的方式看看能不能在自己原先的基础上有所改进。或者相互吸取一下优点。 脑袋里已经对JKI状态机每个Case的名称了熟于心。 ------------------------------Actor Breage.lvclass 成员VI解释------------------------------ Actor Core Template.vi: 每个子AF类中的Actor Core.vi 的程序框图，复制粘贴到新建的Actor Core.vi中，这样每个Actor Core.vi都长得基本一样。 Data: Cleanup：退出之前清除一些信息，引用，串口引用，DAQ引用，其它的信息需要清除的。 Data: Initialize：变量初始化，添加一些JKI状态机里面的代码，判断是开发环境还是EXE环境。 Dynamic Launch Nested Actor.vi：每个AF调用子AF的时候，初始化时在这个VI里面添加调用子AF的代码。 例如： Handle Error.vi：收集每个AF产生的错误发送到错误处理模块。 Macro: Exit：退出时首先执行的case，放置退出之前需要执行的state的命令。 附件20M太大，就传到百度网盘了： 链接: http://pan.baidu.com/s/1dEmhPlB 密码: a7zg ------------------------------------------------------------ 包含程序代码，额外需要的代码模块。 30页的PDF文档。 
17
|
|
相关推荐
57 个讨论
|
|
|
sushu大神，我想问一下哈！！！
1.顶层类指的就是父类是吧。 2.是自己写完整个OOP，再将原来的父类继承到Actort Core，还是写父类继承到Actort Core，然后自己在写下面的各个子类方法？ 3.中间的父类是不需要自己创建的么？直接在Actor Breage.lvclass写方法?写完这个万一需要解耦，需要怎么解耦？还是说Actor Breage.lvclass就是JKI的自定义case需要自己定义然后都挂到这个父类上？ 4.AF架构的基本运行机制是OOP的队列状态机么？应该怎么理解他？ 谢谢哈，我最近比较蒙，所以问题有点傻，见解哈 |
|
|
|
|
|
|
|
|
我个人的一点浅显的认识哈，想和您探讨一下，不知道对不对。 我觉得ActorCore.vi里存在while循环的价值在于处理其前面板的事件。楼主在循环里加入了状态机，必然意味着对前面板消息的处理比较复杂，可能需要多个状态迁移才能完成。 可我认为还有一种方式也能应对这种情况，就是接收前面板事件后，这个Actor给自己发消息，在消息的具体执行函数中，处理对应事件，即使处理再复杂，也不会影响到ActorCore.vi。对于实在太复杂的处理过程，可以在具体的消息处理函数中，写一个有限次状态机，以保证代码的可维护和易读性。 总结来说，就是： 把不同事件的处理动作分别放在对应的消息处理函数中，以分类处理事件，而不是把所有的事件处理动作都挤在一个状态机或者VI（比如ActorCore.vi）中的不同switch-case分支中，从而避免ActorCore.vi的臃肿。 好像这种方式更接近Actor Framework的设计初衷。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
cestlavie007 发表于 2016-12-10 18:12 是这样的， 主要是有时候懒省事直接在JKI的那个状态机里面处理了。设计初衷是把事件处理放在对应的方法里处理的。 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
学习你的分享精神
|
|
|
|
|
|
|
|
labview1314179 发表于 2016-9-1 10:45 额，竟然现在才看到。不知道回复了还有用没。 
|
|
|
|
|
|
|
|
|
本帖最后由 sushu 于 2018-3-31 03:30 编辑
cestlavie007 发表于 2016-12-10 18:12 事件结构里使用JKI状态机，一个是，当一个用户事件的代码太多时，又不想封装子VI，可以考虑用另外的case处理，另外也可以方便处理一下选择事件，还有一个原因，可能有时候不想为一个事件创建message，懒省事，就直接jki状态机处理，其实按照官方模板就一个while循环加用户事件即可。所有的事件处理都放到消息里面。 |
|
|
|
|
|
|
|
/6 
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
26170
评论
淘帖
34758
谢谢整理这么精华的资料
