Jim Kring

Has anyone had success with the

preloadSimScriptingVIs

DebugSimScripting

INI Settings :question:

It's probably something to do w/ something else, but you never know.

Norm: Long time no chat. Been working too hard ;-) I suppose that these keys have to do with the Simulation Toolkit features, which use a VI facade, similar to Express VIs (I think).

The Multiple Document Interface (MDI) is not available in LabVIEW 8.0, but might still make it into a future release.

Hello Forum,

we're using a OPC DA 2 compliant OPC Server that works fine when connected from Nationals OPC Server Explorer. If I try to setup a connection from within LabView there is an error message saying that : IOPCBrowseServerAddressSpace interface is not implemented. Is this something we have to accept or is there a workaround / patch ....

Thomas

Try this suggestion from NI Dev Zone:

LabVIEW 7.1 implements some new security features dealing with DCOM that were not in 7.0. Windows is moving in this direction, and National Instruments decided to follow suit. 7.1 requires a certain level of authentication from the server. If this is the issue in your case, it can be resolved with the following steps (this is for Windows XP; CE will probably be different):

1. On the computer hosting your OPC server select "Start >> Settings >> Control Panel >> Administrative Tools >> Component Services.

2. On the tree on the left, expand "Component Services >> Computers >> My Computer >> DCOM Config.

3. Your OPC server should be registered as one of these items. Right-click on your server and select "Properties."

4. On the "General" tab, change the "Authentication Level" to "Connect."

If this property is already set to Connect or Default (and the default setting is Connect) then this will have no effect.

You can also try checking some of the other settings:

1. On the computer hosting your OPC server select "Start >> Settings >> Control Panel >> Administrative Tools >> Component Services.

2. On the tree on the left, expand "Component Services >> Computers >> My Computer

3. Right-click on My Computer and select "Properties."

4. On the "Default Properties" tab, make sure "Default Impersonation Level" is set to "Identify."

You may also want to look at the "COM Security" tab to make sure your computer has the right permissions.

If all else fails, you can try adding the line "ole.AuthnLevel = 1" to the LabVIEW.ini file. This should reverse some of the changes to 7.1.

Is there a way to directly get the Type String from a Variant without relying on 'Variant to Flattened String'?

Arlan: How about emptying the data from the cluster before getting the type descriptor. Here is a trick that you can use to get the default data of anything:

Structures (For Loops, While Loops, etc) will auto grow when you resize another structure that is inside it. This happens for all the structures except the Flat Sequence. Drop a For Loop on the diagram and then put a Flat Sequence in it. Grab the bottom edge of the sequence and resize it so it extends out of the For Loop. The For Loop won't grow! But it will grow if you use any of the other structures instead of the Flat Sequence. The thing is that I tried this in LABVIEW 7.1 and the loop did grow! So is this a bug in 8?

Yep, it's a bug.

Jim....

I like your solution. It will only work if you're calling one DLL at a time though right? I don't think it was a requirement to call more than one at the same time but I was just thinking things through.

Correct, you can only call one DLL at a time this way. Rolf's suggestion (to write the linker info to the VI and change the called DLL) was also on my mind but this method requires 1) That you be in the development environment, 2) have access to scripting, and 3) understand what linker info is. So, I avoided that solution.

Actually, maybe there is another way to do it. I think that the link to the DLL path is stored in clear text, within the VI (binary) file. If you used a fixed width path like "My_Dynamic_DLL_NNN.dll" you could do a character replacement of the VI's binary information -- for example "My_Dynamic_DLL_001.dll", "My_Dynamic_DLL_002.dll", etc. This could allow you to open multiple instances of the DLL.

Take a look at the LabVIEW Data Tools (lvdata) package of the OpenG Toolkit. That's exactly what this tool does.

Here is a way that should work, although I have not tried it:

Create a VI named something like "DLL_Wrapper.vi" with a Call Library Function that calls the DLL. However, create a copy of one of the DLLs and name it something like "Dynamic_DLL.dll" and have DLL_Wrapper.vi call Dynamic_DLL.dll. At run-time, copy and rename the specific DLL you wish call as Dynamic_DLL.dll and place it in the same directory as DLL_Wrapper.vi (or the location where DLL_Wrapper.vi expects to find it). Then, open a reference to DLL_Wrapper.vi which will load it and Dynamic_DLL.dll into memory. Use Call By Reference to call DLL_Wrapper.vi and thus Dynamic_DLL.dll. Then close the reference to DLL_Wrapper.vi, which will unload DLL_Wrapper.vi and Dynamic.dll from memory. Repeat, as needed.

Still curious to hear how others are faring with the transition...

I'm taking it slow. So far, I have only converted one project to LabVIEW 8. However, I use OpenG Builder to build this application, and it uses a custom installer also written in LabVIEW.

I am trying to programmatically generate a list of information about all NI hardware installed on a machine. I want to be able to read the model and serial number of these devices so that this info can be sent to a corporate database. I am dissapointed by the fact that the list of devices returned by the DAQmx System::Devices Names property is not complete.

When I go to MAX, I see a list of about 7 DAQmx devices, but the DAQmx System::Devices Names property shows only two. Why would this be?

I did find a set of VIs under the NI-SCOPE palette called NI-ModInst that looks interesting.

It looks like this set of VIs can programmatically obtain device info for NI-SCOPE, NI-FGEN, NI-DMM, NI-HSDIO, NI-SWITCH, and NI-RFSG instruments.

This did find two of my high-speed digitizers as NI-SCOPE devices, but it failed to find my Arbitrary Waveform Generator (ARB) board as an NI-FGEN device and my digital multimeter (DMM) board as an NI-DMM device.

Any thoughts?

:headbang:

I am converting from Apple based systems to Windows. What is the Windows equivalent of the Apple Event vis? Specifically, I need to replace AESend Finder Open.

Finder, is sort of the Mac equivalent of Windows File Explorer. You can launch the Windows File Explorer from the command-line (System Exec), by issuing the "explorer" command.

Is there any way to convert those 6.1 vi's to 6.0 vis without the 6.1 version LABVIEW.

Each LabVIEW version has the capability to down-convert to the previous version of LabVIEW. So, you will need 6.1, in order to convert to 6.0.

Hmmm, I just ran MAX and got this message:

I went into the NI License Manager and noticed that the Vision 7.1 components (Vision Assistant, and Vision) were no longer activated. I did a right-click > activate, and it activated instantly. However, I am still annoyed -- that's 10 minutes of my life that I will never get back.

How do you see that? goop that is talking to the beans, or beans who are talking to your labview program???

And why not corba or webservices?

You can define an IDL, and implements it with goop or something like that. Than you can call the methods from Java via the ORB (Object Request Broker)...

There are so many java components, which are cross-platform by nature. If LabVIEW could embed/use these, then it would open up a lot of options.

What does that mean? I understand PJM's post you quoted--these questions I don't.

I still say that if you can't access the classes exposed using this tool, then it is still partly irrelevant (it's good to know the class tree, but you can't do anything with it, so it's "worthless").

There's an old saying... "You can lead a horse to water, but you can't make him drink"

Thanks! i did it.. like this n the command line of system Exec

NET USE \\COMPUTERNAME /USER:DOMAINNAME\USERNAME

then iterated the system exec with the Password input text

to its commandline

Great :thumbup:

Help needed pls..

how do we access network passwords with labview??

because when a network server has a password requiremnt, like these,

i cant use the FILE vi's like the LIST,NEW etc..

what do i need to do to pre-program the network access?

thanks!

You can use the NET USE command, using System Exec to execute the command line.

C:\WINDOWS\system32>net use /?

The syntax of this command is:

NET USE

[devicename | *][\\computername\sharename[\volume] [password | *]]

[/uSER:[domainname\]username]

[/uSER:[dotted domain name\]username]

[/uSER:[username@dotted domain name]

[/sMARTCARD]

[/sAVECRED]

[[/DELETE] | [/PERSISTENT:{YES | NO}]]

NET USE {devicename | *} [password | *] /HOME

NET USE [/PERSISTENT:{YES | NO}]

Kennon, thanks for this post. This is just what we need. Also, I have a quick question: How can we create a new application instance, similar to what the Application Builder now does?

Are there any means in unlocking the password in show diagram, in case u forgot ur password?

Take a look at this. It is your only hope.

A very "quick and dirty" trick I've played on Windows based machines is to give a tab delimited text file an .xls extension. This causes Windows to automatically open the text file through excel when the user double clicks on the file.

Also, you can also have Windows open the file in Excel by calling it from the command-line using System Exec. Just pass the path to the file, as the command string and let Windows do the rest. This method will also work if your have OpenOffice registered as the handler for XLS files.

I have posted info on how to do this here:

There are a couple ways to get all of the OpenG packages.

1) You can download them individually. Most of them are located here: http://sourceforge.net/projects/opengtoolkit

2) You can download them all using Commander on a machine that has internet access and then transfer them to the computer that does not have internet access. Commander keeps all of it's packages in a "cache" folder. You can see the location of the cache by navigating to Tools (menu) >> Options (menu) >> Advanced (button) >> Cache (tab).

How can I access the App.AllVIs property of the user's (main) application instance (and perhaps project application instances) from within the NI.LV.Dialog application instance? We are having issues with OpenG Builder in LabVIEW 8.0 that are affected by the fact that the App.AllVIs property only returns the list of VIs within the application instance of the calling VI.

Let's imagine that OpenG has a function called "Trim Whitespace.vi" and NI thinks that it is so great, that they rip-off also create a function called "Trim Whitespace.vi" and ship it as part of LabVIEW, in vi.lib. Now, any time that someone opens a project that uses the OpenG version of "Trim Whitespace.vi" it could potentially relink to the NI version. This is a very bad scenario, in more ways than one. We can fix this problem by name-mangling all of our VIs prior to shipping them. Then there is no possibility that the VIs will accidentally relink to other VIs of the same name. This is actually a common practice and people have been doing it for a very long time -- commonly adding a prefix, such as "COMPONENTNAME FunctionName.vi".

I compiled a list of the different things you should check [...] the list is attached to the post as a document with screenshots of everything you can look into

This would make a great addition to the LabVIEW FAQ.

There are several things that the LV App Builder uses to determine whether or not the FP needs to be preserved. For example, if it has the Open Front Panel When Called attribute set to TRUE, implicit control property or invoke nodes on the BD, or control reference constants on the BD.