Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Thanks anyway. I'm using LV2014 so after AQ's post above I'm not so worried anymore.

0 Kudos
Message 11 of 16
(1,169 Views)

Thanks for sharing your experience. This is really worrying me because our source code has a wide use of both accessor VIs and property nodes since it was coded by different developers with various preferences. I will experiment if a difference could be made by replacing all property nodes.

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

Certified LabVIEW Developer
0 Kudos
Message 12 of 16
(1,169 Views)

Yangyang Cheng wrote:

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.

In LabVIEW 2014, yes, there's a way to get more information. But not in 2011.

In 2014 (and later), if you get this error, LV will also include information in its log file. Go to your temp directory, located here on Windows:

     C:\Users\<username>\AppData\Local\Temp

And find files named something like this:

     LabVIEW_64_14.0_<username>_cur.txt

     LabVIEW_64_14.0_<username>_log.txt

The 64/32 is the bitness of LabVIEW, followed by the version number. The "cur" file is the most recent run of LabVEW. The "log" file is the previous run.

In that text file, you'll find text like one of the following. The hex numbers are IDs so we know which message was generated by which condition even if the error text is reformatted or new info is added in future revisions. CLN means "Call Library Node."

  • 0x0E697B77 "Caught exception in ExtCode call!"
    Meaning: the DLL threw some sort of exception.  This usually means that the DLL would have crashed (by dereferencing a NULL pointer or something like that) if LabVIEW had not caught it. With these, we either have no further information OR you will also get one of the other warnings listed below.
  • 0x50CBD7C1 "Got corruption with error <error code> calling library <DLL name> function <entry point name>"
    Meaning: this depends on the error code:
    • 1097  - the DLL threw an exception.  In this case you will get the 0x0E697B77 DWarn first, then this one.
    • 1517  - the CLN called the DLL with the wrong calling convention (stdcall vs. cdecl)
  • 0xEB1EDBEE "Call Library Function Node '<entry point name>' corrupted memory on terminal '<terminal name>'. Library Path: <path>"
    Meaning:
    after the CLN call finished, LabVIEW detected that memory near the given parameter was corrupted. Some function overwrote its allocated memory. This often means that some OTHER function is to blame, not the one that crashed.
0 Kudos
Message 13 of 16
(1,169 Views)

ian.yeager wrote:

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.

I don't use them either in my code. They don't fit a lot of situations that I want to be able to code (I leave out error terminals on the vast majority of my accessors), but I do understand why people like the syntax.

0 Kudos
Message 14 of 16
(1,169 Views)

Thanks for your contribution to this post. I just want to give everyone an update that we narrowed it down to computer OS/driver problems.

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

Certified LabVIEW Developer
0 Kudos
Message 15 of 16
(1,169 Views)

I am glad you are making progress. I hope it works out.

0 Kudos
Message 16 of 16
(1,169 Views)