NI VeriStand Add-Ons Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

AIT ARINC 429 Add-On Feedback

1.9.0 also includes the ability to specify the module by SlotID. That sounds like it would work. Does it?

Thanks for the feedback

Stephen B
0 Kudos
Message 121 of 193
(1,043 Views)

how does the slotID work when I have 4 chassis and the arinc all in the same slot per each chassis?

Thanks

0 Kudos
Message 122 of 193
(1,043 Views)

Hmm good point I dont know. I'll check with AIT

Stephen B
0 Kudos
Message 123 of 193
(1,043 Views)

Hi all,

    I tried deploying to our second test environment and I am getting the same BSOD on undeply as awoods in post 90 of this thread.

We get the same Workstation as test environment 1 and the same setup, I even tried FTP copy test environment 1 RT and dumping on test environment 2 RT and still on environment 2 I get the nice BSOD on undeploy while everything is fine on environment 1.

I guess it's more than just a case here, and possibly a driver problem as before we were running AIT 3.13.2 SDK with 1.7.0 custom device and it was just fine.

0 Kudos
Message 124 of 193
(1,043 Views)

Hi Claudio_G,

I'm sorry to hear that. Hopefully this helps us isolate the issue.

You say all was fine with 3.13.2 and 1.7.0. Did you just now change from those versions to different versions and then the issue appeared? If so, what did you change to?

I have been unable to reproduce this here with any version of the custom device and AIT v4.6.0

Thanks,

Stephen B
0 Kudos
Message 125 of 193
(1,043 Views)

I updated all cards to 4.6 firmware, installed 4.6 RT files through MAX and updated custom device with 1.8.2.

I just noticed there is 4.7.0 SDK on AIT site. I'm going to try with that and see what happens.

The thing is that environment 1 seems fine undeploying while enviroment 2 seems not. I tried a fresh install, a copy of environment 1 RT over to environment 2 RT.

Tomorrow i'm going to try some more things. including maybe a reverse back to 3.13.2 AIT RT dlls and 1.7.0 Custom Device.

0 Kudos
Message 126 of 193
(1,043 Views)

OK Thank you for taking the time to test. I look forwrad to the results.

Stephen B
0 Kudos
Message 127 of 193
(1,043 Views)

Ok here is the error

20140429_104631_small.jpg

We tried 4.6.0 with 1.8.2 and 4.7.0 with 1.8.2 and we got the BSOD on undeploy (4.7 btw does not show the FIFO errors anymore).

Every time I cleaned both Host and RT from any remainings of any AIT drivers/libraries other than the one I needed.

I then recompiled 1.8.2 against 3.13.2 and installed 3.13.2 on the RT and no problems at all on undeploy.

This should demonstrate that the Custom Device has no problems while the AIT 429 libraries cause the problem.

Now the error says something about some serial console logging, how to enable BSOD data out from COM1?

0 Kudos
Message 128 of 193
(1,043 Views)

Random thing I noticed -> you have six CPU cores. How is this possible? Do you have hyperthreading turned on with a 3 core CPU on a custom RT desktop? If so, you should certainly turn off hyperthreading as it causes terrible performance problems with Real Time Operating Systems.

Wow excellent work debugging the issue! Thank you. I will work with AIT to get this resolved as soon as I can, and I will add this as a known issue to the download page.

Since I cannot reproduce this problem here, I am interested in getting as much debugging information from your controller as possible, if you have time.

On PharLap real-time targets running LabVIEW Real-Time (RT) 2009 and later, the OMNI console outputs additional crash and debug information through the PharLap controller's serial port. To configure the controller to output this additional information, add the following tokens to the ni-rt.ini file:

2010 and newer:

[SystemSettings]
EnableOMNISerialConsoleOut=TRUE
OMNISerialConsolePortAddr=0x3f8
OMNISerialConsolePortSpeed=9600

2009:

[SystemSettings]

EnableOMNISerialConsoleOut=TRUE

OMNISerialConsolePortAddr=0x3f8

OMNISerialConsolePortSpeed=115200

If you need to use a seperate serial port for retrieving the debugging information you can change the port address tag from 0x3F8 to 0x2F8 for COM2 on the controller. The default value is for the COM1 port on the controller.

After adding the tokens to the ni-rt.ini file, a null modem cable can be used along with a console viewer such as Putty to retrieve the serial debug information. If you're unfamiliar with this processes, see here: http://digital.ni.com/public.nsf/allkb/354A5124E6A667988625701B004A77CD

Stephen B
0 Kudos
Message 129 of 193
(1,043 Views)

Can you give me a list of all the hardware you're using, what slots items are in, and the versions of software you are using? For both the crashing and non crashing targets

Thank you

Stephen B
0 Kudos
Message 130 of 193
(1,043 Views)