Hacti

@SciWare:

The vi that caused the conflict is used in other vi's in the project. The conflict occured because i loaded the vi with the same name from another location on the disk.

After resolving the conflict the crashes started occuring. Now the crashes occure a few minutes after loading the vi. I think that LV somehow mixed up the references or something like that.

Anyway, i recoded the entire vi from scratch, using the same vi's and everything is working fine now.

Thank you all,

Hacti

Little update,

I the attached files are the log files from the last crash.

Can anyone figure out reasons for the crashes?

Thanks,

Hacti

78bb_appcompat.txt

NI_ERRORLOG.TXT

NI_CRASH.DMP.txt

Hi Hacti

Does this happen when working on a specific project or VI, or will it occur if you start with a fresh VI and start playing with it?

Does it happen in development or run environment?

Take a look at this link from NI, it may shed some light.

Hi, sorry for the late reply.

The problem happens while working in the development environment on a specific VI. Problem started happening when I added a subVI which created an conflict. After the conflict was resolved the crashes started occuring.

Hi,

Currently working with LV 8.6 and after a few hours of work

I keep geting the following error and LabVIEW crashes.

" LabVIEW: LabVIEW.exe - Application Error : The instruction at "0x1f713922" referenced memory at "0x00000000". The memory could not be "read" "

In the attachment i put the error log file from one of the previous chrashes.

What do I need to do to stop LV from crashing?

Thanks,

Hacti

error report- LV crash.txt

Hi,

Currentlly working with the Citadel 5 Universe database with LV 8.5, we found out that upon a system crash (power failure, manual reset) database loses a part of the traces. In DSC in LV 7.1 you could configure sizes for input queues and other options, but we can't find these option for the database in LV 8.5.

The database obviously has a buffer in wihich it stores data before writing in in the database, but where can we configure the buffers settings?

I found some posts on ni.com about this but all they said was that this problem was fixed with LV 8.2, but the problem still exists.

http://forums.ni.com/ni/board/message?boar...uireLogin=False

Has someone had similar problems with Citadel and where can we configure the database settings?

Thanks,

Hacti

Hi

I just read your post so i don't know if you solved this problem or not,

If you are using datasocket on a computer that does not have labview installed or just had a run- time engine, you have to install the datasocket yourself (the installer is on the DSC cd in the Products folder).

Hope it helps...

Hi

I just read your post so i don't know if you solved this problem or not,

If you are using datasocket on a computer that does not have labview installed or just had a run- time engine, you have to install the datasocket yourself (the installer is on the DSC cd in the Products folder).

Hope it helps...

Hi,

I recently started working with shared variables in LV 8.5 (previous work was done in LV 8.2 worked fine) and have come upon the following problem:

When I create and edit shared variables programmatically and use SaveTo Library.vi, the library is created with the settings and LV doesn't report any errors.

But when I try to deploy the variables this is what happens:

1. If deploying in source code variables are deployed without reported errors but if you open them in the Variable Manager they are displayed as type Variant.

This is not a big issue because when you start writing in the values the types are correct (and all the settings too). DSC Variable Monitor displays everithing correctly.

2. If deploying in .exe program LV reports an error 1, creates the process but does not deploy the variables. This does not happen if i create and edit the variables in Project explorer of Multiple Variable Editor. When I open the .lvlib file with wordpad i got an .xml file with the shared variable properties, after comparing the two libraries i found out that the library created programmatically has few more properties that shoud not be there - boolean type has all the logging properties of other variables.

Is there a workaround for this problem or is it a bug in LV which needs to be reported to NI?

Thanks,

Hacti

P.S. Sorry for the long post

Hi,

I recently started working with shared variables in LV 8.5 (previous work was done in LV 8.2 worked fine) and have come upon the following problem:

When I create and edit shared variables programmatically and use SaveTo Library.vi, the library is created with the settings and LV doesn't report any errors.

But when I try to deploy the variables this is what happens:

1. If deploying in source code variables are deployed without reported errors but if you open them in the Variable Manager they are displayed as type Variant.

This is not a big issue because when you start writing in the values the types are correct (and all the settings too). DSC Variable Monitor displays everithing correctly.

2. If deploying in .exe program LV reports an error 1, creates the process but does not deploy the variables. This does not happen if i create and edit the variables in Project explorer of Multiple Variable Editor. When I open the .lvlib file with wordpad i got an .xml file with the shared variable properties, after comparing the two libraries i found out that the library created programmatically has few more properties that shoud not be there - boolean type has all the logging properties of other variables.

Is there a workaround for this problem or is it a bug in LV which needs to be reported to NI?

Thanks,

Hacti

P.S. Sorry for the long post

Editing is only supported in the development system. You cannot create a project nor edit a library in the run-time system. No edits are possible in a built application, only execution.

I don't think my boss will be to happy with your suggestion:)In the app you can use cfg files, so this can be one solution to our problem.Thanks

QUOTE

Every property or method has it's table in the online help which states things like "Available in Run-Time Engine and Real-Time Operating System", "Settable when the VI is running" and others. If a property is not available in the Run-time environment, there is usually a good reason (which means, it doesn't make sense to use it outside the development environment).

This means there is no way to use those properties/methods in an EXE or on an RT target.

If you really think you need one of those on your target, let us know what you want to achieve. Maybe we can find a workaround together.

I need to create a project so i can add a library with the shared variables to it. Save process/shared variables to library.vi reports an error when used in .exe file. I'm developing an app for use on the field, which requires that the properties of shared variables can be manipulated and the settings saved in a library. Trying to save a library in the .exe file also uses these nodes. Problem is that the PC in the field run only run-time and real time.

Hi,

I'm having some problems with my .exe because some property and invoke method nodes are not supported by LV realtime and dsc run-time. Is there any way to include these nodes in my application?

I tried making a .llb file to call the functions from the .exe file but that didn't work.

Thanks

QUOTE(Aristos Queue @ Sep 1 2007, 01:15 AM)

If you have a finite set of shared variables, you could create a separate subVI for each variable that sets its value and then use VI Server to select which subVI to call.

Did a similar thing but with OPC server. Works fine:)

Hacti

QUOTE(Ben @ Sep 14 2007, 02:13 PM)

Don't appologize and feel free to ramble more often. :thumbup:

Ben

I agree:)

Hacti

QUOTE(David Boyd @ Sep 13 2007, 07:30 PM)

I know their meaning, but I'm not sure it will help. The indication -1.#QNAN is a string formatted output of an IEEE-754 floating-point value of Quiet NaN (not-a-number). Broadly speaking, it's the floating-point value that IEEE-754 compliant floating point libraries (or silicon) will output when performing certain operations, like dividing zero by zero, or computing the square root of a negative number, where there is no numerical answer. The IEEE standard guarantees that NaNs are propagated through further processing, so NaN plus, times, divided by, etc anything also returns NaN. Also of note, all numeric comparisons involving NaN return FALSE, even "does NaN equal NaN?". NaN doesn't "equal" anything, though there is an "IsNaN?" test. LabVIEW, I believe, is fully compliant to the IEEE-754 standard. Whenever displayed by a numeric indicator or converted to string, the output appears as NaN. There's some encoding magic I don't understand in the standard that classifies NaNs as either "quiet" or "signalling" - I think LabVIEW only generates "quiet" NaNs.

The -1.#IND is another IEEE-754 value that represents "indeterminate", though I'm less sure about how that's generated. I believe it is the string conversion of a floating-point "denormalized" number, which I believe signals a limits-of-precision condition in a calculation. I'm not a computer science major - so you'll have to look that one up for more information. I know that LabVIEW never displays indeterminates in the way that it does NaNs, so they may just be quietly converting underflows into zero.

There are also flag values for positive and negative infinities in the standard, which LabVIEW does implement (as +Inf and -Inf). Again, the encoding you're seeing in the shared variable monitor is from some standard C library and uses the formatting -1.#xxx, so you'd see that as -1.#INF.

Where your initial values are coming from, though, I couldn't say.

Sorry for the long ramble...

Dave

Thank you very much for the clarification.

Now that I know their meaning i can hopefully find the error in our code. I think the problem lies in the initialization, we run many numerical algorithams.

Regards,

hacti

Hi,

After deploying the library and running the app I get values in the shared variable monitor for which i don't know their meaning. Some values are displayed correctly and some display the following: -1.#QNAN and -1.#IND. Tried searching the web and NI, didn't get an answer.

Also, I can't write values in the monitor for variables with above values.

Does anyone know their meaning?

Thanks a lot.

Hacti

QUOTE(Ben @ Aug 31 2007, 02:36 PM)

This does sound like a DSC app you are trying to upgrade.

To quote from Indiana Jones and the Temple of Doom "Hold on lady, we goin for a ride."

If so, "do not pass go, go directly to" datasockets. Only the most simple DSC constructs will mutate correctly. The URL's of the datasockets can be manipulated the way the old tag names could.

And if you are using alarming features, you may have to resort to reading values more than once to get the actual value.

If this is not a DSC app, disregard all of the above.

Ben

thanks, thought that might be the case.

Hacti

Hi,

My question is : Can I change the value of a shared variable programmatically (with property nodes, without hardcoding the variables) some other way then using the datasocket.

I ask this because our configuration changes from one project to another and we are trying to transfer from 7.1 to 8.2 as easily as posible, without having to rewrite our whole program.

Thanks.