atreding

This is more of an annoyance than a bug perhaps, but a lot of the old toolkits don't install correctly on newer machines anymore. I got my LV 8.2 CDs and was doing the installs this morning, and a bunch of the old toolkit installers just won't run. (Ex. the old SPC toolkit gives windows errors in Win2K because it uses a 16-bit app.) Does anyone else run any of the older toolkits, and if so what kind of workarounds did you come up with for getting them to install?

I tried to duplicate this behavior but it seemed to work for me - at least when running the output of the enum constant to an enum indicator of the same name. I agree, very strange error...

Andy

I was writing a fairly long algorithm over the last couple days with a lot of intermediate signal wires, and I got really sick of moving my wire labels every time I rearranged some code. So I had a cheezy idea that I think could work as a pitifully simple wire label. This is too rudimentary to be usable, but perhaps one of the more experienced (that is, way smarter than me) people on these boards could take the idea and make something useful of it.

All I did was make the world's simplest express vi, gave it an In and Out control that was just a pass through, and made the configuration dialog change the title. Therefore this vi just stays attached to the wire, and if you move the wire the vi stays attached.

Andy

Do you remember which dlls need to be registered with regsvr32? I wonder if this is a problem with built applications on Windows 2000 too.

The support technician gave me these two names:

opcproxy.dll

opccomn_ps.dll

I registered opcproxy.dll and the problem went away, and has stayed away in the built app. I didn't need to do anything with the other file. The file was already there in the windows directory but it was just never registered.

Andy

Never mind - the problem is solved. NI tech support was able to help me out. It turns out that on some builds of LV8 on windows 2000 there is a bug where the OPC dlls don't get properly registered during the installation. A quick call to regsvr32 from the run menu fixed the problem. The support technician said she would be filing the bug report to have the error repaired.

I assume you are looking for a way to "release" the processor during a loop to allow other processes to run - correct? If so, the standard solution recommended is to wire a wait(ms) vi with zero for its input and place it inside the loop. Each time through the loop the wait will release the processor to other tasks if there are any waiting.

My first post to the LAVA forums... Hi!

I have a project in LV 7.1 I've been working on for several weeks and the datasocket part is (was) finished. I am using DS to connect to OPC topics on a PLC. After installing LV8 on the same machine, the Datasocket open vi now throws an error. I am assuming this must be the result of the LV8 install changing some shared file, since I have not touched the Datasocket/OPC code in at least a week, nor have I changed any of the topic addresses.

I get error code -2147467262, which does not appear to be documented in LV 7.1 or LV 8 help files. The closest match is -2147467263, which is named NOT IMPLEMENTED. The error is the same whether I run the program under LV7.1 or LV8.

Has anyone else gotten far enough along in LV8 to see this yet?

Thanks, Andy

Minor update - I wrote a quick new vi using the Datasocket Select URL.vi and it lists the OPC servers (as well as all the other DS servers) but if you try to expand them to see their topics you get errors. It keeps saying interface not supported. I'm thinking perhaps that the download for LV8 either doesn't include the required drivers or doesn't register them correctly?