CRIO CAN 9853 same data issue

[drogne]

Hello, this is my first post and I need some help.

I am reading data from a fifo into RT from a 9853. I change the data on the bus and the fifo gets more items with the same old value.

There is one thing that I have seen that does not seem right other than what was stated above. It does not appear that the FIFO is working properly or something because it's defined as 511 elements and you would think going into the debugger it would grow to over that size but it seems to be limited to 24.

This may or may not have something to to with the first problem.

I was not having this problem, except all the usual crashes and buggyness of LV, RT and FPGA software until I upgraded to crio 2.4.0.

Any ideas on what to look for?

Thanks a lot in advance.

PS It also seems like it comes and goes, but currently it totally gone. I though about termination, but I don't see a problem with that.

-Dustin

[drogne]

I wanted to point out one other odd thing that I see with respect to this problem.

The data will update in the IO node and the FIFO if I cycle the TRANSMITTER on then off. It will update once until I cycle the port on and off.

Thanks,
-Dustin

[DirkW]

Hi Dustin,

The CAN I/O node has a timeouty for waiting on a frame to arrive. This timeout is typically 10 seconds. When this timeout happens the node executes and receives an empty frame. You have to take care to handle these timeouts by using a case for the timeout error and one case for a regular frame. See the examples for details.

If this is not the reason for your problem, please post your code, so i could have a look to it.

[drogne]

Hello Dirk, attached should be, not all but most of the code I am using.

Any pointers on upgrading it to be more robust or even to get it working would be appreciated.

I have seen the case where all 0's come in and that is should be getting thrown out.
I also read a post about a half frame that comes in at the end, I should be handling that properly.
I had code in the RT side to read the pink node cluser from the FPGA and I could clearly see that the timestamp was changing when messages were being sent (i.e. can plugged in) but the data bytes will hang with the old values like described before. So I don't think any of the processing really matters because the data is wrong at the start.

Thanks,
Dustin

[DirkW]

Hi,

I would need to see your FPGA VI to make any suggestions. Your RT VI is far to complex and has to many missing parts to debug it. I hope you wrote this code and understand how it works, because you have to debug it.

I would start with isolating the CAN part into a single VI, so you can debug the CAN traffic more effective. Then try to send a FRAME you know with a rate you know and debug the data flow within your RT environment.

DirkW

[drogne]

Dirk, one of the most important things to keep in mind is that EVEN the FPGA CAN cluster is showing the same/repeated data, so the FIFO and 99.99% of the code should not be the problem.

That being said are there any recommendations.

Thanks
Dustin

[DirkW]

I agree if the data really changes in your frames and you receive the same data all the time, there is something wrong. But since the module and the driver are running ok with other customers, i would suspect your setup or FPGA code to be the problem.

Does the ID and number of bytes indicator show the correct values? Have you checked the baud rate to be the same with the transmitter? Did you know that the second port needs external power in order to work at all?

DirkW

[drogne]

After messing around with it and getting nowhere, I tried Port 1, and it started to work for a few minutes then quit.
So then I decided that it must be bad hardware. So I opened it up to see if there were any glaring issues and I found what look like to be manufacturing defects. See photo.

I ordered a new board and it's currently working like it should.

But this brings up another question. There does not appear to be any examples of how to synchronize can data with other data such as analog inputs.

I know there is a timestamp, and theoretically I could somehow match timestamps on the fly, but there has to be a better way.

Thanks

Dustin

[O_Proulx]

Hello Dustin,

Can you give more details as to what exactly you want to see after synchronization?  There are a few ways I interpret synchronization in this case:

1.  You want to timestamp both your analog outputs as well as your  CAN frames to know the time difference between analog outputs and CAN transmission.  For example, if a CAN Frame is received at time 0, you want to know how many seconds later was an analog output sent?

2.  You want to send a CAN Frame at the same time (synchronized) as an analog output.

3.  You want to update the analog output value every time a CAN Frame is received.

Can you please let me know which of these you want to accomplish, or expand a little bit more on exactly what you are looking to do.

Have a great day.

[drogne]

O. Proulx,

My application is just a 50+ channel data logger, so it mainly deals with timestamping Analog Data with CAN data.
I did see an example Called 9853 SYNC_CAN and it appears to create a timestamp based of each CAN frame.

It's not exactly clear to me how this would be used, though.

For example let's say that I am reading Engine RPM via an analog input and CAN message that is at an Update Rate of 50ms
I would like to see them at the same value in time.

I think where it get's tricky, is that I have over 50 hardware channels of data and I would like to collect at 5kz.
(Speed and FPGA size seem to be causing issues)

Thanks,
Dustin