Dsc 8.20 bug

HI,
there is an issue with DSC 8.20 and opc client (updated or not) that is bugging me.
Make a new library with an opc client inside and deploying works.
Change the name of the computer (restart the computer) and
when I try to deploy a library with opc client
inside it , I get "Visual C++ runtime error, Labview needs to close in
an unusual way.....".
Verified with win2000 and winXP with DSC 8.20.
Another issue is that from a computer with winXP the opc client does
not connect to a any opc server from a win2000 computer besides
OPCLabview ver.6.
I followed every configurations (DCOM and else) specified by NI. From win2000 to win2000 works ok.
cosmin

Cosmin:
Thank you very much for your response, here are some suggestions/answers for your questions:
1. I created a library with an OPC server using LabVIEW DSC 8.2 and I then deployed it. After renaming and restarting my computer, I re-deployed my library and everything still worked fine. I am curious as to what you did differently to obtain that error.
2. I would suggest you to see if you can use "Server Explorer" to communicate with your OPC server on the client pc that is running Windows XP and let me know what you find.
3. Regarding not being able to install LabVIEW on a computer with Win 2000 and sp2, Page 3 of the LabVIEW Release Notes mentions that to use LabVIEW with Windows 2000, you must have service pack 3 or later installed.
I hope this helps and please let me know what I need to do to reproduce your issue.
Best Regards,
Rudi N.

Similar Messages

Dsc alarm control bug?

Hi all,
The alarm list control retains the process watch list when a VI is copied between computers. This will make the VI both load and execute very slowly when a program starts, presumably as it will try to connect or located the processes on the other computer. It seems also not possible to set the process watch list to be listening on 'localhost' processes. Clearing the processes and then closing the VI does not work properly either, as the processes from the other computer will be back in the configuration after labview is restarted.
However I found a way to clear the process list.
1. Clear the process list.
2. Set the alarm control list in 'design mode' and then back again.
3. Save the vi.
It is quite bothersome if there are several instances of the alarm control? Is there a better way to deal with this?
Am I maybe missing something obvious?
/Roger Isaksson
Solved!
Go to Solution.

The alarm control will store the process list when the control is modified and saved. It is therefore important to shut down the calling vi cleanly and calling clean up procedures before anything is saved.
This is a workaround and a proper fix is in the works I presume?
/Roger
Attachments:
UnSubscribe All Local Processes.vi ‏18 KB

[Bug?] DSC - Registering for Server Events

[LV2009, Win 7 Pro]
Howdy (Ben S another one for you? )
I am trying to register for alarm events.
This works fine by using the Register for Shared Variable Events method.
Since I have a lot of SVs and a dedicated server, I thought listen to the server would be much easier to implement.
The LabVIEW Help implies that using the Request System Event Notifications.vi will do the trick:
However, I can't seem to Register for Server Events - it doesn't work.
The code seems quite simple (below) - I just want to listen to all SVs on the localhost (default).
All the Events are coming through to the DSC (viewed in MAX), however, using the Server method I don't get any notifications through the Event Structure.
Am I doing something wrong? - Or is this a bug?
Is there somewhere I need to configure stuff?
Or does it just not send me Alarm and Notification Events of Shared Variables?
What does it send me then?
I couldn't even get the Example in NI Example Finder to work (labview\examples\lvdsc\Event Structure Support).
It shows the SV Registered Event but not the Server/System Event.
Attached is a simple project I used to demonstrate this - a SV configured for a HiHi Alarm:
The work around is to list out all Shared Variables and just read that from disk and load it into the application etc...
However, it is much more desirable to subscribe to the server and get all SV Events - is this possible?
Cheers
-JG
Certified LabVIEW Architect * LabVIEW Champion
Attachments:
DSC Server Events [LV2009].zip ‏20 KB

Ravens Fan wrote:
I think if you put in the fully qualified name for the network path and process and library on the other machine, you should be able to get the list.
You'll have to try it and find out.
Cheers for posting
From the help - I didn't think this was possible?
I gave it a go using the following naming
But I get the following error (I tried to connect to multiple SVE across our network and got the same error).
I can use though and it returns the local SV List, so I think I have the naming correct?
<edit>
My other thought is to build a hook in to the app and invoke this across the network using VI Server, so that it can run the VI on the localhost then report back the SV List).
</edit>
Certified LabVIEW Architect * LabVIEW Champion

LV 8.2 DSC Multiple Variable Editor - Import/Export bug?

Hi,
Has anyone used the export/import feature in the Multiple Variable Editor in LV DSC 8.2? I'm having problems importing a Comma Separated Variable (CSV) file and it fails to include the "Bind to Source" parameters.
You can test this by simply exporting a bound variable and then importing it into a new library. Not all the features are imported.
Is this a bug or have I simply not read the documentation or is it not meant to work like this!?
...Andy
Lead Engineer, Controls and Electrical
Irvine CA

Rudi,
Apparently this has been identified by Doug Mumford (NI) in an email to our consultant (ThinkG):
"There is a bug in the importing/exporting of CSV files using the Multiple Variable Editor. This will be addressed in the next maintence release of LabVIEW. Attached is a VI that should fix this -- make a backup of the original and replace it with the attached VI. The path to this VI is <labview>\resource\dialog\variable."
See Doug, he'll have the VI.
The bug omitted a ":" e.g. "Network Buffsize" instead of "Network:Buffsize" so that when items were imported back in the items were loaded incorrectly.
Regards...Andy
Lead Engineer, Controls and Electrical
Irvine CA

[Bug?] DSC Executable shows 'VI Loading' splash screen by default

[LV2009.SP1]
I posted this thread here regarding DSC applications showing the VI Loading splash screen on startup of an executable:
The workaround is, to add a name-value pair to the application's ini file: In your ini file, you can include the line: ShowLoadProgressDialog="False"
I would like to file a CAR on this however, my local AE said:
"[RE: CAR] I think showing the VI Loading screen by default is behaviour by design - ie, to keep the user updated as to what is happening, as I suppose many of the complile applications are not commercial in the same way that yours seem to be. However, the option to turn it off is there, for applications such as yours."
So I wanted to see what others online think about this?
And whether the general opinion is the same as mine, which is any application NOT show the VI Loading screen by default (it looks very unprofessional) DSC or otherwise.
Cheers
-JG
Certified LabVIEW Architect * LabVIEW Champion

Sounds like a bug to me.
Another thing you can try is to have your top-level VI of your executable be nothing more than a simple VI that loads the main VI or VIs using Open VI Reference. I believe VIs opened in this manner will not ever show this dialog. This workaround wouldn't rely on an ini setting.
Jarrod S.
National Instruments

[Bug?] DSC - Clusters Different between 'Read Alarm.vi' and 'Alarm and Event Query.vi" but Contain 'Same' Data

Howdy!
Why are the clusters different coming out of the Read Alarm.vi and the Alarm and Event Query.vi when they have the exact same data?
The only difference is the order of two last elements.
I am leaning towards bug on this one, unless these clusters need to be distinct for some reason?
Certified LabVIEW Architect * LabVIEW Champion

Thanks for posting Ravens Fan
I re-jiggered my API to reverse my datatypes then applied changes to my application code.
It wasn't that painful to update.
My current understanding is that this bug affects one VI, so I decided it was easier to wrap that VI with the bugfix.
Attached is my implementation if anyone wants it too.
Cheers
-JG
[LV 2009]
Certified LabVIEW Architect * LabVIEW Champion
Attachments:
Alarm & Event Query_bugfix.vi ‏30 KB
Convert Alarm And Event Query Cluster.vi ‏21 KB

DSC Saving Shared Variables to Library

I'm guessing this is a bug (LV/DSC 2009 SP1), but I wanted to see if anyone else had experienced this or had a workaround.
I'd like to make changes to the logging state of some shared variables programmatically and be able to save the changes. When I use the SharedVariablestoLib.vi function on a simple test library it works. However when I use it on my actual library I get the following (testing vi I'm using is Untitled 2):
Error Code 1
Invoke Node in PRC_SVsToLib.vi->PRC_DumpSharedVariables.vi->NI_DSC.lvlibharedVariablesToLib.vi->Untitled 2
Possible reason(s):
LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488: Command requires GPIB Controller to be Controller-In-Charge.
I think the culprit is that my library has variables organized into virtual folders. Any thoughts?
Thanks,
Kyle
CLD using LV, DSC 8.5-2009, RT 8.5
Ghoti!

I can pretty well cause the problem with virtual folders. I have attached the vi I'm using to change the logging state and save the changes as well as the two libraries I used for testing purposes.
What I did to test:
-Disabled logging on both variables in both libraries.
-Saved, undeployed, and redeployed both libraries.
-Ran my log enabling vi on each library. It ran on Test 2 (no folders) fine. On Test 3 (includes a folder) it threw the same error as above.
-At this point I tested and both libraries were logging both variables.
-Looking at the variable properties in the project, both Test 2 variables showed Enable Logging checked. Neither Test 3 variable did.
-Exited the project. Test 3 had unsaved changes so I saved it.
-Re-opened the project and examined the variables, both Test 2 variables showed Enable Logging as before. In Test3 the root variable showed Enable Logging but the variable in the folder did not.
-Undeployed and redeployed both libraries.
-Confirmed that both Test 2 variables and only the root Test 3 variable were logging.
CLD using LV, DSC 8.5-2009, RT 8.5
Ghoti!
Attachments:
Programmatic Log Change.vi ‏17 KB
Test 2 Library.lvlib ‏5 KB
Test 3 Library.lvlib ‏4 KB

I want to Create an Single Installer (My Application + DSC Run Time License )

Hi,
I want to create an single installer by including my Application and DSC RTL, So by using this i will give an single installer to my clients where they dont have any Lab VIEW components. Even though i seen some similar post, but its doesnt give me a proper solution for this. Please do the needfull.
With Regards,
Vijayakumar.V

Hi Vijay,
I think, there is no seperate RTL for DSC (for that matter, for any of other NI addons/toolkits) to be included in the installer.
You need to select the appropriate installer from the Additional Installers category while creating the installer.
Please see the attached pic.
- Partha
LabVIEW - Wires that catch bugs!
Attachments:
NI DSC 8.6 Deployment.PNG ‏43 KB

Preview Problem for DSC 2.0 files in CS4

I'm having problems getting a preview for a file created in Adbobe PSCS4. The file is a Multi-channel using spot colors. The file was created new by going from a blank RGB straight to Multi-channels and spot colors assigned to each channel with an additional 4th channel. File was saved including 8 bit preview and a single file with color composite. When placed into Illustrator CS4 I get a solid black area. When imported to Windows Illustrator CS3 the preview is soon as expected.
Also there are problems printing DSC 2.0 placed files for color separations. In windows cs3 I have to copy the DSC 2.0 to a new document in order to do color separations using PowerRIP ImageSet as the print driver. I don't do color seps on Mac with CS4 since I only have a windows license at this time for the RIP.

After further testing I've found out what the reason is for the black rending in CS4 Illustrator.
When rending DSC 2.0 within Illustrator CS4 for a preview, it doesn't calculate the opacity of each channel. I use the first channel to render my substrate color, my original file had a pure black for my substrate. Then I calculate the opacity of Inks being used on the other channels. This is a major bug for me. I have no idea what Illustrator will do if my first channel in the DCS 2.0 is something other than Black, I haven't tried yet.

Avoid MathScipt Comments in EXE, Build & Run Problems - NI Please Fix these Bugs!

Hello,
After 4 days of intensive work, I have finally found the solution for two major MathScript Problems:
1) Mathscript Comments are included in your EXE File !!
    - Yes, if you do not watch your steps, the EXE will include all your % Mathscript Comments!
2) Problems building, but even worse: An app that builds with NO Error and NO Warnings will not RUN and creates the following misleading Erro Message:
    "The VI is not Executable. The full development version of LabView is required to fix the errors"
    With absolutely NO hint to what VI have the problem.
I have made myself an internal note how to avoid this problem. I am using LabView 2009, 2010 DS1 Release (I think this is 9.01) under WInXP SP2.
Rather than retyping everything, I will post the full text of my Notes below. I also mention several other LV BUG in this note, so pleae read carefully.
One is the TagSrv Error that occurs in LabView 2009 if I programatically deploy Shared Variables under the WinXP Development Environment. After this problem has occured, it will occur every time I restart XP, and in essense I have to restore to before I did this (thanks Nortong Ghost !!!).
Below you can find the full unabridged version of my Build, Run and Bug Notes for LV 2009 / 2010 DS1 (9.01). Hope they can be helpful to my fellow LabView programmers!
2010-07-03:
Building under LabView 2009 / 2010 DS1 Release (version 9.01)
Follow the steps below:
a) To successfully build an EXE that also runs
b) Avoid that MathScript Comments are included in the EXE !!!!!!!!!!!!!!!!
Before Building:
I) Recompile All by pressing Ctrl+Shift and pressing the RUN button on the Application_References.vi
   Then Save All (about 1200 Vis are saved)
II) Make Sure that NO User Defined Mathscript (and Mathscript Nodes?) define Empty Functions:
    This seemed to cause the following problem with the built EXE: The main VI will be broken, and a dialog reports:
    "The VI is not Executable. The full development version of LabView is required to fix the errors"
    MathScitp BUG: Empty Functions causes no Build Errorm but RUN Error:
    The following User Defined MathScript .m files are candidates:
    log_write() and log_clear() whith do_log_write() and do_log_clear() commented out, these functions are empty.
    When calls to log_write() and log_clear() where removed, the problem above vanished !
Building the EXE:
1) Additional Exclusions:
-"Disconnect type definitions": YES
- "Remove unused polymorphic VI instantces": YES
- "Remove unused members of project libraries": NO (do not know if this is important)
2) Advanced:
- Enable Debugging: "NO"
3) Mathscript BUG: The Application Builder Includes ALL MathScript Comments in the EXE if you use the New Build File Layout:
   IMPORTANT !!!!!!!!!!!!!
   Advanced:
   "Use LabView 8.x file layout": YES !!!!!!!
   Using the new layout, causes ALL COMMENTS FROM USER DEFINED MATHSCRIPT .M FILES TO BE INCLUDED IN THE .EXE !!!!!!!
4) BUG: DSC Reference Problem in LabView 2010 DS1 release:
   In VI Deploy_Shared_Variables.vi we deploy alle Shared Variables using the "Deploy Libraries.vi" which is a part of the DSC option.
   As long as only deploying of Variables is used, using this VI should NOT require any DSC Runtime license.
   We have used this before with no compilation problems.
   However, starting with LV 2009 SP1 (or was it the DS1 2010 upgrade) LV will start nagging us to resolve references to tens of VIs
   in the DSC lib file ! Solution: Used press "Stop" on the dialog, and the Build will succeed and the EXE will work !
   Optionally, we could use the following Invoke node for the deployment:
   (see: http://digital.ni.com/public.nsf/allkb/04D9A85B6967EE87862571140065EEC6). Excerpt from this description:
<<Right-click the block diagram to bring up the programming palette and go to Programming»Application Control and place the
    Invoke Node on the block diagram. Using the hand tool, click Method and select Library»Deploy Library>>
5) LabView BUG: Do NOT RUn the Application under the WIn XP SP2 Development Environment if the APP Deploys Shared Vars:
   This will cause the Dreaded TagSrv Error: "TagSrv.exe: This application has requested the runtime to terminate in an unusual way".
   After this Error has occured, it will reoccur each time WinXP SP2 is restarted, and (Network) Shared Variables will NOT work any more!
Geir Ove
Attachments:
LabView_Tagsrv_Error.jpg ‏26 KB

Hello Geir,
I have tried to reproduce the behavior you are seeing where .m file comments appear in the final built executable. However, I am unable to do so using LabVIEW 2009 SP1. I have a caller VI with a MathScript node that calls the adder function in adder.m. The contents of adder.m are as follows:
% ADDER This function adds 3 to its input variable
%   y = adder(x)
%   INPUT: x
%   OUTPUT: y, equal to x + 3
function y = adder(x)
y = x + 3;
I have configured the build specification as you mention in steps (1) and (2):
Additional Exclusions
- "Disconnect type definitions" Yes
- "Remove unused polymorphic VI instances" Yes
- "Remove unused members of project libraries" No
Advanced
- "Enable Debugging" No
At first, I did not include the adder.m file in the project. I built the application and was not able to find the text "adder" anywhere in the EXE. Then, I added the .m file to the project and put it in the "Always Included" section in "Source Files." Again, I was not able to find the search text in the built EXE. In step 3, you mention
geirove wrote:
   "Use LabView 8.x file layout": YES !!!!!!!
but in the 5th post in this thread, you state
geirove wrote:
Compile using the new compile method ( Use LabView 8.x file layout": NO),
I have tried both settings in the Advanced section, but again, I am not able to find any comments in the EXE. I even added a call to the "path" function in adder.m. This puts a warning glyph on the caller MathScript node and generates different code. The EXE will return an unknown symbol error for adder (any VI with a warning glyph will not work in a built app), but I am not able to find any comments in the EXE. This project is attached below.
As for your other item with a broken EXE if you call empty functions, I am unable to reproduce this as well. I have taken the last attachment to your third post in this thread (the log_write function) and called it from the caller VI as well. The EXE runs just fine and I do not find any comments in this EXE either.
Unfortunately, there was a rather serious issue in the LabVIEW 2009 MathScript RT Module, where some internal MathScript VIs could become corrupted when building executables. Have you tried running the "Find Bad Instantiations" tool from this Knowledge Base article? Simply installing the SP1 version on top may not have corrected any VIs that may be corrupted.
Due to our difficulty in reproducing the issues you mention, could you modify the attached project or else attach a new project, appropriately configured, that builds an EXE with .m comments embedded in it? This way, we can uncover any minute details that we're overlooking.
Grant M.
Senior Software Engineer | LabVIEW MathScript | National Instruments
Attachments:
MComments.zip ‏186 KB

Use of DSC causes other applications that use SQL: to fail to run.

The use of Labview DSC seems to cause programs that use other vendor's SQL support to lock up and die. My current choice had been to run msconfig to disable loading any labview support upon startup. This allows me to use other applications such as PageManager. However oncde I run Labview I must again reboot to gain access to the other applications.
I thought all SQL and Database drivers were downwards compatible.

Hi,
maybe you should write your question to the NI LV DSC forum directly. It's
not so crowded and suits well for bug reports. I'd suggest to add this to
the discussion "What issues have you run into when upgrading to LabVIEW 7
Express?" ( http://tinyurl.com/xc1c ) even.
Sometimes I've the impression NI needs more pressure of the users for LV
DSC...
"reverse o" schrieb im Newsbeitrag
news:[email protected]..
> The use of Labview DSC seems to cause programs that use other vendor's
> SQL support to lock up and die. My current choice had been to run
> msconfig to disable loading any labview support upon startup. This
> allows me to use other applications such as PageManager. However oncde
> I run Labview I m
ust again reboot to gain access to the other
> applications.
>
> I thought all SQL and Database drivers were downwards compatible.

DSC Question

At the moment i have a deployment system whereby:
- Virtual machines are created by various means.
- A 'post installation' powershell script is executed by the answer file at the final stages of install.
- This script is used to do things like set-up IP addressing, host name, install software packages, anything we need.
I have been looking into DSC and i was wondering if it were possible to use it for these final stage 'state configurations'.
My only issues are:
- I cannot configure WinRM past the default config on these machines.
- I don't actually want to use the consistency feature of DSC, i just want to use it for one-time config. I want the config to be able to drift over time. I appreciate this is not quite the use which DSC was designed for.
Is it feasible to setup DSC in pull only mode, let it perform a state configuration and then effectively remove\disable any trace of DSC?
Cheers.

You'd be better off using a Push rather than a Pull, in the scenario you've described. You can set the LCM to ApplyOnly mode, which will apply the configuration you push, but then will not bother to re-check the system on a schedule afterwards.
As to whether using DSC this way adds any value over just using your existing scripts, that's a harder question to answer.
Possible pros: DSC resources will eventually get more use and scrutiny by the community, possibly more reliable code. Automatic logging into the event log which you can archive and/or review later to see what happened. Simpler code for
you to write; the configuration itself doesn't show all the complexity of the resources themselves.
Cons: Many DSC resources currently available have problems, and may not be ready for prime time yet. You'd have to re-implement all of your scripts as DSC configurations, possibly even having to write some custom DSC resources if the existing
set doesn't quite meet your needs yet. Basically, time investment (and possible introduction of bugs that aren't in your scripts today.)

[Bug] Writing to the same trace in Citadel from two Sources at the same time

Howdy
I am experiencing an issue and am looking to get some NI support:
I have two distributed applications that can write to a Citadel database at the same time.
And I am investigating the possibility of what would occur if both of them were writing to the same variable at the same time, with possibly the same timestamp data.
I did this in the attached VI by using the same timestamps with a constant for the data (either #1 or #2).
This generates an error, as expected, stating you cannot have two references open at the same time.
The data file, dumped from Citadel, contains 1000pts with all data from only one of the arrays (in this case #2) and everything looks fine:
However, what appears to be happening randomly tho, is that the same portion of code can also returns no error.
When the data is dumped from Citadel this file contains 2001pts - 1000pts from each array and one separator (or break) point:
You cannot write an older timestamp to Citadel without it throwing an error, but from further testing it seems you can write the same timestamp repeatably. So I am guessing what is happening above is race condition that is somehow allowing two references to be opened to Citadel which should throw an error but it does not and this is somehow allowing both sets of data to be written by both loops??
The data, IMO, is now corrupted.
Is being able to write to the same timestamp a desirable feature?
Or is this a known issue or a bug?
What about acquiring two references - bug?
Is there a workaround to protect the data from multiple distributed-application writes?
Cheers
-JG
Attached VI was coded and tested using LabVIEW 2009 SP1, DSC 9.0.1, MAX 4.6.2f1
Certified LabVIEW Architect * LabVIEW Champion
Attachments:
dual_databaseWrite.vi ‏21 KB

Ben S wrote:
The race condition of opening the refererence in two places at once should still apply to two different VIs running at the sametime.
Will a CAR be lodged for this?
Ben S wrote:
If you open up the code and save it as a .vit, you don't get any missing VIs. Only when you change the extension without the aid of LabVIEW.
No VI should have missing members by simply renaming its extension outside of LabVIEW???
I think there is an issue with the VI.
Can you replicate the following and verify what I am seeing?
Attached is a Project with Main VI (contains a call to the Open Trace.vi polymorphic only), a Class and a Build Spec
If you Build the spec with the Main VI outside of the Class it works
If you place the VI in the Class, save then Build, the Spec fails with the error:
Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:
Error 1003 occurred at AB_Application.lvclasspen_Top_Level_VIs.vi -> AB_Build.lvclass:Build.vi -> AB_Application.lvclass:Build.vi -> AB_EXE.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW: The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.
Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:
Error 1003 occurred at AB_Application.lvclass:Open_Top_Level_VIs.vi -> AB_Build.lvclass:Build.vi -> AB_Application.lvclass:Build.vi -> AB_EXE.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW: The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.
Next place a disabled structure around the Polymorphic VI (as Class Member or not, it doesn't matter)
Save the VI
Close the VI
Open the VI - the Open Trace.vi polymorphic is "missing"
Cheers
-JG
Code in LV2009
Certified LabVIEW Architect * LabVIEW Champion
Attachments:
DSC.zip ‏341 KB

Disable Error Dialogs in LV DSC Engine 6.1

I am having a frustrating experience trying to disable error dialogs on the DSC Tag Engine. My simple goal: to make sure that every time the engine is started, the "Error Dialogs" checkbox (seen in the Engine Manager) is disabled. It should be possible to edit the INI files or use the options menu to disable error dialogs, but it appears that the engine simply ignores these settings. I think it works fine on 6.0.2, but is easily reproducible on my LV 6.1 machine:
1. Run LV 6.1
2. Open the Tag Configuration Editor
3. Create a new, default, empty SCF file
4. From the Tag Configuration Editor, choose TOOLS>OPTIONS and make sure that Enable Error Dialog = False ... this should set an INI setting in lvdsc.ini. If you exit LabVIEW and open it again, LV will properly read the INI file so that this will remain False. That's good.
5. But now start the Tag Engine and double-click on the sys-tray icon to show the Engine Manager. You will notice that Show Error Dialog checkbox is checked (ON).. this means it will show error dialogs. Why is that? I have already siabled error dialogs?
6. So then... un-check the "Error Dialog" box in Engine Manager.
7. Stop and Exit the engine completely (it doesn't matter if you exit LV or not.. you get the same result). Now run the Tag Engine again and open the Engine Manager... You will notice that Error Dialog option is automatically re-enabled (ON).
Note: I am certain the ini files are NOT read-only and that Win2000 has given EVERYONE the FULL CONTROL permission to my LV6.1 folder. I am logged in as Administrator and I installed LV and DSC when logged in as Administrator.
Summary: It is impossible to permanently disable error dialogs in DSC 6.1 ... AND the INI setting "Show Error Dialogs" has absolutely no purpose since the Engine automatically re-enables error dialogs every time you load and run it. In addition, it is not possible to programmatically disable error dialogs.
Question: How can I permanently disable error dialogs on the DSC Engine? If its impossible, how can I programmatically disable it (from a VI)? These INI settings have no effect:
userErrorDialogs=FALSE --- in lvdsc.ini
enableErrorDialog=FALSE --- in DSCEngine.ini

John Paul,
National Instruments is aware of this problem and should be able to fix it for the next version. The problem is that the setting is stored in dscengine.ini but it is read from the lvdsc.ini. - what a silly bug
The only way to workaround for now would be to create a key in lvdsc.ini in the section [LVDSC] with enableErrorDialog=FALSE.
Hope this help
Roland

Importing into iPhoto 6 from Sony DSC-T1 crashes the application

Until I updated to iLife 06 I never had trouble importing photos into iPhoto from my Sony DSC-T1. Now, within seconds of clicking on the "import now" button the program crashes, and I've sent the obligitory bug report to Apple, but now the card is full and I don't know where to turn...
12 PB Mac OS X (10.4.6) iLife 06

Strange. Sorry to hear about your problems. Rather than importing via iPhoto directly from the camera, why don't you try getting the images off the card in the Finder? When you plug in the camera an icon for the memory card will appear on your desktop. Quit iPhoto if it automatically comes up. Create a folder on your desktop. Double click the memory card icon, and browse its contents until you find the image files. Drag them to the folder you created, and wait for the copy to complete. Then launch iPhoto and drag the folder of images into iPhoto.
Hopefully Apple support will be able to help you with that camera import into iPhoto. Is it on the iPhoto supported list?

Dsc 8.20 bug

Similar Messages

Maybe you are looking for