How can I release the parallel port to allow another application to use it?

[Robb@Switch]

Currently I am using a PE Micro debugger to access a 68332 IC on a PCB. The debugger uses the parallel port to communicate to the PCB. I then need to allow another program, a stand alone command-line .exe to access and program FLASH via the debugger. This command-line programmer works in windows 98 but does not for windows XP. It seems that Labview does not "release" the port after I access it once in Labview. I have to close down LabView to allow the command-line programmer to work. But I want to call the command-line programmer through LabVIEW.

[Cyril]

Hi,

How is the parrallel port accessed in the first place? through VISA? If so make sure you use the VISA Close.vi when you're done communicating...

Hope that helps,

[Robb@Switch]

To communicate through the debugger, I access a .dll using a "Call to Library function Node". After that is when LabVIEW holds the parallel port so the command-line programmer .exe cannot access the port.

[Cyril]

Ok,

LabVIEW loads a DLL invoked in a Call Library Function when the VI that contains the Call Library Function is loaded into memory. Likewise, LabVIEW unloads the DLL when the VI that calls it is unloaded from memory (i.e., the VI is closed). So Basically what happens here is that the dll is not unloaded from labview memory and still holding the parallel port resource.
-Is there a function to close the comm in the dll that may prevent it to release the resource?
- Try encapsulating the Call Library Function node into a subvi so that dll is "theoretically" unloaded when this is done executing

Good luck,

[Philip_Courtois]

You might also try to use the "Request Deallocation" function in your VI. This will deallocate the memory handled by LabVIEW after the execution of the VI is ended. The handle to the port should be cleared this way.

Good luck!

[Robb@Switch]

I have tried all of these and none of them worked. I actually have to close down LabVIEW and then I can run the .exe that uses the parallel port (debugger). I have tried many was to close, clear, flush, the parallel port and nothing seems to work except for exiting LabVIEW. There is nothing in the dll that allows me to close the port, but this was never a problem in Windows 98. I will continue other solutions. All ideas are welcome.

[Philip_Courtois]

Sounds like LabVIEW is having a firm grip on that DLL. Have you tried putting the Call Library Function Node inside a VI that you then call dynamically from the main VI? Remember to close the called VI programmatically when done.

[jaapr]

Hi,
Same problem with LabView refusing to release a dll using File-Close in LabView.

We are sure the dll itself is properly closed. But closing the main vi (File-Close) which uses the subvi's holding the call library function vi's, and then re-opening the main vi causes a labview.exe application error: memory could not be read. When closing down LabView completely (Exit), the main vi runs without a problem again.

Calling the same dll from Visual C++, Visual Basic, Delphi and Borland C++ does not give any problem at all.

"Have you tried putting the Call Library Function Node inside a VI that you then call dynamically from the main VI?"
Yes, we created for each function used in the main vi a subvi with all the connections properly set. In the main vi, we use these subvi's. Is the word "dynamically" important in your suggestion above?
"Remember to close the called VI programmatically when done"
The last function in the main vi calls the subvi for the function that releases the dll. Should we explicitly (programmatically?) close each subvi used by the main vi? If yes, How?
Thanks in advance for your help,
Best regards, Jaap

[Robb@Switch]

THis problem was resolved. The maker of the Dll recomiled the software with newer drivers and all started to work.