LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Condor Arinc 429 from NT to XP

I am hoping someone may have seen this type of problem years ago and can shed some light on a possible solution.
 
I just starting working for an aerospace company. They have test stations in their factory that are running executables written in LabVIEW 5.1.1, on Windows NT, and using the Condor ARINC 429 board, on a VXI chassis, along with some other boards. Due to the nature of the product, they will not upgrade any of the software. These machines have been working fine over the years. They just built a new test station. Due to the dual core processor machine that they purchased for this, they had to install windows XP. All of the test run fine except the ARINC 429 test. I have buzzed out all of the wiring within the test station 3-4 times and I am convienced the hardware is good. I have also swapped out the ARINC card with one from a NT work station, that is working, and still get the failures. I believe the issue is related to software. My guess is that there is some transition issues trying to use the executables, dll's, etc. when moving from the NT machine to the XP machine. I have tried to run this in debug mode, but can not see any reason why there would be failures. I thought debug would slow it down in case it was a timing issue but did not see any change.
 
I do not know if this is enough information, but just thought I would ask if anyone has used ARINC 429 in the past when transitioning from NT to XP and saw any problems when doing that.
 
I have been using the latest and greatest LabVIEW in the past and dropping back to 5.1.1 is taking a little getting use to.
 
Thanks for any help from anyone who may have enough experience to have seen this.
 
 
0 Kudos
Message 1 of 8
(5,185 Views)
Wild Bill,

Could you clarify exactly what is not working properly?  Are you able to get the Condor ARINC 429 board to work on the XP machine stand-alone just fine?  Does the LabVIEW program crash or hang when running, or just not yield any data from the ARINC board?

Have you updated your drivers on the ARINC board for Windows XP?  Is the issue getting the ARINC working on XP or getting the LabVIEW 5.1 code running on XP?
Regards,

Jared Boothe
Staff Hardware Engineer
National Instruments
0 Kudos
Message 2 of 8
(5,162 Views)

I have solved my problem and I am posting this in case it helps someone in the future.

I eventually dropped back to the basics. I buzzed out all of the wiring, per the drawings, one more time to verify the test station was wired per the drawings. I decided to develop my own test function. I wrote my own ARINC 429 test program that would send a message out one of the transmit ports and receive data on one of the receive ports. I then had the techs build me a couple wires with pins on them so that I could loop back my transmit port to my receive port on the ARINC card. When that worked, I worked my way out the cable. Everything was correct. Between shifts, they run 24-7, I was able to borrow one of the working test stations for a few hours and trace it's wiring to make sure the drawings were correct. I ran my test program on the working system and it ran correctly. I might mention that we have a switching matrix card, not made by NI, in which the ARINC signals pass through. I was eventually able to find another group within the company that had a ARINC 429 analyzer that I borrowed. Perhaps it was sheer luck, but I had it connected to test points on the front of the test station. I noticed that when my test program was transmitting on one ARINC channel, I was getting data on another ARINC channel. Based on the wiring drawings, it was impossible for this to happen in a working system. Based on all of the other checks that I had done, I decided that the most likely suspect was the switching card. Somehow, it was putting data where is was instructed to and on a few signals that it should not have. I replace the switching card and that cleared up my problems.

 

Message 3 of 8
(5,140 Views)
Wild Bill,

Thanks for posting what you did to solve your problem!  I am sure it will help someone down the road.
Regards,

Jared Boothe
Staff Hardware Engineer
National Instruments
0 Kudos
Message 4 of 8
(5,119 Views)

Wild Bill,

Since I realise you became very intimate with the hardware side of the ARINC bus, I dare ask you a question that is not strictly related to the problem you raised.

I have been thrown at the deep end of a data acquisition project, that among other things, needs to record information of the ARINC bus. I am completely innocent. To make things worse, we're not getting any cooperation at all from the aircraft / engine manufacturer.

What I would like to understand first of all is: am I likely to find anywhere inside the aircraft some terminals that could allow me to connect to any of the ARINC buses on the aircraft, or is it more likely that I need to get under the hood and connect my wires directly onto one of the devices already on the bus?

I hope I made myslef understood, and I also hope you'll have some advice for me. Apart for the aircraft's own maintenance manuals, would there be any other sources of inspiration? I did find various ARINC tutorials, but they all assume you're already connected.

Thank yoo!

0 Kudos
Message 5 of 8
(5,026 Views)

Mihai,

While I understand what you are asking, I do not understand why. Why do you need to collect this data?

In the aircraft environments in which I have worked, the aircraft manufacturer documents how they expect subsystems to function in their system. This is usually proprietary information that can not be given out. The information given out is per subsystem and then only enough information to complete that part of the aircraft. This includes wiring, dimensions, weight, communication protocols, functionality, etc.  The connectors that I have worked with are military standard, screw together and lock in place, or railing system in which the black box is pushed into a slot, which has connectors in the back of the slot. Once the black box is fully pushed in, the box is locked into place. This helps eliminate the possibility that the connectors will become loose during flight. Wiring is shielded to help eliminate EMI problems. Due to weight, cost, EMI, etc. , aircraft manufacturers usually do not put in extra test/monitoring ports. If proper test of subsystems is done, prior to installation in the aircraft, and Built-In-Test are performed by the black boxes, while powered up, these ports are not needed.

I would NOT recommend that you consider attempting to change the wiring or connectors on the aircraft. This is a serious safety of flight issue. I do not know where you are located, but in the USA, the FAA and aircraft manufacturer will not allow this.

Now, back to the why question.

If your company has designed a black box for an aircraft, your company should have design documents on the box that indicate how the box is wired, communication protocols, etc. These documents are based on the requirements documents given to your company by the aircraft manufacturer.  If you are testing your company’s box, and you need to collect data to verify your box, then you do not need the aircraft. Your company should develop test that fully test the requirements specified within the aircraft manufacturers documents and your companies design documents. Boxes that have failed in the aircraft are replaced and the failed box is taken back to a service center or lab for testing to determine the cause of the failure. Usually, test stations are developed which contain instruments to simulate aircraft power, discrete signals, ARINC, or anything else the box needs from an actual aircraft. The box is connected to the test station and testing is performed, including collecting ARINC data. The test station can simulate ARINC messages transmitted and/or received. The amount of simulation depends on the requirements and the person designing the simulation/test. You can have a technician build a wiring harness that connects the test station to the black box which needs to be tested.

If you are designing a system to test something on the actual aircraft, then you will need documents from the aircraft manufacturer on how they have their system wired, etc. Most likely, you will need to remove whatever box you are trying to simulated/test. You can then connect your wiring harness to the connectors on the aircraft. I would use extreme caution to make sure your wiring harness matches the documents that describe the connector to make sure you do not damage the aircraft or any other boxes the box under test is connected to. I do not understand why this would ever be needed to be done since almost everything can be simulated with a test station external to the aircraft.

Larger aircraft manufacturers have simulation and integration labs. The purpose of these labs is to test the aircraft systems, as a whole, prior to placing them in the aircraft. The aircraft manufacturers and FAA require the manufacturer of the black box to extensively test their boxes prior to shipment to the aircraft manufacturer. This requires the black box manufacturer to develop test stations to simulate the part of the aircraft the box is connected to.  The FAA requires the aircraft manufacturer to fully integrate and test the subsystems placed into an aircraft. This is done through simulation/integration lab testing and later flight testing.

If you need in flight data acquisition, that would be a function of the black box your company is designing. I have not heard of LabVIEW being used as real-time imbedded code for avionics black boxes so I would think you are working with a test station.

 

I hope this helps out.

I work as a contractor in the Phoenix metropolitan area. I have my normal work, as a LabVIEW developer, and do some other minor projects unrelated to software development. My time is limited. If you have any further questions, you can email my personal email at William.Simmons.Sr@FineWineImporters.com . Do NOT add my email address to any mailing/advertising list or send resume’s.  I would consider any potential contract work.

0 Kudos
Message 6 of 8
(5,014 Views)

Hello everyone,

   I have few questions on ARINC 429:

1. Why it is called MARK 33 Digitial Information Transfer System? Is it because of 32 bit protocol?

2. Why it is called self clocking signal? I see this being explained at two places: a. Because of return to zero and b. atleast 4 NULLS b/w two consecutive words. I could not understand how this synchronizes without external clock. It would be great if anybody explains that (elaborate above two reasons).

I am glad to join this dicussion forum and thanks evryone to let me in.

 

 

0 Kudos
Message 7 of 8
(4,836 Views)

sidhnil,

 

I believe the ARINC 429 uses the MARK 33 DITS specs regarding signal levels, timing, and protocol characteristics for its bus.  As far as the other questions, I have no idea.  If you have any LabVIEW specific questions this is definitely the place to post (new thread preferred).  As for the ARINC, some other board members may have some knowledge on this, but you'd probably be better off using your favorite search engine for that information.

Regards,

Jared Boothe
Staff Hardware Engineer
National Instruments
0 Kudos
Message 8 of 8
(4,820 Views)