Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 1097 in "Get LV Class Default Value.vi"

Hi folks,

Recently I have been painfully fighting with error 1097 in my Actor Framework based application and would like to hear your opinions on this.

As a quick background, this is a Windows PC application that exchanges data with different types of hardware controllers. We used LVOOP and built each HW driver as an actor. Each driver itself was compiled into a packed library (PPL) so the main application (exe) can dynamically launch them.

Until yesterday, it was the first time I saw this error happen with a high chance (approx 70~80%) on startup (i.e. launching drivers). Knowing that 1097 is mostly related to incorrect DLL function call configuration, but this still have a small chance to work at times and it is a LabVIEW function.

Our main exe is about 20MB+ and each driver is 2~10MB+ (Block diagram removed for IP) so this is a fairly large and complex application. Below is some more information that you may consider

- We developed on LabVIEW 2011 SP1

- Actor Framework source was compiled into a PPL

- There was an AbstractDriver PPL that inherits from Actor.lvclass and defined all driver methods

- We have 3 drivers so far that inherit from AbstractDriver.lvlibp:AbstractDriver.lvclass

- We built this application on AF since May 2014 and never had this issue until recently where some UI changes were made but none should impact driver launching logic.

If you require any further information please let me know.

Thank you for your help in advance.

Tony

-------------------------------------------------------------
LabVIEW 2011 newbie >.<

Certified LabVIEW Developer
0 Kudos
Message 1 of 16
(6,591 Views)

Are you saying that the call chain says that this error came out of the Get LV Class Default Value VI?

That would be very surprising. LabVIEW code for loading files is some of our oldest code, and it is therefore mostly C code, not C++. The few places where it touches C++ code it traps exceptions and translates to error codes itself. We might have missed one somewhere, but I doubt it... it's a pretty high traffic area (dynamic loading for plug-in systems being the number one use case for LabVIEW classes).

Still, if you're sure it is coming out of that function, you should work with an Application Engineer to submit your code as a bug report so we can try to replicate and fix.

Have you upgraded drivers lately or applied any OS patches that might have made a driver behave badly?

0 Kudos
Message 2 of 16
(4,300 Views)

Yes, AristosQueue. It did come from that VI. Below is the error logged by our application before it crashed.

2015-04-22 21:18:32.34[DVCommand.PumpController]ERRORCode 1097; Source: Call Library Function Node in Abstract.lvlibp:Get LV Class Default Value.vi->Abstract.lvlibp:AbstractSlot.lvlib:getPumpSlotClass.vi->PumpController.lvlibp:PumpController.lvclass:Pre Launch Init.vi:1->Actor Framework.lvlibp:Actor.lvclass:Actor.vi:4->Actor Framework.lvlibp:Actor.lvclass:Actor.vi.ACBRProxyCaller.5D200156

What makes this very difficult to debug is that I am not able to reproduce this in my dev environment and it does not happen 100% of the time on the target computer. Like I mentioned, it's around 70~80%.

There was no driver changes recently, only UI code changes. The target computer has both LV2011SP1 and 2014 RTEs because some of our products are developed in 2014. But this application I am working on still bases on 2011.

-------------------------------------------------------------
LabVIEW 2011 newbie >.<

Certified LabVIEW Developer
0 Kudos
Message 3 of 16
(4,300 Views)

Very weird. I doubt I can be helpful without a reproduction case.

If you use your source code control and revert your UI changes, does the problem go away?

0 Kudos
Message 4 of 16
(4,300 Views)

(if the answer to the above question is "yes" then perhaps you can explcitly state what the UI changes were and maybe I can come up with some connection.)

0 Kudos
Message 5 of 16
(4,300 Views)

This was a problem I experienced often while working with a project that was written using OO and used property nodes to expose it's accessors, some of which were by reference objects themselves. Fixes ranged from deleting and replacing a specific 'Or' node to creating a brand new project from scratch and tossing the old one. After reading the post on LAVA about best practices in OO (most notably ditching property node accessors and seperating compiled code) the problems basically disappeared. There seemed to be no specific path to reproduce the error consistantly, but when it appeared, it was maddening.

0 Kudos
Message 6 of 16
(4,300 Views)

That point about property node accessors is a worry, as I use them a lot. Do you have a link to the thread on LAVA?

0 Kudos
Message 7 of 16
(4,300 Views)

ian.yeager: Did you ever submit a bug report to NI? There have been MANY fixes to property nodes since LV 2011, which is what DMurryIRL mentioned using.

Message 8 of 16
(4,300 Views)

No we did not. I won’t go into details why, but I’m glad to hear that there are fixes. I'm not anti-LVOOP nor do I think that property nodes are a bad idea, just relaying some information about a similar situation. However, since giving them up all together, I’ve never felt like I’m missing them, and I’m still using LVOOP on a daily basis.

DMurrayIRL, I can't find the specific post, it was emailed to me by a co-worker at a previous company and I no longer have access to that email and my google-fu is weak today with all my searches coming up fruitless.

0 Kudos
Message 9 of 16
(4,300 Views)

Thanks, Aristos. I was referred to seek for help here because I heard you had a lot of knowledge of the underlying OO in LabVIEW.

I am working with our QA team to run several different released builds starting from February 2015 and see if we can find some relevance. I also have difficulty replicating this issue on my workstation and our code base is very large and complicated (compiling all components can easily take 2~3 hours in LabVIEW alone). I am trying to see if I can narrow down the problematic area in the code and send those to NI, that way we have a clearer scope to focus on.

So another question for you: is there a way that I can get more meaningful information from this error 1097? If all it means is an exception was thrown from a black box DLL, it hardly helps me.

-------------------------------------------------------------
LabVIEW 2011 newbie >.<

Certified LabVIEW Developer
0 Kudos
Message 10 of 16
(4,300 Views)