Actor Framework on cRIO

Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.

Re: Actor Framework on cRIO

Thanks for the link - the other thing I was thinking of was debugging them. It seems that there is yet another branch of actor code dedicated to monitored actors - any advice on how to integrate them or do something to check up on them - perhaps just log each message as it gets dequeued?

Thanks AQ,

Rik

0 Kudos
Message 21 of 36
(325 Views)

Re: Actor Framework on cRIO

If all goes as planned -- and I try to never make promises about future LV releases* -- the debugging aspects of AF will be better integrated in LV 2015.

Then you just need to splice in the couple changes for the network proxies. If you install the package, copy these three classes:

"Actor"

"Lower Proxy Actor"

"Upper Proxy Actor"

off and then uninstall (which should restore your original AF). I *think* those are the only parts you need to splice into the existing LV. Sorry -- I've never updated that package for the latest AF changes (i.e. Launch Nested Actor and Launch Root Actor). My own project time got eaten up by other things and no one got excited enough about distributed computing to keep it a priority for me.

* For those who don't know my history, LV classes were in the 8.0 beta but surprised many people by not being in the 8.0 release. We decided to hold them for 8.2. I've had several features over the years that at the last moment we decided, "nope, not ready for prime time, wait a release." As such, I'm skittish about future functionality promises.

0 Kudos
Message 22 of 36
(325 Views)

Re: Actor Framework on cRIO

I just wanted to comment on something that sent up a red flag in your previous post.

I don't likt the idea of using a cRIO and then having a PC control it. I think you want your control on the cRIO and the PC can access a view of what is going on.

Second thing is that you will need to get used to the idea of your actors having a LNA. I don't think you want your actors to inherit from LNA, but rather have them use an LNA as a nested actor.

Casey

Casey Lamers


Phoenix, LLC


casey.lamers@phoenixwi.com


CLA, LabVIEW Champion


Check Out the Software Engineering Processes, Architecture, and Design track at NIWeek. 2018 I guarantee you will learn things you can use daily! I will be presenting!

0 Kudos
Message 23 of 36
(325 Views)

Re: Actor Framework on cRIO

Thanks for the heads up. The idea was basically as follows: I'm trying to automate a power electronics test lab. I want to make an actor for each type of instrument, such as a scope, power meter, etc. Think SCPI and modbus going out of the PC serial port. But I also have control hardware, with cRIO and the electrical measurement package, and super fast super hardcoded ultra reliable protection type mechanisms thru the FPGA. It would be nice to create parameters for these cRIO controllers, and perhaps make a modbus map to control them...but then I thought that I could host an actor and use network streams to send the info instead, probably hosted in the RT part of the controller. Then I would "just" send the appropriate messages that way, which I think would provide slightly better encapsulation while maintaining an interface consistent with how I would use the other drivers.

One thing that concerns me a little is that different features seem to have been proposed in different experimental forks of the actor framework, and while this all seems like a mighty fine upgrade to the old QDSM way, I would hate to hedge my bets on some type of fork which becomes unfashionable or unsupported! Does anyone have any idea of the state of affairs at this time? I missed the NI Day near me, but it would probably be something that someone would talk about if it's still got the mainstream support of NI.

No disrespect to AQ, who seems to have invented much of it - no mean feat, and it seems like a sensible evolution from known templates to integrate OOP ideas. But I have seen many other half-baked excursions from labview into the world of OOP, including UML modelling, by ref DVR's and GOOP. It doesn't seem very easy at times to have dataflow programming and all the benefits of OOP coexist.

* Edit: Or perhaps it is the case that NI just don't seem to want to dedicate resources to developing a complete OOP platform, as many of these features seem to have been borne from single handed pioneers such as AQ taking huge amounts of initiative to drop a complete feature in their lap, all in their spare time!

0 Kudos
Message 24 of 36
(325 Views)

Re: Actor Framework on cRIO

We're actually moving away from the various forks on the community page, in favor of a "community sourced" version of AF:

National Instruments has decided to place some of its G code in a GitHub repository so that customers can collaborate on custom versions of NI libraries and so those customizations can possibly make their way back into the core NI products, including LabVIEW itself.

Actor Framework is one of three libraries currently in the Community Source project.  This is the "official" development trunk.  Our hope is that features that get added to the community source version eventuall get rolled into the version that ships with LabVIEW.

0 Kudos
Message 25 of 36
(325 Views)

Re: Actor Framework on cRIO

rik_aspinall wrote:

It doesn't seem very easy at times to have dataflow programming and all the benefits of OOP coexist.

What are the main missing benefits in LabVIEWs current OOP implementation?  I have limited programming experience outside of LabVIEW so this is an honest question.

0 Kudos
Message 26 of 36
(325 Views)

Re: Actor Framework on cRIO

That's a really great question, and I'm posting now because I know it will take a little while for me to answer it properly. (Hopefully when I do post, I will show my ignorance to all my peers such as niACS and AQ, who will then correct me and prove me wrong! I could learn so much). But until then...

0 Kudos
Message 27 of 36
(325 Views)

Re: Actor Framework on cRIO

I really don't know what to say. In some ways that is great, because we can crowdsource the design, which is surely going to be better than one person alone, and this is a really smart way of solving tough problems.

But part of me is also annoyed. I work for a very large company, and we must have hundreds if not 1K labview licenses, all at about $5k a pop. The culture is such that we value stability in our code, as well as avoid potential security conflicts by "trusting" open source code.

Further, for the amount we pay NI, it seems like they should be able to develop watertight frameworks for OOP application development on their own.  If this was visual studio express and we were crowdsourcing the linux kernel (the best free things I can think of) that would be fine, but we pay them to deliver a product to us which is much more complete and out of the box ready - we are engineers for whom time is money, and we want solutions delivered yesterday. It almost seems lazy that they do not want to allocate the PhD computer scientists (or whoever are the grand architects of their product lines), and instead leave it to paying customers. We should not forget that NI collects some kind of money from every person who writes G code, unlike almost all other languages that enjoy open source collaboration.

0 Kudos
Message 28 of 36
(325 Views)

Re: Actor Framework on cRIO

If you're paying 5k each for 1k licenses, you need to talk to your local rep. VLM gets you a much better deal than that.

0 Kudos
Message 29 of 36
(325 Views)

Re: Actor Framework on cRIO

I think we should end the discussion of license rates. Let's keep this thread about AF on cRIO please.

Thanks,

Casey

Casey Lamers


Phoenix, LLC


casey.lamers@phoenixwi.com


CLA, LabVIEW Champion


Check Out the Software Engineering Processes, Architecture, and Design track at NIWeek. 2018 I guarantee you will learn things you can use daily! I will be presenting!

0 Kudos
Message 30 of 36
(325 Views)
Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.