FPGA question

[jeff_scharpf]

Hello all,

Tomorrow I will be trying to troubleshoot a problem with a cRIO that was programmed by an ex-employee.

I am now familiar with Labview 7 and 8 using FPGA, so I know my way around the cRIO. I'm still a novice Labview programmer though.

I realize that this is a general question so I'm just looking for some "starter" hints before I wake up and grab some coffee to sit down and start looking at this thing. I want to look for the obvious things first.

It's a cRIO which has an FPGA program and a RT program. I'm told it was working fine until last week, when someone changed some hardware on the system. Now it "appears" to do nothing. What they mean is that the test doesn't run.
What I see is what appears to be an FPGA program that is running but not doing anything.

For the sake of this discussion, let's say the program was working and didn't change. I've tried re-compiling and re-downloading the FPGA program. I click the run, I see the files being downloaded, and I see the main panel. Everything appears to be running but nothing is happening. If I install break points they are never hit. There are some digital inputs that do not reflect the real world.

I guess I'm looking for advice on what steps you would take in approaching this. I have a second machine which supposedly has the same program that I can take and download, but I'm wondering if I should clear out the FPGA and just put a simple program to read or write a digital input or output, and go from there. (The FPGA program was quite complex, and I'm wondering if it's in some internal loop that I  can't see)

I realize that I'm only giving small details. I'm just looking for how you experts would approach this. I value your opinions as I've been helped many times here.

Should I be able to "see" or step through and FPGA program?

Well, advice.. opinions.. all welcome. 

Tomorrow I start diagnosing 🙂

Jeff

[jeff_scharpf]

I'm sorry I wasn't clear. I have more experience with LV8 FPGA than I do LV7 FPGA, but I have programmed in both.

This application is LV7 FPGA cRIO.

Jeff

[jeff_scharpf]

Good morning.

I have started out by just developing a simple VI with one digital input and one analog input. This cRIO has a digital input module in slot one and an analog input module (think it's the 9215) in slot 7. There are other modules.

So far I was going to just see if I can read the digital input and the analog input.

Any suggestions if I get nothing at this point? Could the FPGA be bad? Is there a "test" vi out there that would excersise the I/O so I can find out if it's hardware or software?

Jeff

[jeff_scharpf]

and it's my Birthday today so I should get special attention lol 🙂

[Rick_K]

Troubleshooting is always tough when someone else wrote the code.

You mentioned a change in hardware. The first thing you need to do is exactly as you said. Try out a simple reading of the digital line and the analog line. I am going to guess that it will work. Then go to your prewritten program and exchange all of the I/O points with new ones. This will re-associate any hardware changes with the actual existing hardware.

The next big thing about debugging is the lack of debugging tools available due to the fact that once you compile, download, and run, there is no way to set breakpoints or probe lines.  This "code" is now running independently in hardware. The best way to probe or change lines is to add controls and indicators everywhere during development. If you ever think you will want to change a value make it a control. If you ever want to probe a line create an indicator off of it. In FPGA controls and indicators on the front panel become registers for controlling the hardware. This is great for debugging, and then in the final solution you can remove unnecessary indicators and change control into constants.

I hope this helps,
Rick Kuhlman
Applications Engineer

[jeff_scharpf]

Thanks for the advice,

I found the problem. He had a sequence and was operating a pneumatic clamp, then waiting for the sensor that showed that the clamp had actually closed before going forward. (I guess it was critical to not continue unless the clamp was indeed clamped).

So the clamp stuck, and the while loop waited forever for it to show that it had closed, thus locking up the program.

I can see other areas in the code where this could occur. I'm guessing the best thing to do is to put a time limit on how long to wait for something so the program doesn't get stuck.

In the meantime, he's back up and running.

jeff