Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 1556 in exe build run

Hello again,

I'm building an exe out of my AF project, have removed a lot of cruft and whittled it down closer to the correct implementation, but not yet quite there. 

Building with debugging flag set to true and not removing any unused instances (no checkmarks on that page), it builds and runs correctly.  The resulting exe also weighs in like SW they'd run at CERN, so I'd like to get that size down.

If I turn off debugging flag in build but still leave the 'remove unused' flags as unchecked, then it also builds and will start running, but then I get the 1556 error coming somewhere from the nether regions of the core actor framework.  I think it's coming from the priority queue, but the call chain that is kicked back in the error is insanely long and impossible for me to read.  It goes right to the popular 'resetting vi' that never recovers, after kicking the 1556 error several times.

I've gone through and removed all but a few diagram disables, and the remaining ones no longer contain any broken code.  I think I'm past the errors that occur in exe's due to unreachable code, or broken code that is unused but pops up during exe time with BD's and such removed.  This took care of 1502 errors during build and 2208 errors when trying to start the exe.  (The 2208 is a nasty one, no useful message given as to the offender, precious little info available online).

On a whim, I tried adding the AF lib itself and its attendant extra classes to the project and build, but this did not change anything I could see, doesn't seem to be a linking issue there.

I should mention here that I had similar behavior running in 'source' code mode right through LabVIEW when I was upgrading the framework from 2010 user.lib version.  I cleaned up some messages and did a mass compile and the problem went away.  I don't know if that's necessarily related to this.  But the behavior was exactly the same, several 1556 errors followed by 'resetting vi'.

Any ideas?  I don't see where there could be a race condition in startup, or rather I should say that I should be immune to any differences in the order things start up ... there's no global sharing outside of the mechanisms provided by the framework, no object does any cute little trick like feedback nodes inside a method, etc.  The boundaries between actors are pretty clear cut, no cheating.

In particular, I'd like to get a better idea of what actually causes those 1556 errors.  When they happen, all I know is that nothing is going to work even close to as expected.  It's kind of an inscrutable black box, it's either working or it completely freaks out with no way I can tell to figure out what it actually was.

I don't want to downvote my own post right off the bat, but this is not actually a showstopper, it's just an itch I want to scratch.  The big exe can be dealt with for now if need be, if I have to build in 'rookie' mode.

Thanks in advance...

Message 1 of 18
(13,709 Views)

Addendum, I wonder if this is related to a top level VI going out of memory for some reason when in exe mode, and LV starting to clean up processes that I don't want cleaned up yet.  I know that if my launcher finishes its tasks and runs to completion ('idle'), something in the launched actors becomes invalid, so I keep it open until all actors finish.  Not sure if it's the same root cause as the 1556 errors, but both seem to be references having gone bad.  It seems like there might be something quietly cleaning up stuff behind me, before I'm done using it.

0 Kudos
Message 2 of 18
(5,674 Views)

Ben... I missed this post yesterday...

That reference-is-bad error definitely seems like something shutting down sooner than expected. Your top-level launcher VI should be able to call Launch Actor.vi and then exit as long as your actor doesn't send any messages to the caller... the only messages sent to the caller by the framework (Stop and Last Ack) both ignore any error from the send because they were written to assume the caller could exit early.

Can you post the insanely long call chain from the error? I might be able to make sense of the lower down parts of it enough to identify what the problem is.

0 Kudos
Message 3 of 18
(5,674 Views)

You aren't late, I only wrote this this morning.  We're pretty good now, I just can't get it to build in anything less than full behemoth mode.

But be careful what you wish for   Here's the error chain, undecorated.

Error 1556 occurred at ??? in Actor Framework.lvlib:Message Priority Queue.lvclass:Priority Enqueue.vi:2->Source Manager AF.lvlib:Source Manager Actor.lvlib:Source Manager Actor.lvclass:Set and Launch Data Publisher Actor.vi->Source Manager AF.lvlib:Source Manager Actor.lvlib:Launch Data Publisher.lvclass:Do.vi:1->Actor Framework.lvlib:Actor.lvclass:Actor Core.vi:1->Source Manager AF.lvlib:Source Manager Actor.lvlib:Source Manager Actor.lvclass:Actor Core.vi:1->Source Manager AF.lvlib:Source Manager Debug UI Actor.lvlib:Source Manager Debug UI.lvclass:Actor Core.vi:1->Actor Framework.lvlib:Actor.lvclass:Actor.vi:3->Actor Framework.lvlib:Actor.lvclass:Actor.vi.ACBRProxyCaller.6A100018

0 Kudos
Message 4 of 18
(5,674 Views)

Ben_Phillips wrote:

Error 1556 occurred at ??? in

Actor Framework.lvlib:Message Priority Queue.lvclass:Priority Enqueue.vi:2->

Source Manager AF.lvlib:Source Manager Actor.lvlib:Source Manager Actor.lvclass:Set and Launch Data Publisher Actor.vi->

Source Manager AF.lvlib:Source Manager Actor.lvlib:Launch Data Publisher.lvclass:Do.vi:1->

Actor Framework.lvlib:Actor.lvclass:Actor Core.vi:1->

Source Manager AF.lvlib:Source Manager Actor.lvlib:Source Manager Actor.lvclass:Actor Core.vi:1->

Source Manager AF.lvlib:Source Manager Debug UI Actor.lvlib:Source Manager Debug UI.lvclass:Actor Core.vi:1->

Actor Framework.lvlib:Actor.lvclass:Actor.vi:3->

Actor Framework.lvlib:Actor.lvclass:Actor.vi.ACBRProxyCaller.6A100018

Bah. That's short! The LV C++ code has special handling for reporting a "long call chain", which is defined as 30+ levels. 🙂

The inlined VIs are missing, which is why the call stack isn't as meaningful as it might otherwise be (wonderful debate here in R&D about whether inlined VIs should be somehow included in the call chain results... it's a pretty major performance hit to do that, even in a debug build, but I still think it would be worth it to help debug these issues, at least in a debug build). But the long and short of it is that this is the interesting VI:

Source Manager AF.lvlib:Source Manager Actor.lvlib:Source Manager Actor.lvclass:Set and Launch Data Publisher Actor.vi

Can you publish its block diagram? Somewhere on that diagram, it is doing a Send Message of some sort. Where does it get the message queue that it is sending to? It can't be a send to self, because we know that the self queue is still valid here (because we're handling a Do.vi right now). Is it a send to caller? Or is it a send to another actor that somehow shared its queue with this one?

Long and short of it, we're looking for an actor that is independent of this one that sometimes quits before this one can send it a message, and in a debug build the timing works out that the other actor stays around, but in a release build it is just fast enough to disappear first.

0 Kudos
Message 5 of 18
(5,674 Views)

Yeah, maybe I should change our error handler for the AF project to split the lines like you did, definitely makes it less offensive to the eyes.  Stringing it horizontally like the oregon trail only works for short errors.

So I figured out that some of the panels for actors were being removed, and set them to not be removed in the build, and things seem to be working correctly now.  The clue was that the actors that were properly appearing were the ones that had dedicated GUI's, which were the ones that contained references to themselves on their BD's.  --> aha!

And I think this might explain your theory above that the actor being launched has quit by the time the VI named above has executed, so the queue has become invalid.  And it also explains why it worked with 'debug' flag checked in the build, as it won't remove any FP's.

I'm a little confused about why a missing front panel would cause the actor to fail instead of just running headless, but I won't lose any sleep over that if it remains a mystery.  Looking at the asynchronous call inside Launch Actor VI, it looks like any error trying to open the front panel of an actor will cause downstream queue black-magic to fail.  Is this expected/planned?

0 Kudos
Message 6 of 18
(5,674 Views)

So this is not an Actor framework thing. It's a general rule for creating executables that contain parallel processes. I think this should automagically be handled by the Actor framework somehow, since it seems to be stumping a few here.

0 Kudos
Message 7 of 18
(5,674 Views)

Not sure how those actors are instantiated but if it is in any way like a top level hierarchy (like the Run() method) then that will only work if the VI has a frontpanel. Otherwise the Run() will fail with an error. That or that some other property/method gets invoked during instantiation that requires the front panel to be present.

Rolf Kalbermatter
My Blog
0 Kudos
Message 8 of 18
(5,674 Views)

Michael_Aivaliotis wrote:

So this is not an Actor framework thing. It's a general rule for creating executables that contain parallel processes. I think this should automagically be handled by the Actor framework somehow, since it seems to be stumping a few here.

I think there has to be something more subtle at work here. Why? Because Actor Core.vi is not invoked as a top-level process. The actual VI that is the top of the process is Actor.vi, and then Actor Core.vi is called as a subVI. SubVIs do not require their front panels to run (I agree that top-level VIs shouldn't have to have their panels either, but that's a historical thing predating my time on LabVIEW). Indeed, Ben did not mark "retain panels" on all of his VIs, which means that the subVIs of Actor Core.vi are working just fine. So what is different about the various Actor Core.vi overrides that makes the panel required?

0 Kudos
Message 9 of 18
(5,674 Views)

Ben_Phillips wrote:

Looking at the asynchronous call inside Launch Actor VI, it looks like any error trying to open the front panel of an actor will cause downstream queue black-magic to fail.  Is this expected/planned?

Can you post a picture of exactly which function is returning the error? I may be able to improve the error handling, depending upon where it occurred.

0 Kudos
Message 10 of 18
(5,674 Views)