Sending cycling message over the CAN

[oukai]

Dear Hooovahh,

Thanks very much.

Could you give me a xx.Vi example of USB-8052 application.

I don't think my database has any problem. But I still can't communicate with the objective system.

Or could you help me debug the problem.

I upload my program to the message board.

Thanks again.

Kai

[Hooovahh]

Is an error generated?  What traffic do you see?  Start small and build it up.  Nothing obvious jumps out at me other than the fact that I don't think you need to specify PS5_Settings_Mux every time, I think it just needs to be added to the list of signals once but I don't have the hardware to test this with.

[JefeL]

I am able to run your VI against the XNET bus monitor and it appears to work exactly as designed. The three "PS5" frames are all transmitted and received with the appropriate signal data. The PS5_StartRequest frame is transmitted properly at 0.5 second intervals.

One thing that concerns me is the lack of any timing on your loop. Both the PS5_Commands and PS5_Settings frames are event frames with a transmit time of zero. Without any timing elements to control the loop rate, these will execute as fast as possible and as a result push the bus load to 100%. This will prevent any other node on the bus from transmitting a frame with a higher arbitration ID.

Can you tell us what you are expecting to see? What is the application supposed to do?

[oukai]

Hello Hooovahh,

Thanks for your reply.

There is no any error when I run the program.

But the connected system shows losing the CAN signal.

I am really confused the programming.

I upload the file of CAN information. 

Could you read it if you have time.

It may help you understand better of my problem.

I am really appreciated to your help.

Kai

[oukai]

Dear Jeff L,

Thanks for your reply message.

I am also able to run the VI program without any error indication.

But the interfaced system still can not get the signal from the USB-8502.

Maybe your comment is right. Could you tell me how I can set the timing elements to the control loop rate.

The problem I meet is stated as following;

We have a fuel cell system with external CAN controller.

We  want to monitor the system in real time. So we choose the remote control mode to transmit messages and receive messages using external controller. In the local system, we have choose Remote control model already. But the system can not detect the external can signal from the USB 8502. I still can not find out the problem yet.

I have spent lots of time to solve it but failure. 

Your kindly help is important to me to kill the problem.

Thanks again.

Best regards,

Kai

[JefeL]

The manual indicates that the responses from the DUT do in fact have higher arbitration IDs so we are likely blocking any output as I mentioned. It could be that the DUT realizes it isn't able to transmit any data and decides communications has been lost. Let's start by adding a 500 ms wait in your loop to bring the bus usage down and allow your DUT to transmit data.

We have confirmed with the bus monitor that the PS5_EnableAutoStart signal is transmitting cyclically as we would expect so it is unlikely the watchdog associated with this signal is triggering any problems at this time. If adding a wait to the loop help alleviate the lost communication error we can discuss more complex architectures for your application that split the watchdog signal out from the command signals.

[oukai]

Hello, Jeff 

The problem I solved.

It is not a matter of time loop.

After creating a database, I set a termination in Xnet session. Then the problem solved

Thanks for your help

Kai

[oukai]

Hello Hooovahh,

Good day.

Finally, I solve the problem by adding a termination in Xnet session when I create the database.

Thanks for your help.

Kai

[Minions]

One key to note that when communicating across CAN is that it expects a 120-ohm termination to avoid signal reflections.  The cabling you are using should ideally be low capacitance 120-ohm matched impedance cable as well.  Standard wiring may work over shorter distances, but will have rounded edges that may cause invalid hi/lo values that generate errors or use up precious time with fault-tolerant retries during cyclic readings.