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, 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

QUOTE(Aristos Queue @ Oct 25 2007, 04:24 PM) Variables are edited in the shared variable engine after deploying the library, that works fine, problem is when i want to save the library from the engine.We will have to make some adjustments.ThanksQUOTE(Neville D @ Oct 25 2007, 07:00 PM) I'm no expert in using shared variables, but why don't you save these properties or whatever to a file instead of to a llb and then read them from file at the start of your code?If all else fails, here is a brute-force approach: buy a NI $900 debug licence that allows you to legally install the full LabVIEW development environment on the PC (in the field) and use it like that.Neville. 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 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) Did a similar thing but with OPC server. Works fine:) Hacti

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

QUOTE(David Boyd @ Sep 13 2007, 07:30 PM) 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) 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.