6533 delay trigger

[jjohannsen]

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.

Thanks

Jason

[jjohannsen]

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.

Jason

[hoffiz]

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.

[jjohannsen]

Jaime,

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.

Thanks

Jason

[hoffiz]

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.

 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 Clk.vi” 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

 

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

[jjohannsen]

Jaime,

Thanks for reviewing this.  The only difference I can see in the example vs. my code appear to be "Finite" vs. "Continuous".  Could this be causing a problem with the external clocking?  Did I miss any differences?

If I set the sample mode to Finite, and set the buffer size to greater than the expected # of samples for one cycle, will this work the same way as setting to Continuous as it is now?  Keep in mind I am stopping and starting the task every cycle, with approx 3000 samples being received over a 30+ second cycle.  Stopping and starting the task (with "DAQmx Start Task" and "DAQmx Stop Task" VIs) will reset the buffer, correct?

To find velocity, I just post-process the recorded angles and CAN message timestamps.  Then do a Vel =  [Angle(x + 1) - Angle(x)] / [Time(x+1) - Time (x)] calculation where x is index of array.

Thanks,

Jason

[Hani R]

Hi Jason,

I noticed that in the your program you never start the task or perform a read on the digital ports.  Comparing the two programs, the example program also has a DAQmx Clear Task VI and error handling which is not present in your VI. 

Starting and stoping the task will reset the buffer, but requires a small amount of time (system dependent) to do so.

If you set the sample mode to Finite, the buffer size will be set by the number of samples to read.  You can force the number of sample to be equivalent to a Continuous sample mode, but the behavior of the two modes are inherently different.  When the sampling mode is set to Finite, the DAQmx Read VI will wait until the number of samples specified is acquired.  If the samples are never acquired, the DAQmx Read VI will timeout after 10 seconds (by default).  When the sampling mode is set to Continuous, the DAQmx Read VI will take whatever data is in the buffer regardless of the number of samples.  Refer to the KnowledgeBase article, KB 31T899KD: How is the DAQmx Buffer Size Allocated for a Finite or Continuous Acquisition?, for details about buffer allocation. 








Message Edited by Hani R on 12-26-2007 03:18 PM

[jjohannsen]

Hani,

I am starting the tasks at the start of each cycle, reading the buffers later on during the test, when power is applied and the CAN device starts transmitting messages, and stopping the tasks at the end of each cycle.

I can specify the # of samples to read at the DAQmx Read VI even when set to continuous acquisition, correct?  Then the Read VI will only take as long as it needs to read out that # of samples from the buffer?  i.e. if the buffer size is 1000, there are 350 samples in the buffer, and I set the Read VI to read 350 samples, there should be no wait time?

I read all available CAN messages, and the corresponding digital input samples, every 100 ms or so, in order to keep the CAN buffer from overflowing (max buffer size of around 75 messages with my configuration and both ports being used).  I have attached the portion of code I use to do this.

My question now is, using "continuous" sample mode, and having the buffer size manually set to 1000 samples, could this cause a problem with "re-sizing" the buffer as more samples are placed into it, and old samples are shifted out once 1000 samples have been collected and read?  I expect around 3000 messages and corresponding digital input readings for each test, so would setting the buffer size to ~4000 samples solve this issue (if it actually is a problem)?  Or would I need to set the mode to finite to truly stop any "re-allocation" of memory.  Or am I totally in the wrong place to be looking.

Thanks,

Jason

[Hani R]

Hi Jason,

I can specify the # of samples to read at the DAQmx Read VI even when set to continuous acquisition, correct?  Then the Read VI will only take as long as it needs to read out that # of samples from the buffer?

Correct.  One thing to note is that setting the number of Samples to read when using the Continuous Sample Mode will allow the computer to pull whatever samples are available off of the buffer (when the PC is ready). 

That being said, I don't think the problem is coming from a difference between the Continuous and Finite sample modes or the buffer size.  How are you converting the binary bit pattern to an angle?  What is the rate of the external clock that you are using? 

It is important to ensure that the frequency of the external clock is significantly higher than the frequency to be measured.  Refer to the DeveloperZone article: Making Accurate Frequency Measurements for details, but essentially when the clock and signal are near the same frequency, error may be introduced due the phase difference between the clock and the signal. 

[jjohannsen]

The encoder has a 10 KHz update rate.  It is a parallel output gray coded binary 14-bit encoder.  It has 14 individual 5 V TTL outputs to the 6533.  The encoder outputs do not have a frequency, they just turn on or off depending on the angle.  I take each encoder measurement from the 6533 and convert it from gray code to a decimal value, then convert to degrees by dividing by 16384 and multiplying by 360.  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.

Thanks

Jason