gpib write or read sometimes hogs cpu

[Mathan]

Another thread in Instrument control board discussing the same issue. Just see here for reference.

[Mr.F]

Interesting, this might not show us exactly what we need to see but I would be curious to look at a SPY capture for both cases. Can you post a capture for the working and non working case? Can you also post your new (VISA) code?

[rmshelby]

Hi Matt,

The contents of the attached zip file:

 Archive:  sr640filter.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
        0  12-08-09 16:51   filter_gpib/
    37238  12-08-09 16:46   filter_gpib/Capture_working.spy
    25140  12-08-09 16:35   filter_gpib/test_sr640.vi
    49112  12-07-09 15:04   filter_gpib/srs_filter_setparms_v.vi
    14398  12-08-09 16:44   filter_gpib/Capture_broken.spy
    10304  12-04-09 17:13   filter_gpib/srs640_visa_init.vi
    11244  12-04-09 17:13   filter_gpib/srs640_visa_close.vi
 --------                   -------
   147436                   7 files

srs_filter_setparms.vi is the rewritten vi with VISA, test_sr640.vi is an simple vi to open the VISA session, interact with the sr640, then close.  The .spy files were obtained while running test_sr640.vi.  Capture_working.spy shows a series of button pushes without my complex vi loaded. Then the complex vi was opened but not run.  test_sr640.vi was run again.  The second time I changed a control, the vi hung for several seconds while pegging the cpu.  In the trace you can see the delay at lines 40-41.  Other than the delay, I don't see much in the trace that's revealing.

Thanks,

Bob 

[Justin_E]

Hey Bob,

Am I correct in saying that the VIs you attached and all the VIs in this forum thread are for the subVI itself? Could you post the overall complex VI? LabVIEW is constantly monitoring/compiling your code when you develop (hence why you get broken wires if you wire something improperly). If something in your complex code is giving LabVIEW troubles, then LabVIEW could be devoting resources to compile that complex VI, taking away from the VI you're running. It's a very outside chance, but I think it'd be worth taking a look at. Does the hang always occur at the exact same place?

Also, when you do see this hang, do you know which application in the task manager is causing the hang? If it's labview.exe, then clearly LabVIEW is doing something strange here, but there are a number of other NI tasks that run in the background.

Regards,

Message Edited by Justin_E on 12-09-2009 04:43 PM

[rmshelby]

Okay, here's the entire project.  The main vi is called joystick_digitalgalvo_etc....etc.vi.  There's a lot going on at once here, but keep in mind that this was all working wonderfully well until I added the srs640 contol vi's.  It still all works except when I push one of the buttons that causes a call to srs_filter_setparms.vi. 

To answer your other questions, it's hard to see which process is grabbing the cpu because Windows Task Manager stops updating during the hang.  When it comes back to life, on the first update of the process list, a few times I've seen LabView.exe at the top with 99% cpu.  

The hang can occur at any of the VISA reads or writes, seemingly randomly and unrelated to which control on the front panel I had selected to change.

Bob

[RavensFan]

Any chance you have a virus scanner running?  If so, can you try disabling it?

I have a LV application that was running continuously perfectly in the development environment for days on end.  The program had been in use for over a year without ever seeing a problem.  Then one day I noticed the front panel would slow down and pause for a few seconds here and there.  So would the task manager display, but it showed 99% usage on LV whenever it popped back to life.  But I was lucky enough to notice it right after our IT department in all of their infinite wisdom decided our old virus scanner was no good and needed to be converted to a new virus scanner.  The corporate wide update was pushed down on us without our control.

I put two and two together and figured it was related to the virus scanner.  But why?  I found that if I disabled one very small part of my LabVIEW program where a dll was called to interface with an external device, there was no slow down.  All I can figure was that the frequent call by LabVIEW to the dll (about once per second) was causing the virus scanner to go crazy constantly scanning that interface.   Task manager was kind of lying to me because it attributed all the CPU activity to LabVIEW (since it was LV making the dll call) rather than to the virus scanner.  (Though I did see some minor blips on the scanner processes that got me looking that way.)

Once I figured out how to disable the virus scanner and kill some of the background services that would automatically restart it.  I haven't had a problem since.

Your symptoms sound like mine, so maybe the GPIB calls are somehow causing your virus scanner to peg your CPU like my dll call was doing to me.

[rmshelby]

This was a really good thought, but did not fix the problem.  After disabling all the Symantec Antivirus services, rebooting, making sure no SAV stuff was running in task manager, I still have the hangs.

Bob

[Mr.F]

Hi Bob,

Can you try recreating the subvi and see if this behavior persists? I’d like to see if these Vis are linked in any way or if the subvi itself is causing the problem.

[rmshelby]

Maybe you could be more detailed about what you want?  What I think you mean is to make a copy of the subvi that is not called by the big vi and see if the copy behaves any differently.  Is this correct?  Or if not what do you mean by "recreating the subvi"?

Thanks,

Bob

[Mr.F]

Hi Bob,

Sorry if I was unclear. What I meant was to create a new VI that performs the same functionality as the previous set filter parameters subvi and test this VI. This would tell us if perhaps there is still some linking between the main vi and the subvi (perhaps due to being previously linked in the same library) which is causing the compiler to misbehave. You could then test this new VI is the same way that you have previously tested the set filter parameters subvi and see how you performance is affected.