"Himes, Allen" <[EMAIL PROTECTED]> wrote: >"LabVIEW: An exception occurred within the external code called by >a Call Library Node. This might have corrupted LabVIEW's memory. Save >any work to a new location and restart LabVIEW. > >VI "Jitter Test with Temp.vi" was stopped at node 0x410 of subVI >"tktds7k Set Measurement Source.vi"."
Well seems like the Tektronix TDS 7000 driver has some problem here which might manifest itself only in the runtime system. Looking at the IVI C source of that driver might help you if you understand C. >I just realized that my development machine is running Windoze2k and the >target machine is running WinXP. Could that have something to do with >it? When I ran the .exe file on my development machine, it ran through >the whole test without any problems. I left it over the weekend and >when I came in, it had finished without generating this error. What >could be different between the two computers? Unlikely but with so many software (DLLs, drivers, LabVIEW executable, VISA, etc.) you never know. Try at least to make sure you install the latest VISA runtime from the NI site. >Also, sometimes, the .exe file won't even start on the target machine >because there are communication errors with my scope and other system >components. They vary between these messages: > >* tktds7k Initialize.vi<ERR>Driver Status: (Hex 0xBFFF0039) Unable to >queue the asynchronous operation because there is already an operation >in progress. >* tktds7k Initialize.vi<ERR>Driver Status: (Hex 0xBFFF0078) The value >of some parameter (which parameter is not known) is invalid. But resource closing of a previous run might be the reason for this. If the previous run aborted with an exception that is probably the reason. VISA sometimes maintains asynchronous state information over process restarts if the VISA DLL wasn't properly unloaded. >And finally, whenever the .exe application is closed, there is an error >that an instruction at location "0x7343FF3F" could not read the memory >at the same location. This particular error happens on either the >target machine or the development machine. Huu. That sounds strange but from the address is unlikely to be really in executable code but rather a mixup of a data pointer which managed to get into the execution chain. Either a stack corruption or an improperly set cleanup procedure callback pointer. Of course one of the DLLs you are using, including your USB interface may have scribbled over some address space it wasn't supposed to touch. And just because you don't have such an error when calling your DLL from another application than LabVIEW really means nothing at all. Rolf Kalbermatter CIT Engineering Nederland BV tel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijk http://www.citengineering.com Netherlands mailto:[EMAIL PROTECTED]
