Blue Screen (BSOD) while communicating with GPIB Instrument

[Quaker]

I have a problem communicating with a Mensor PCS400 Pressuregenerator via NI-VISA. My really simply application sends some requests to the instrument and reads the returned responses. These actions are executed in a while loop until the stop-buttom on the frontpanel is pressed. The VISA-Ressource is initialized before the while loop and closed after leaving the loop.
Now the problem is, that the computer will run into a Blue Screen with the message "NMI: Parity Check / Memory Parity Error". This Blue Screen can be provoked by switching between the programwindow and another window (e.g. the File Explorer) - i know it sounds strange. Then the Blue Screen appears after about 20 seconds. The computer is working stable in daily work with windows.

I have tried several things already
- Waiting a while (up to 30 ms) after write and read from VISA => Blue Screen
- Communicating with the Agilent 34401A Multimeter with the same program (but other requests of course) => no crash!
- Testing the system memory during about 45h with memtest86+ => no errors found
- Stresstest with Prime95 (produces 100% CPU Load) during about 1.5h under windows => no crash

Sended Requests:
_PCS4\sREADING?\n
_PCS4\sERR?\n
_PCS4\sSTAT?\n
_PCS4\sERR?\n

The system is configured as follows:
- Windows XP Professional SP3
- LabVIEW 8.5 FDS
- NI-VISA V4.2, NI-VISA Runtime V4.2
- NI-488.2 V2.52
- PCI-GPIB Adapter with 3x Mensor PCS400 Pressuregenerator (Addresses 1..3), Agilent E3641A (Address 5) and Agilent 34401A (Address 6) connected
- PCI-6052E DAQ-Card
- Some RS232 Expansion Cards (PCI)

Do you have any ideas how to solve this strange problem?

Thank you.

[Steven_T]

Quaker,

The only way to find out which driver is causing this problem is to get a kernel memory dump.  Please follow this link for information about creating one.

http://forums.ni.com/t5/forums/replypage/board-id/140/message-id/38226

After you have a kernel memory dump, you can upload it to our ftp site and let us know the name of the file if its too big to attach to the forum.

ftp://ftp.ni.com/incoming

I hope this helps,

Steven T.

[JÞB]

http://sine.ni.com/apps/utf8/niid_web_display.model_page?p_model_id=15110

There is a LabVIEW driver available for this model.  you may wish to download it and use that for talking to the instrument.

To find out what the problem is we need to know if you are using RS-232 or GPIB for the control connection.  I can make two suggestions though.  Your outer loop has no delay, put in a wait for next ms multiple.  Secondly, wiring a 0 to wait(ms) forces the vi to release and reacquire the thread.  It seams possible that releasing the processor could allow a competing VISA request to another GPIB resource running on a second program to get in the way at which point I'm not sure how collisions get resolved 

[Quaker]

Steven T and Jeff Bohrer

Thank you for your answers.

@ Steven T
Unfortunately Windows is not creating a kernel memory or mini dump file if the BSOD happens 😞

@ Jeff Bohrer
I'am using GPIB to control the instrument. I looked to the driver already and decided to implement the needed requests with VISA functions because the driver is not using the error handling properly and it would be easier to switch to use RS232 to communicate with the instrument. I will try the same experiment with the manufacturer drivers and/or my own implemention in NI-488 too.
- About your first suggestion: I will try to put a 'Wait Until Next ms Multiple' function into the while-loop (e.g. right before the for-loop).
- About your second suggestion: The BSOD happens also if I wait 10ms with the 'Wait (ms)' function. In addition there is no other application accessing the GPIB-Bus.
I will try out these suggestions next week.


- What do you think about updating NI-VISA etc. to the latest version?
- In general, do you prefer NI-VISA or NI-488 to communicate with GPIB-Instruments? And why?


Thanks a lot for your help. I hope you understand my poorly english.

[JÞB]

---

Quaker wrote:
Steven T and Jeff Bohrer

Thank you for your answers.

@ Steven T
Unfortunately Windows is not creating a kernel memory or mini dump file if the BSOD happens 😞

@ Jeff Bohrer
I'am using GPIB to control the instrument. I looked to the driver already and decided to implement the needed requests with VISA functions because the driver is not using the error handling properly and it would be easier to switch to use RS232 to communicate with the instrument. I will try the same experiment with the manufacturer drivers and/or my own implemention in NI-488 too.
- About your first suggestion: I will try to put a 'Wait Until Next ms Multiple' function into the while-loop (e.g. right before the for-loop).
- About your second suggestion: The BSOD happens also if I wait 10ms with the 'Wait (ms)' function. In addition there is no other application accessing the GPIB-Bus.
I will try out these suggestions next week.


- What do you think about updating NI-VISA etc. to the latest version?
- In general, do you prefer NI-VISA or NI-488 to communicate with GPIB-Instruments? And why?


Thanks a lot for your help. I hope you understand my poorly english.

---

Yes update the VISA driver!!!! some of the early versions had some interesting behaviors

I like the way late versions of VISA act the need to fire off straight 488.2 commands is completely gone and using VISA allows you to run the same driver for your instrument regardless of the interface.  (Enet, GPIB, serial).  VISA is like Vitamins- just take em

[Albert.Geven]

Hi

Please don't add a wait for next ms multiple, the first wait of this function in windows is undetermined.

And even if it waits you will see that if you have enough wait for next ms multiple functions hanging around that they tend to execute at the same moment.

For delays please only use a wait ms.

The help is pretty clear about both functions but the fact that the wait for next ms multiple appears in almost all NI examples does not make it a good function. As long as it does not behave as in the realtime environment it stinks.

[JÞB]

Albert,

Yes the first wait is indeterminate in the wait for next ms multiple.  Howver it does have one advantage ove Wait(ms) that I fell you may have overlooked.  If you are waiting using the Wait(ms) when the ms timer rolls over (I32 = about every 27 days) the Wait(ms) call will never return.  It is the reason Wait fo nex ms multiple is generally preferable for loop timing

[Steven_T]

Quaker,

Wow, I completely gave you the wrong link.  This one will bring you to a KB that shows you how to configure Windows to leave a kernel dump.

http://digital.ni.com/public.nsf/allkb/581127525C80606A862570BE0003111D 

Thanks,

Steven T.

[Albert.Geven]

Did you really test this rollover behaviour, then it should be considered a bug.

I never encountered it and I really don't understand why that should happen. Even the subtract of the systemtimer works in that event correctly and we really tested that.

[Quaker]

Thank you all for your replies. I will try out your suggestions as soon as possible.

I have another question about the problem:
Now the Write and Read operations are configured in asynchronuous mode. This (https://www.ni.com/en/support/documentation/supplemental/18/choosing-between-synchronous-and-asynchr...) article describes some interesting things about threading in read/write operations. Could it be helpfull to configure them in the synchronuous mode instead?

Bye