Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

My computer locks up when using NI-dnet pcmcia card but not with NI-dnet pci card?

I ran the SingleDevice vi. example with the NI-dnet PCI card without incident (In fact I have modified the SingleDevice vi. for various devicenet applications and have had no incidents, when using the NI-dnet PCI card.) However, when I run the SingleDevice vi. example with the NI-dnet PCMCIA card, my computer locks up (screen freezes and the computer does not respond to the mouse or keyboard entries) after 1 min to several hours of running. It appears that the SingleDevice vi. is hanging up during the NIWriteDnetIO. The only way to "unlock" my computer is to eject the pcmcia card. However even after this the SingleDevice vi. does not fault out, but continues to run until I press the STOP button. I am using NI-dnet driver version 1.4 with LabView 6.1. My computer is running Windows 2000 service pack2. Any suggestions. Thanks.
0 Kudos
Message 1 of 6
(4,076 Views)
Hi fusion1,

Do you see the lock-up, when you start up your system, go the the Measurement & Automation Explorer an execute a self-test on that PCMCIA card (right-click » self-test)?
If so than that points towards a resource problem (interrupt line is locked and blocks the computer). I assume you use some kind of PCI-to-PCMCIA adapter in your desktop for the PCMCIA-DNET card? Do you have more information about this adapter (manufacturer/model)?

-B2k
0 Kudos
Message 2 of 6
(4,073 Views)
Hello B2k,
I don’t see the lock-up when I start my system. In addition, the pcmcia card passes the self-test in Measurement and Automation Explorer. The lock-up happens after the SingleDevice vi has established communication with my DeviceNet slave and the vi is in the process of reading and writing data. The attached NI-spy capture appears to collaborate this observation. Please see attachment. I suspect that the pcmcia card loses synchronization with the DeviceNet slave during the “Wait on Occurrence” function. I reached this conclusion by taking the “Wait on Occurrence” out of the SingleDevice vi while loop. In this case the Read DeviceNet IO vi and the Write DeviceNet IO vi within the while loop can be observed to utilize 100% of the CPU and greatly slows the computer. If this out of sync is the culprit, I think it may be caused by either a hardware (cable or pcmcia card), driver, or vi problem.
You are correct in your assumption that I am using a PCI-to-PCMCIA adapter for the pcmcia-dnet card. The adaptor I use is a Texas Instruments PCI-1225 Cardbus Controller (Driver Version 5.0.2195.2959). It is set to use interrupt #11 on my computer. The Window’s device manager does not indicate any conflict. However, I do notice that other devices use the same interrupt 11, but they do not appear to be active. Also it should be noted that I ran an application version of the SingleDevice vi on a laptop (Dell 700Mhz Pentium 3, 128k Ram, Windows 2000, Service pack 3, NI DNet version 1.3) and experienced the same lock-up issue. I appreciate any suggestions or insight you can provide. Thanks.
Best regards,
Fusion1
0 Kudos
Message 3 of 6
(4,056 Views)
fusion1,

The 0xBFF62005 error points to a problem with setting attributes. The precise language relating to this error is as follows:

"The value of one or more properties (attributes) is invalid. This
error occurs for Set (one value bad) or Initialize/Config (one or
more values bad). Solutions: Consult the Programmer
Reference to verify the values of each property."

I notice that the error first occurs on an 'ncAction' which is an NI-CAN function call. You are also using NI-CAN user callbacks. Are you mixing NI-CAN and NI-DNET calls? Would it be possible to post your code?

Craig H.
NI Applications Engineering
0 Kudos
Message 4 of 6
(4,044 Views)
Hi Craig H.

the ncAction() is called by the 'Operate DeviceNet Interface' function. It looks like as if it is doing just the same. The second parameter (0x80000002) stands for 'Stop': "Stop all DeviceNet communication for the associated interface."

If the application stopped for about 13,5 hours (see timestamps) and hung the computer I could see that the driver is 'confused' (at the least).

fusion1,
you mentioned that you have Servicepack 2/3 installed on those computers. Both are really old, even though Microsoft fixed a lot of 'security problems' they did fix a lot of othyer things, too. Can you install SP4 on that computer? Does it help?
As this is essentially a crash, you might want to sent an email to support@ni.com and reference this thread.

B2k
0 Kudos
Message 5 of 6
(4,040 Views)
fusion1,

I would take biker2000's advice and submit a support email to 'support@ni.com'. I will receive the email and we can figure this one out offline!

Craig H.
NI Applications Engineering
0 Kudos
Message 6 of 6
(4,033 Views)