Labview Question

[professorX]

How can I debug without having the robot connected?

I want to see if the values of the motor will change once I press a button on a joystick.

[Alan Anderson]

You'd have to replace all the cRIO-specific VIs with emulated ones, including the Joystick and Motor VIs. It's not a casual undertaking.

[Greg McKaskle]

If you don't have the robot connected, but you do have the cRIO and DS, then it becomes possible to perform debugging to a basic level. You'd connect the joystick, DS, and cRIO and computer together, run the app, and put a probe on the input to the motor. Clearly the inputs to the FPGA are not going to change without sensors attached, but you can access and update motors and other outputs all you like. The FPGA will dutifully update open circuits and you can test out logic stuff pretty well.

You can test other stuff by writing harness VIs to send sample data into the processing subVI. This HW in the loop testing is pretty much what NI HW and LabVIEW are designed to do.

Greg McKaskle

[professorX]

Originally Posted by Alan Anderson

You'd have to replace all the cRIO-specific VIs with emulated ones, including the Joystick and Motor VIs. It's not a casual undertaking.

Can you explain how to do this?

I forgot to mention that I don't have the cRIO since we shipped the robot with it.

[Greg McKaskle]

I forgot to mention that I don't have the cRIO since we shipped the robot with it.

Bummer. My post assumed you still had a cRIO. This is doable, but a bit more involved.

In that case, the first thing I'd do is zip and backup everything so that you don't have accidental edits showing up on the robot.

Next determine which portions of your app you want to test out. It will be very difficult to get the whole app up and running -- the PC can't do the FPGA I/O after all, and there are many calls to the FPGA.

Anyway, pick the leaf level code you most want to run on the PC. Drag it from the cRIO target to the My Computer target. Open the VI under the PC portion of the tree. You'll find plenty of broken subVIs when finished loading. You can possibly delete them, or open the subVI, save As to new name, and then delete the diagram to make a stub. In some cases, you may want to have the VI return model data -- a sine wave or random number or constant may be fine.

Once you get the things below your VI ready and you can single run, you will sometimes want to build a quick harness to call your VI with model inputs. This is also a good way to discover what your code does with flaky inputs, things like 0, big numbers, even infinity and NaN.

You can interact directly with the subVI panel and build as many of these harness caller VIs as you feel you need in order to drive your subVI through its paces. Obviously, you need to be very organized here and any changes you make to your code needs to be integrated back carefully without all of the stubbed code changes. So hopefully you don't have too many of these to do.

Greg McKaskle

[Luke Pike]

Trying to emulate a physical system is really hard to do, because there are so many things that you have to take into account.

I did give this a try myself, though. I was trying to emulate our turret. I got the spec sheet for the globe motor, found the rpm, multiplied it by 0.5 (50%) to get it's real rpm, divided it by 60 to get the rps, and multiplied it by 360 to get the degrees per second.

To emulate the encoder on the motor, I took the desired speed, multiplied it by 12 (the voltage of the globe motor), and I assumed that there was a linear association between the voltage and the degrees per second (there probably isn't) and convert that value to desired degrees per second. I multiplied that value by time elapsed, and added it to the turret angle.

As you can see, it's a very involved process, and not completely accurate. I was able to find and squash some bugs in the software though, so it's not without merit.

[Greg McKaskle]

Sounds like you are on your way. As you say, some testing pretty much requires feedback from real world sensors or response from the system, and modeling it can be quite hard. But it is forward progress.

Greg McKaskle

[Joe Ross]

Another way (possibly less invasive) would be to use a conditional disable structure. Put all the cRIO specific parts in the default case, and in the other case, use TARGET_TYPE==Windows and use normal front panel controls. See the attached picture for one place where I did this.