Crashes OS

[Bill from CPI]

I recently took over a program from a retiring engineer. The first upgrade they wanted me to perform was adding a programmable power supply. I have found that I can use the Measurement & Automations to talk to the power supply and monitor the commands with NI Spy but when I go to my program in the VB environment there is not response from the equipment.

If I try to running VB and NI Spy together it crashes XP. If Try to go back and forth from the Measurements & Automations to the VB it also crashes the OS. It’s like some sort of “DLL” conflict. I’m not sure if this other engineer complied his code on this computer or not.

Any suggestions?

 

Thank for your time and attention

 

[TV_Enable]

Hi Bill,

Can you tell me a little bit more about your application?  What hardware are you using (i.e. PXI-4110, etc)?  What does your VB program do exactly?  I look forward to hearing from you soon.  Have a great day, Bill!

Regards,

Todd V.

[Bill from CPI]

 

Thanks Todd,

The program is extremely simple,      ' Set voltage    pstrSCPIcmd = "VOLT" & Str$ (gsngVoltage)    Call Send(0, gintIeeeAddress, pstrSCPIcmd & Chr$(10), NLend) ‘Read Voltage        pstrReturnString = Space(40)         Call Send(0, gintIeeeAddress, "VOLT?" & Chr$(10), NLend)        Call Receive(0, gintIeeeAddress, pstrReturnString, STOPend)        gsngMeasuredVoltage = CSng(pstrReturnString)        lblMeasuredVoltage.Caption = "Measured Voltage =" & gsngMeasuredVoltage  I have included             NIGLOBA.bas Version 1.7 from 1997And            VBIB-32.bas Version 1.7 also from 1997  I have a fair amount of experience with VB and IEEE, but this is my first time with the NI card, so the problem is probably something really really dumb. 

Thanks again.

Bill

[TV_Enable]

Hi Bill,

Thanks for including your code.  I do, however, need to know what hardware you are using.  You mentioned a power suply.  Which power supply is it?  What other hardware are you using?  Have a great day!

Thanks,

Todd V.

[Bill from CPI]

 Todd,                Sorry I didn’t get back to you yesterday. I’m sure you can relate, this is one of 6 projects I’m working on and each one of them is full time. Go figure. Any way this project is updating some really old equipment the Agilent N5763A (IEEE Address 5) is replacing an HP59501B (IEEE Address 22) Power supply programmer which feeds an HP 6260B DC Power supply, so It is out of the circuit. The only other thing on the bus is an HP 59306A Relay Actuator (IEEE Address 😎 which I removed for testing, and isolated my code to only talk to the Agilent N5763A.             The old program works on this station and as I said before I’m not sure if the old engineer compiled his code on this computer or not. This got me thinking… Could the order of installation cause this type of problem? If the IEEE drive was loaded first then followed by the VB6. Could this have messed with the “.DLL”?             Maybe I should uninstall the IEEE driver then re-install it? What do you think? Bill 

[TV_Enable]

Hi Bill,

You are completely correct when you ask about the order of driver installation.  This is very important.  The driver must be installed after you programming software.  This is because the driver will search for a language (LabVIEW, CVI, .NET, etc).  I would recommend uninstalling and reinstalling your NI-488.2 driver software.  You can find the latest drivers and updates page here.  I look forward to hearing back from you soon.

Regards,

Todd V. 

[Bill from CPI]

I have good news and bad…The good news is that the OS is not crashing any more the bad news is that I’m still not able to talk to the device.

I physically removed the IEEE driver card and uninstalled the software then re-installed it.   

I then stripped the software down to the bare bones.

The program has NIGLOBAL.bas (Ver. 1.7 Date 1997 12K in size) and VBIB-32.bas (Ver 1.7 Date 1997 51 K in size) as modules. The main form has one command button with the following code      

Dim pstrReturn          as String

  

            pstrReturn = Space(100)

  

            Call Send(0,5,”*IDN?”, NLend)

 

            Call Receive(0,5, pstrReturn, STOPend)

    When I step thought the code it acts like it is talking to the unit but “pstrReturn” comes back unchanged. When I try an *IDN? From the NI comm. software it does report the unit ID.   

Thanks again for your time

Bill    

[TV_Enable]

Hi Bill,

There a couple of things we should try to get this up and working for you.  When you open Measurement & Automation Explorer and you click "Scan for Instruments", what exactly do you see?  Do your instruments show up as they should?  If not, could you please send me a screen shot of what you are seeing when you scan for instruments?  If you can see your instruments, what happens when you try to communicate with the device in MAX?  Does it respond to a *IDN? query?

Once we can verify that your instruments show up in MAX, we can then move on to your code.  Have a great day, Bill!

Regards,

Todd V.

[Bill from CPI]

The Measurement & Automation seems to work just fine; the Scan for instruments locates all the devices on the bus. I have had up to 3 on at one time but for this testing I have limited it to just the power supply. The power supply does correctly responds to the “*IDN?” when queried from the MAX.   As you can see from message 7 I have simplified my code about as much as I can and still expect a response.  

My assumption at this point is that when I did the un-install that one or more “DLL” were not removed. This is understandable as most “DLL” are used by more than one program.

 

When the re-install took place the install program checked the existence, the date and time of the files and didn’t change them. If this is the case then I’ll need to get a list and location of the “DLL” that are loaded or updated during the install routine so that I can manually rename them, then rerun the install program.

 

[Bill from CPI]

Todd

 OK so here is what I did… I used the NI.Spy program to monitor what MAX was sending over and I noticed that instead of “Send” and “Receive” it was using “ibwrt” and “ibrd” (after getting board device number from “ibdev”). So I modified my code to match that and it started working, unfortunately I don’t have time to try to figure out why. They may have “lower” entry points into and out of the “DLL”. Like I said I don’t have time to figure it out, but I do want to thank you for your time and assistance.

Bill