How to use 9512 in FPGA Mode?

[K.Ross]

Hi, 

I have two NI 9512 in a 9030 cRIO Chassis. 

I have successfully created a new project, added my cRIO, added two Axis configued them and run up the interactive test panels. My Stepper motors are running as should be. This was good for a simpe test to verify my system is all up and running. 

I have other requirements for the system that require me to run this on FPGA. I took to the LabVIEW example finder as a place to start and came across "Stepper Interface (9512).lvproj"

This is for a single axis, so I made a clone of the FPGA code and ensured they had different names to the first axis. Compiled and ran it. When I run this I am seeing my stepper motor "judder" at random intervals during the rotation, almost as if it is slowing and speeding up. 

I am trying to get to the bottom of this and understand why this is happening. Any advice would be greatly apreciated. 

Using LabVIEW 2014 SP1

Many Thanks 

Kev

[aevans2]

Hi K.Ross,

Is the juttering regular? and how have you modified the code to be for more than one axis exactly? maybe link the code here

Thanks,

Alex

[ZX81]

I agree, it sounds like a coding issue.  Like a shared local or global variable used for both axes.  Or both axes using the same output(s).

Did you try the example on one axis (with no changes)?  When possible, it's usually a good idea to try the example with no changes first.

And good job looking for examples early.  A lot of people miss that great resource.

[K.Ross]

Hey Thanks for the interest and the comment around this. 

The code from the NI Example runs perfectly out the box.

To add the additional axis we cloned the loop and renamed all the Control and Indicator to have a “2” at the end. We also tried having both axis in a single timed loop.

The code runs fine when alone, but when running other (unrelated) modules alongside it. We see issues.

Probing this further, basically we are monitoring the setpoints being used by the RT code (see 9512 stepper interface example) and notice there is an occasional glitch where a setpoint is generated in the wrong direction, i.e, if sending a straight line move, you expect a constantly rising setpoint (new value generated each scan engine cycle) however when the "judders" occur, we observe a setpoint generated that is lower than the previously generated value. This lower setpoint causes the motor direction to reverse and is the cause of the judder we experience. The next generated setpoint is a value that you would expect.

Many thanks

K

[aevans2]

Hi K.Ross,

Are you saying the code runs fine if run alone, but when run alongside other code it judders?

if so, are any of the other programs you're running attempting to access the same resource as the one you're getting problems with? which model cRio are you using? do the other programs you're running also have moments where they judder? and how many other programs are you attempting to run?

Thanks,

Alex