XP embedded using PC/104-GPIB causes program crash

[jb1805]

I am trying to create an instrument using the following hardware and software:

Advantech PCM-9377 SBC (512 MB RAM)

NI PC/104 GPIB card (0x2C0, IRQ7, DMA6)

Microsoft Visual C++ 6.0

Measurement Studio Component Works++, Version 1.0.1

I have developed the SCPI language to control the instrument and the code works fine using RS-232. We have a requirement to use IEEE-488 and this is where we are encountering problems. The program does not crash while running in the debugger. I have Bounds Checker and have run the debugger with this tool enabled and it does not find any memory overrun or other problems. To test the interface, I am using MAX on my computer with a USB-B controller connected to the back of our instrument. I can send commands and queries and they are received and answered but then the program crashes after an indeterminate amount of time. Sometimes it can be right after the first query or command and other times it could take a few minutes. As another test, I tried querying *IDN? and then just waited. After approximately 2 minutes, the program crashed with the following message:

The instruction at 0x00497edd refereneced memory at 0x000014. Memory could not be read.

When I trace this address into the map file, it points to CNI4882EventProxy::Release. This appears to be private NI code.

In the program I have the device defined as CNi4882Board.

The functions related to the board are:

bool CMainFrame::OpenGPIB()

int GPIBEventHandler( CNi4882& object, void* userData )

LRESULT CMainFrame::OnGPIBEvent( WPARAM wParam, LPARAM lParam )

int CMainFrame::GPIBSetWriteBuffer( void *wrtbuf, size_t count )

void CMainFrame::OnGPIBSetup(void)

int CMainFrame::InstallGPIBHandler(int iMask)

I have try / catch code inside the functions but no exceptions are triggered.

I would appreciate any help, thoughts or insight you might provide. 

Thanks very much,

Jack

===================

The GPIB code is in an attached file

===================

[Josh_L1]

Hi jb1805,

How did you modify your code to use IEEE-488 protocols? It looks like you are having a time out somewhere. If you are using VISA functions in your code, please make sure that all the references are properly closed. Below are some general serial communication articles you might find useful.

http://zone.ni.com/devzone/cda/tut/p/id/2895

http://digital.ni.com/public.nsf/allkb/E22DA85E97818DE78625678C0069BFC9?OpenDocument

http://zone.ni.com/devzone/cda/tut/p/id/2897

Regards,

Josh L.

[jb1805]

Hi Josh,

Thanks for the reply! I am not directly using the IEEE-488 protocols. My device is defined as a CNi4882Board. I am using the standard methods available for that class. When the program crashes, I lookup the reported address in the map file and that is what points to the EventProxy routines.

Yesterday, it actually crashed in the debugger I had installed in the instrument and I was able to look at the stack trace. Maybe this will shed some more light. (I don't have the full line on the first 2 since I only took a screen capture)

First chance exception: 0xC0000005: Access violation

std::_Tree<class NI::CNi4882*, class NI::CNi4882*, struct s...

std::set<class NI::CNi4882*, structstd::less<class NI::CNi...

NI::CNi4882EventProxy::Release(class NI::CNi4882*) + 237 bytes

NI::CNi4882ReleaseEventProxy(void) + 38 bytes

NI::CNi4882EventProxy::ProcessEventReturnValue(int) + 35 bytes

NI::CNi4882StaticEventProxy::Invoke(int,int,long) + 103 bytes

NI::CNi4882::EventThunk(int,int,int,long,void*) + 43 bytes

I will double check that all references are properly closed.

Thanks, again, and thank you for the references.

If you have any other thoughts, I would certainly appreciate them.

Best,

Jack

[Josh_L1]

Hi Jack,

Sorry for the late reply, it's been crazy around the office lately. In any case, Is it possible for you send me a small section of your code that deals with the VISA communication. I don't see the attached code you mentioned in your post.

In addition, have you checked the windows event log? It might give you another perspective on this issue.

Have you done similar applications in the past? Were they successful? Since we are working with a third party board in additional to old software, I wonder if it's GPIB compatible. One way to test this is do create a simple read and write application with your board and the USB-B controller. Test the application and see if you are able to communicate with the board via USB-B controller. I know you mentioned that you did a loop back test in my previous post. I'm not sure if it was just within MAX, it's always a good idea to also do it programmatically.

For the meantime, I will need to do some more research on this. I will get back with you once I find anything relevant.

One last thought, have you contact advantech support regarding this issue? I'm not really sure how their product interacts with MAX. There might be some fundamental compatibility issue there as well.

Regards.

Josh L.

[jb1805]

Hi Josh,

Sorry for the delay in getting back to you. I am attaching the code that was written for the GPIB communication. I don't think that I had pressed the "Add Attachement" link after selecting the file, last time. Since my last post I have made a few changes to the code and it appears to be working but throws an exception after running for a while.

This is what I did. I added 2 flags defined in MainFrame that are used to know when we are in the event handler (GPIBEventHandler) and when we are in the code that responds to the event, OnGPIBEvent. In each of these functions, there is a while loop that waits until the flag is cleared from the other function. There is a Sleep(1) inside each while loop as well as just after them. Once out of that loop we either InstallGPIBHandler or post a message that there has been an event. I also keep track of the number of times we are in each loop and display that on the status bar of the program.

The program used to crash within a few minutes but now will run for at least an hour. I did another experiment to see if it would run overnight. I started MAX and then started the application. I sent some commands and queries to the instrument and it behaved as espected. So, I left for the evening and when I got in the next morning, the instrument was still functioning. I sent a query using MAX and got an Internal application error. I then added some more code so that I could see what error message it was.

To answer your question about similar applications. No, this is my first time creating an instrument and using the NI PC/104-GPIB card. I have written several successful applications which act as a controller using the NI USB-B/HS using the CNiVisaSession object.

Since the instrument was behaving fairly well, with the exception of that last problem, I wrote an application that would communicate with the instrument continuously at timed intervals. This program uses the CNiVisaSession object and is able to communicate with my instrument via the USB-B plugged into the PC/104 GPIB card in the instrument. I started the program last night, along with Spy++ to capture the communication and let it run overnight. It ran for approximately 45 minutes before throwing an exception. The exception message was: "488.2 Exception: Status = 8148 Error = 6 Transfer Count = 0". My status bar shows the Event Wait Count (OnGPIBEvent) to be 44205 and the Handler Wait Count (GPIBEventHandler) to be 0.

Thank you for your help so far. I certainly appreciate any other suggestions/advice you might provide. If I can provide further information please let me know.

Best regards,

Jack B.

[Josh_L1]

Hi Jack,

Thanks for the update. I found an article on common GPIB/488.2 errors. It's listed below. Please the section on error 6.

http://digital.ni.com/public.nsf/allkb/2FA525A8585A92E9862566EE002A3755?OpenDocument

I hope this can give you some insight into the issue.

Regards,

Josh L.