Nested Endpoint Actors 4.0 and cRIO

[StevenHowell]

Good afternoon everyone.

Could someone help answer this question for me? 

I have an application where a cRIO will be connected to a Host machine for data updates and control overrides. 

Yesterday I was able to get the nested endpoint working and confirm messages are being transferred over the network to the host side.

I remember from my AOD class that with the Nested Endpoints you had to drop an instance of every message on the caller of the endpoint block diagram so that the messages would be loaded into memory.

With interfaces I was under the impression that I could drop the interface class instance on the block diagram and that would work?

Do I still have to drop every class instance of messages that the endpoint will receive and send to its caller on the callers block diagram? 

I was not able to get any messages with the interface instance, but the individual message class instances works and messages are received.

Just need some clarification if I am doing it correctly with interfaces or did I do seomthing wrong?

TIA

Steven

[justACS]

Hi Stephen,

Dropping the interface on the block diagram is not sufficient.  That would pull its *methods* into memory, but not any messages targeting those method.  The messages depend on the methods, not the other way around.

Even grouping the messages into a library with the interface and adding the library to "Always Include" doesn't do it.

You need the cube drop the individual message classes (but only the ones you expect to *receive*; the ones you send are statically liked by way of their Send methods).

This is no different, by the way, than the experience with actors.

[CaseyM]

---

@justACS wrote:

Even grouping the messages into a library with the interface and adding the library to "Always Include" doesn't do it.

---

I knew this was the case, but why is this?

[IlluminatedG]

I'd assume because by default the config is to strip unused library members. I'm curious if changing the strip library member options affects this behavior. (I'll test it, eventually, if no one else does, I'm currently behind on proving things I've seen in the community). I'm getting a few questions teed up from the viewpoint of my current employer on aspects like this.

[justACS]

---

@CaseyM wrote:

---

@justACS wrote:

Even grouping the messages into a library with the interface and adding the library to "Always Include" doesn't do it.

---

I knew this was the case, but why is this?

---

It's because the EXE file is really just a container, like the .llb file.  I seem to recall that, back in the day, the EXE was just a renamed zip file, though I may be incorrect, and it's certainly not correct now.

So when you "always include" something, it gets added to the EXE, but it's still not necessarily part of the startup VI.  That's handy for lazy loading, but it doesn't help us here.  You have to create an explicit, static link.