Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

6052E LIN

Hi, hope someone can give me some advice on this one.

I need to measure the time it takes from when a LIN message is sent to a target board to when an LED activates on it, ( i.e, the processing time of my target board to decode the LIN and turn on the LED).
I am using the LIN-USB 8476s with sync and I have a PXI 6052E with the LED connected to AI3.
What is the easiest way of doing this ?

Using a scope I can see the time is in the order of 8ms from when the message is sent to the LED turn on so I know my result expected.
Can my setup be configured to measure this to the microsecond?

There is an example in Labview called Sync DAQ and LIN Master Send and Receive.vi but this requires RTSI and I dont think my PXI 6052E has this.

Thanks !
0 Kudos
Message 1 of 13
(7,014 Views)

Hi,

You could use the mentioned example regardles of RTSI. The CAN part names the sync terminals RTSI, but we are talking about the sync connector outside the box.

The DAQ part routes the clock and start trigger to PFI 1 and 0 and that means you can use a simple NI Connector block to wire clock, trigger and ground to the USB box.

If you send the LIN frame, it gets received because the example has enabled self reception?. That means you got the timestamp from the frame you send out. Then you have to monitor your DAQ receive and when ever the Diode comes to light you should measure something. Now you should stop both loops and compare the time stamps.

Because both boards are synced the difference should be the time your target needs.

DirkW

0 Kudos
Message 2 of 13
(6,998 Views)
Hi DirkW,

Thanks for the reply.
I have not used any DAQMx so far until now so sorry about the newbie questions.

The vi gives an error  89120 saying that the terminal names are invalid. Attached is the error message.
Can you tell me why the Connect DAQMx Connect Terminal.vi seems to connect the source and destination terminals to the same device ?
I would have thought source would be my 6052E card and destination would be the LIN box.

Thanks,
Mike


0 Kudos
Message 3 of 13
(6,995 Views)
Ok,

I renamed the connect DaqMx connect terminals part as  /ai/ReferenceTrigger from /10MHzRefClock and that error now has disappeared.
Was this the correct thing to do ?
However another error has appeared.
It seems the LIN box is generating an error saying that the timebase has disappeared during communication.
screenshot attached

Any ideas ?
0 Kudos
Message 4 of 13
(6,994 Views)

Hi Mike,

Well, DAQmx should be easier then the old NI- DAQ. For your case you need to route the timebase, which is available for your E-series board. Instead of using the 10 MHz Ref Clock, which is available with M-Series Boards only, you should use the 20 MHz Timebase Clock.

The problem is 20 MHz is realy fast and you need good isolated, short cables and a good grounding connection, in order to get the clock imported by the USB LIN device. If that doesn,t work and you have the second error again (timebase disappeared), then the only chance is to use the freq out pin of your E-Series device to generate a 1 MHz pulse train. This timebase is slower and therefore less noisy. And because it is based on the 20 MHz onboard clock it synchronizes both devices as good as directly.

Hope that helps.

DirkW

0 Kudos
Message 5 of 13
(6,981 Views)
Thanks again !,

I'm a bit confused by this ,Where would the 20Mhz clock be available from on the PXI-6052E?, is it at PFI 1 like I have already wired ?
If so I have scoped that line and there is nothing there, unless that becomes active when the task is started perhaps ?, I'm not sure.
I have the 6052E user manual and it mentions this 20Mhz.
The manual says " NI PXI-6052E uses signals on the PXI backplane for the RTSI Clock. The RTSI Clock signal uses the PXI trigger<7> line for this connection. ",

Is this PFI 7 ?, if so should I be using PFI 7 and PFI 8 for my clk and trigger ?

Thanks for the help
 



0 Kudos
Message 6 of 13
(6,980 Views)
The original example routes the 10 MHz Ref Clock to PFI 1. This clock is only available on M-Series devices. You need to replace this clock with the 20MHz Timebase, because thats the Timebase available on E-Series devices. See the attached example. Let me know if that works.

DirkW
0 Kudos
Message 7 of 13
(6,973 Views)
Never mind the last posting. I checked it on my computer and it seems that E-Series devices cannot rout the 20 MHz Timebase to PFI Lines.
In this case you have to use the freq out pin to generate a MHz pulse train. Connect Freqout (PIN 1) to USB CAN CLK, DGround (PIN 35) to GRD and PFI 0 (PIN 11) to TRIG.
See the modified example.

DirkW

0 Kudos
Message 8 of 13
(6,972 Views)
Hi DirkW,

I have connected the wiring as you suggest.
I have also modified your example to send 2 LIN messages, the first wakes the board and the second activates the LED 100ms later.
The 2 messages are the same but that does not matter as my target board takes ~60ms to wake up anyway, and by then is ready for the 2nd message.
Meanwhile the 6052E is capturing in a while loop.
The vi now works with no errors but my timestamp result is not correct.

I am saving the message sent time and the LED on time and subtracting them but however it returns an activation of ~430mS if the while loop executes every 5ms and ~960 if it executes every 10ms. If the timer is removed altogether then the result jumps between 1 and 10ms.

I can see on the scope after the LIN message is sent, ( i.e the LIN bus is now inactive) there is ~1mS before the LED comes on and it is this I need to measure.
Is this too fast for my setup ?

Also another question, is the LIN timestamp created when all bits are sent or once the interface begins sending ?, as messages take ~5ms to send.

Attached is the vi

Thanks for your invaluable help.

0 Kudos
Message 9 of 13
(6,966 Views)
Hi
I had a look to your programm and the changed some issues. See the attached version for more information. The problem is mainly that you are doing a hardware synchronization, but compare LabVIEW Software timestamps. You should use your synchronized DAQ and CAN timestamp for comparison.
CAN has enabled the self reception feature and receives the frames even the frames sent to your device. Thus you can take the timestamp from the second frame sent and compare it to the DAQ Timestamp if the value reaches 1.
Hope that helps.

DirkW
0 Kudos
Message 10 of 13
(6,950 Views)