XNET Resample fails, bug? (Signal Waveform)

[mdelsol]

Hello,

I'm using:

XNET 1.7

NI-DAQmx 9.7

LabView 2011

cDAQ-9178 and module 9862, also tried cDAQ-9171 and module 9862 with same results.

I'm using the simple "CAN Signal Input Waveform.vi" to monitor some singnals from vehicle CAN bus (attached database).  When resampling at 100Hz the signal "Brake_pedal_SW" do not show any change (remains at 0 value) when the brake pedal is applied, instead "Brake_lights" signal changes normally, both signals shoud have the same value. Resampling at 1000Hz both signals remain to 0, and if I resample at 10Hz both signals seem to show the correct values. Similar behaviour happens with the other 2 channels.

Due to this behaviour I decided to record some data using "CAN Signal Input XY.vi" and plot it, everithing works fine so I don't see a reason why Signal Waveform is returning wrong values other than it is not doing well the resample.

As we have the original data from the "CAN Signal Input XY.vi" on the array control, how we can generate the same frame outputs, with the same timings to reproduce the problem?

Can any one explain that behaviour or it's a bug from the resampling?

Regards,

Marc

[mdelsol]

I forgot to attach the database...

(.xml is not a valid file type to attach... maybe could be included to be admitted files...)

[mdelsol]

I'm sad and disappointed because one week after my post and support request to NI (Reference#9023-GRQ 747) no one answered or contacted me.

After many tests I could reproduce the problem and the final conclusion is that "XNET Read (Signal Waveform).vi" doesn't work properly inside a timed loop. If you reproduce always the same data from one CAN port and read that data from another CAN port the read values are wrong and different every time. So data is not well resampled or whatever... is this a bug?

To reproduce the problem:

You need 2 NI 9862 modules, I used 2 different chassis, the cDAQ-9171 to reproduce/generate the CAN data and the cDAQ-9178 to read it.

You need to connect them properly one to each other and power them.

1. Open the vi attached call "CAN Signal Input Waveform_Timed.vi"

2. Select your input interface, database "Database_red.xml" and the 4 signals: Brake_lights, Brake_pedal_SW, Gear and Retarder_position

3. Run it to start the acquisition

4. Open the vi attached call "CAN Signal Input Waveform_Timed.vi"

5. Open the vi "Reproduce Output.vi"

6. Select your output interface

7. Run it to generate the otput

8. When vi  "Reproduce Output.vi" finishes (arround 2 minutes) stop the vi  "CAN Signal Input Waveform_Timed.vi" using the stop button.

Now you can compare the output graph with the one from my first post and see the diferences. Every time you reproduce the data the readins are diferent.

Now if you repeat the proces but using the vi call "CAN Signal Input Waveform" no timed loop used, the readings seem to be good.

Unfortunately I use timed loops in my application so it is a BIG problem !!!

See below picture of a bad readings, Brake_lights and Brake_pedal_SW signals should be equal and are different.

Hope someone can answer to this post, specially from NI to work around this.

Regards,

Marc.

[fromm8]

Hello Marc,

I was able to reproduce the behavior. I could see the difference in the Chart from both examples. More than a bug, I am thinking in a timing issue. I was using the finished late flag and I noticed that your task spends more than 100ms sometimes. For example, if the code needs 105ms to be executed, the timed structure is going to spend 105ms, but your while loop with the timing VI is going to spend 200ms. So, if this is true, there is an expected difference in their behavior. Now, I am still not sure how this is affecting the chart, but you could start analyzing the timing, and testing it.

Regards

[mdelsol]

Hello,

Thanks fromm8 for confirming that you are experiencing the same wrong behaviour.
You are right about the diferences on the execution times, but it should work any way as XNET Read (Signal Waveform).vi should take it's time to return the requested values while doesn't times out (set to 10 seconds). Maybe somthing inside the Read function is wrong and being afected by the time between calls or the number of requested values, if so from my poin of view this is a bug.
As far as I know Signal Waveform sesions use 2 buffers, one internal for it's use and another for the resampled date, the user can only resize the one for the resampled data, also could happen that the function is not managing well it's internal buffer.

If you remove the Wait Until Next ms Multiple Function and let the while loop go as fast as posible, also wrong resampled values are returned.

1st Observation:
Resample = 100 (not changed)
Time out = 10 seconds (not changed)
Number to read = 10 ---> returned values are wrong
Number to read = 5 ---> returned values are wrong
Number to read = 20 ---> Returned values look good, no errors can be apreciated only looking to the graph, further inspection should be done.

2nd Observation
Resample = 100
Time out = 0
Number to read = -1 ---> Returned values look good, no errors can be apreciated only looking to the graph, further inspection should be done.
Note: Unfortunately I can't use that method as I syncronyze the CAN data with other data and my application is designed to read 1/10 of the sample rate values. (100Hz / 10 ---> 10 values to read by iteration)

This tests was performed with only 4 signals (attached database from previous posts), my application reads 80 signals or more and I don't know how it will perform in that case, as then maybe results can be different.

Hope some one from NI gets involved into this to help us and to clarify some aspects of it. Experts and R&D people from NI where are you?

Regards,

Marc.

[JtotheB]

Hey mdelsol,

I apologize for the long time it took for an AE to reply to your service request. That was due to an unfortunate error with the system our support staff uses to assign out forum questions to engineers. In the future if you get an service request with letter characters, that is not a valid number for our notification system. I have alerted our support guys to revisit this post if you have any follow up questions, and I'll be following along as well.

Without a full log of the traffic on the bus it is impossible to tell if this is erroneous behavior or not, but it could be expected behavior for a waveform session. When XNET Read is called on a waveform session, it returns a subset of the read data. For example, lets imagine I'm receiving two different frames (C and E) from the bus into a waveform session with a sample rate of 500 Hz (once every 2 ms). Here is the example traffic.

Between when my session was configured and the first call to XNET read at 8 ms, I received those seven frames. So, in a waveform session the data I get back will be the following;

Time    C data     E data

0 ms    0,0          0,0 (default)

2 ms    1,2          0,0

4 ms    3,4          5,6

6 ms    3,4          1,2

8 ms    5,6          1,2

In our second sample time at 2 ms we've only received one C frame, so we set that value for C and return defaults for E since we haven't received an E frame yet. The third sample illustrates what might be going on here. The sample that we get at 4 ms represents all of the data received between 2 and 4 ms. In that time, we received only 1 C frame but 2 E frames. XNET will discard the earlier data and use the data from within the more recent frame for the waveform. That loss of data could be the source of the issue that you're seeing here. Increasing the resample rate can help decrease data loss and give you data closer to what you expect (as you've seen in your troubleshooting). For more details on waveforms, check out page 4-31 in the XNET manual. That goes into a little more detail about waveform sessions, and why you weren't seeing the same problem with XY sessions. Have a great day!

[mdelsol]

Hello John,

First of all accept my apologies as I was traveling and couldn't answer before.
Thanks for your try, I really appreciate it but is not a correct answer to the matter and readers can be confused and the worst thing is that people could continue using the function XNET Read (Signal Waveform) without knowing that doesn't work well.

It's a known problem on the driver working on that mode, it was known before I contacted support and wrote that post (CAR 381802) even so 3 weeks were necessary for the support guys to confirm that to me... amazing isn't it? (not necessary to mention that post) meanwhile I was hitting against a wall and wasting time.

Guys if you are using XNET Read (Signal Waveform) contact NI support for a workaround, but I do not recomend to use it as first call to XNET Read (Signal Waveform) takes arround 600-700 ms and can't be recovered... delay will remain all the time. From my point of view delay it's too big and not acceptable for my applications. I relly recomend you to use XNET Read (Signal XY) and do the resample youself. NI notified me that this CAR will not be solved at least until XNET 1.9, actual version is 1.7, that means it will take around 9 month? we will see....

Now John I'll do some quick comments regarding your answer:

- You have a full log of the trafic as we genetate it using "Reproduce Output.vi"
- Data rate for all 3 generated frames is 10 Hz, can be easily seen on the bus monitor or analyzing data inside "Reproduce Output.vi" in consequence if data is resampled at 100Hz and the driver works well never could be loss of data.
- On the example that you mentioned received data had once a rate of 1000Hz (1ms) and resampling rate is 500 Hz (2ms), then obviouly can be loss of data.

Some thoughts for readers:
When do you give kudos to the posts? interesting ones, solve problems, valuable information, avoid doing something wrong...
How many people is using signal waveform sesions without knowing the problem? in some cases is not easy to realise about it...
When a bug or problem is found (can happen) should NI inform people that bought products related to it or we have to continue hitting a wall while the problem is known?

Regards,

Marc

[mdelsol]

Hello,

Just to remember to all XNET users that NI didn't solved the problem yet.
XNET Read (Signal Waveform) has the commented bug.

Last test performed with:

XNET 1.8

NI-DAQmx 9.8

Best Regards,

Marc.