04-10-2019 08:48 AM - edited 04-15-2019 01:03 PM
I've been thinking about my AF workflow and realised I would be a lot more efficient if I didn't have to constantly switch between the Block Diagram and Project Explorer (particularly big projects). So, I was thinking about writing some right-click menu (or QD-Shortcut) scripting tools as a side project that would allow me to spend more time on the BD/increase productivity:
*Working PoC
I would be interested to hear your thoughts on this:
04-10-2019 02:31 PM
I am going to alert Sam Taggart about this post because I know that he and Allen Smith have been working on tools to improve the AF DX (Actor Framework Developer Experience).
Regards,
Fab
04-10-2019 05:51 PM
Yes, I have done some work with Allen on the UI Actors and created a scripting tool for creating test harnesses. Unfortunately, I don't have a good solution for having to access the project so much. I agree it would be nice to not have to access it so much.
If you are able to throw whatever you are working on up on Github or GitLab, I would be happy to take a look and collaborate.
04-11-2019 12:53 AM - edited 04-11-2019 01:18 AM
Number 3 on your list can be done with this shortcut menu plugin.
Although I have noticed it becomes very slow when there are a lot of classes/libraries in the project. This can be solved by changing the criteria to determine whether or not to show the menu. The thing that actually slows it down is the property node of a VI that returns the reference to its library. I got a version that just checks if there is a Do.vi next to the VI under test. This is a lot faster and works for all my Send*.vi's.
I also omitted the check if the message class inherits from the actor framework message class for 2 reasons :
You can find my version of the plugin attached to this post. It is saved in LabVIEW2016.
Best Regards,
Stefan Lemmens
04-11-2019 03:21 AM
Thanks, Fab, Sam & Stefan,
@Sam, I've become quite au fait at IDE extension, so I can handle that side of things / if you're interested, I can point you towards the tools I use for Project providers/BD RCMs/QD-Shortcuts. I'll get some more detailed proof of concepts done in the upcoming weeks and share my GitHub repo with you.
@Stafan, Thanks for pointing this out. It wouldn't be the first time I've re-created an existing tool! - I've learnt to search/ask before making! 😉
nb: Is it possible to properly '@ Mention' someone on here?
04-11-2019 04:43 AM - edited 04-11-2019 04:44 AM
I have made some minor updates to the tool Stefan pointed out. Please see here:
https://forums.ni.com/t5/LabVIEW-Shortcut-Menu-Plug-Ins/Open-Message-Handler-llb/tac-p/3913787#M332
https://github.com/TomsLabVIEWAdventure/Open-Actor-Method-From-Message
04-11-2019 05:38 PM
Project Provider? You are way braver than I am.
04-15-2019 01:28 PM
04-15-2019 02:06 PM
Hi Tommy!
Maybe some other useful stuff. (got my inspiration from ROS)
Greetz
Natan Biesmans, CLA
04-15-2019 03:06 PM
- Being able to block the VI sending the message until you receive a response.
This would allow you to force synchronization when needed and you would also be able to implement full getters and setters.
I would take quite a bit of convincing that this is a good idea... To me, this screams mega coupling and deadlocks. I never use reply messages. When I need to have synchronous tasks happen (like in a device driver) I will use a proxy actor for buffering.
Regarding 'Getters and Setters', Actors should "share data by communicating" and not "communicate by sharing data", so I struggle to see why this would be a benefit.
Message me - Let's take this one offline as it's not really what this thread is about.
- A visualization tool for tracing messages between actors. Think execution highlighting meets class diagram.
It would be amazing to debug that one rogue message in a chain.
This is an interesting idea Hmmmm..... I'll have a think about this one. I'm not sure how it would be implemented. But a graphical representation of the message information in DETT sounds epic!