From: jjohannsen on
I am using a PXI-8461/2 CAN card to trigger a PXI-6533 Digital Input card when it receives a specific ID CAN message.  The CAN card will trigger a timer in a PXI-6250, which uses pulse train gen to pause 5 ms, then send a RTSI trigger to the PXI-6533.  The 6533 reads digital patterns from a binary parallel encoder.  CAN messages are received every 10 ms.  I am using DAQmx, and LabView 7.1.
Intermittently, the 6533 sampling will be delayed, for one sample.  This is evident because we plot the encoder value vs time, and see the velocity spike for one sample, then fall for one sample.  It appears as though the delay is around .9 ms.  The CAN message timestamp is consistent at 9.9 to 10.2 ms.  We are seeing a delay in the encoder readings from the 6533, but not in the CAN messages coming in from the 8461 card.
We read CAN messages and corresponding encoder reading buffers every 100 ms or so, for approx 35 seconds.  A stepper motor moves the DUT and encoder back and forth.  This is where we see the velocity.  This is one test cycle, then a new part is loaded and it starts again.
I have increased the sample rate input (sets the maximum expected rate of external triggers) for the 6533 all the way up to 10,000 samples/sec.  The issue is still present, but has not been as frequent.  Have also tried closing the tasks, and re-opening/recreating the tasks for every cycle, with no luck.
To rule out the timer portion of the system, I have tested it with the CAN card directly triggering the 6533, without the pause generated by the timer (6250).  The issue is still present.
Attached is the configuration VI I am using to set up the tasks.

From: jjohannsen on
Note:  I am using PXI-6533 ports 0 and 1 for the RTSI triggered sampling.  I also have a separate task in the main application that is reading ports 2 and 3, with Internal Clock set as the sample trigger, with a scan rate of 100 scans/sec.  I have tried removing the buffer config for the 2nd task, and just using software timing to periodically sample the ports, but the issue still persists.  I cannot remove this task at this point, as it is used to track the encoder position for the machine's use, separate from the testing purposes.
From: Jaime F on
Hi jjohannsen,

I would need to ask a couple of questions to be able to help you. If you can provide some kind of screen shoots of what your encoder vs. time plot should look like, and how does it looks when you skip a sample?

I'll try describing how I understand your system is setup. You have a CAN compatible system generating messages every 10 ms, those messages are receive by the PXI-8461/2. When a specific CAN message is receive the PXI-8461/2 triggers a timer in a PXI-6250. The PXI-6250 holds for 5 ms when this trigger is receive and then send a trigger through one of the RTSI lines to the PXI-6533, which reads the encoder. 

May I ask, which is this specific message?, and what does it means? Since CAN message are sent every 10 ms and you read these messages from the CAN and the encoder readings every 100 ms, what happens with the other 9 CAN messages? Can you provide some more information on the parallel encoder? What is the output specification for the encoder? Is there a new encoder reading for every CAN message? 

My guess on your issue is that, those times where you have fall for one sample in the PXI-6533, it was reading while no reading of the encoder was available, that is the reason why I would like to know what type of synchronization you have between the encoder and the PXI-6533. Also can you explain why you need the PXI-6250 generating the 5 ms delay?

Any other information you think might help me help you, please don't hesitate on posting it.
From: jjohannsen on
I am reading all 10 messages and encoder samples every 100 ms.  100 ms is just the rate at which the software is reading out all of the buffered data.
The specific CAN message is a periodically transmitted message from an angular measurement device that reports it angle.  This is then compared to the actual angle measured with the encoder.  The motor is set to move at a constant velocity (1800 deg/sec).  The angle and velocity messages received over CAN confirm this, so we know the motor is not really accelerating and decelerating for 20 ms, as seen in the attached charts below.
The 5 ms delay is part of the test to help align our encoder sample points with the internal sampling of the CAN DUT.  We have tried running the test with the 5 ms timer pause removed, but the issue was still evident on the velocity plot.
I allow a 30 ms timeout when reading the digital input buffer.  If there happens to be one less sample in the 6533 buffer than in the CAN buffer, that sample should be present in < 5 ms. 
The encoder has a 10 KHz update rate.  It is a parallel gray coded binary 14-bit encoder.  5 V TTL outputs to the 6533.  There will be a new encoder reading for every CAN message since the CAN card triggers the timer card, which then triggers the 6533 after 5 ms.  RTSI (PXI bus) triggers are used.   Please check the above VI that contains the configuration VIs.

Good vel sample.JPG: vel sample.JPG

Bad vel sample.JPG: vel sample.JPG
From: Jaime F on
Open your code this is what I see:

I can tell from the labels that the top part is the 6250 Timer Task and the bottom is the 6533. Something that might help and I will like to check is the part of the code that generates the degrees/second vs. message plot, you may want to post it.

<img src="">

&nbsp;Going on with the troubleshooting something I will try is making the 6250 (Dev4) count how many messages it receives from the 8461. You should be able to do it setting up a read digital channel from Dev4 or setting up a change detection task to count how many times the message has been received on the 6250. Another though would be doing the same with the 6533 (Dev3); counting how many times it receives the clock from the 6250 after the timer is done. Since you can count how many messages the CAN has sent, it should the same for the pulses receives on the 6250 and the clocks ticks receives on the 6533. It should also work with the no-timer setup.

I would like to clarify to avoid confusions that the 6533 is using the signal from the 6250 as an ?external clock? not as a ?trigger?. I would like to point also that if you take a look at this shipped example: ?Read Dig Port-Ext you will see that the configuration to read the port is different from what yours, you might want to try the approach taken on the example.

I hope it helps

&nbsp;Message Edited by Jaime F on 12-20-2007 06:06 PM