ISR goes to 100% after I plug a VGA screen into my RT desktop

[AnthonV]

Hi, has anyone seen this - my RT system is running smoothly until I plug a normal VGA screen into the RT desktop.  Then the ISR  CPU usage jumps to 100% (see attached image).  This prevents any of my RT timed loops or other processes from running and the whole system is useless. This does not happen if the VGA screen is plugged in already when the RT system boots up.

Any help or comments will be appreciated.

[Samuel_S]

AnthonV,

Does this happen with another VGA screen or just a certain brand or model? Does an HDMI screen work? I have never heard of this happening and have used VGA monitors many times on Real-Time systems. Could you try a different VGA cable or port?

It sounds like the OS is determing how much usage goes to the overhead of having the screen plugged in and this varys based upon the memory already allocated when the exe is running. What does this VI do? How large is it?

[Robert_North]

Sam S,

AnthonV has asked me to respond to your reply on this issue.

I've plugged in multiple monitors with the same result.  It does not seem to matter which brand of monitor I use.

This application is a machine control applicaiton and with the PC equipped with 2 Ethernet adaptors, an NI PCI-6229 card and an NI PCI-6509 card. The application is approximately 2.5MB

and makes use of an IMAQdx device connected to one of the Ethernet adaptors.

Regards,

Rob

[Samuel_S]

RobertNorth,

Thank you, the only reason i can think for the processor to do that is if there's an interrupt being triggered which isn't responding to the OS... so the OS just sits and waits or retries the interrupt over and over but this seems unlikley. What I would to do is save a back up of everything and then try reformatting the target to see if anything appears different. If that doesn't help you may want to try reinstalling Real-Time as the BIOS may have become corrupted. Is this behavior reproduciable on another computer?

[Robert_North]

I've finally managed to build another Real-Time PC and can't reproduce this fault.  This PC has exactly the same spec as that one exhibitine the fault so I can assume that this in not a LabVIEW RT issue.

Thanks for your help.

Regards,

Rob

[Samuel_S]

No problem Robert 🙂 Glad your up and running

[Texas_Diaz]

Hey,

Actually, we ran into something very similar on a platform we were evaluating - it turns out that the BIOS had specific video interrupts enabled and when the VGA was unplugged or plugged after the controller was up the interrupts fired.  Those interrupts are not supposed to fire unless the OS registers an interrupt handler for them, but alas they were firing anyway.  Since there was no handler, the RT OS is throwing the interrupt away, but the device keeps insisting it needs servicing - a loop that blows the system to hell.  You need a new BIOS update that handles this correctly - when we ran into this problem, we were able to work with the BIOS developers to disable these interrupts; if this is an off-the-shelf system you probably don't have this kind of support from the vendor. 

Good luck.

-Danny

[AnthonV]

Thanks for the update.  Since we are not seeing this on the newest desktop we recently puchased from Dell, I'm assuming that they have updated the BIOS since our previous purchase.  We'll check to see if the BIOS versions are different and if so, update the older desktop to the latest BIOS version.

Cheers.