I am currently attempting to configure a PV450 to receive an ABS tooth count data on the first CAN channel once every 20 ms , carry out a simple calculation with the scripting language, and then transmit it on the 2nd CAN channel.

Currently at the moment I have been able to set this up. However due to our application the delay between the Rx and Tx of the can messages is of great importance to us. Although we are overly concerned about the length of the delay (although would be preferable if it was less than 20 ms), we are experiencing a lot of variance in the delay between Rx and Tx. We would be requiring a delay variance of ~ 50 micro seconds.

Do you this is feasible on the PV450?

Thanks in advance
Andrew

Hello Andrew,

Unfortunately because the displays do more than just CAN traffic, there is an unpredictability. The gauges and screens get updated requiring different amounts of processing, even though the screen has a low priority, it still has to be serviced.

It is possible to do some things to mitigate the difference. Simplify and reduce screens and other processing. Switching screens and moving needles will take time away from other processing.

Try doing the calculation on the outgoing variable as the On Change Event of the incoming variable. Don't use a script for the calculation.

Are you using Free Form CAN to transmit or the Transmit device? Are you using a recurring 20 ms timer or transmit when needed? It is possible to have one 10ms timer. You might try using the highest priority for the message also.

I hope something here will help. Sounds like an interesting problem.

Hi Sara, Thanks for reply.
We are using the Free Form Numeric Message.
We are using the Complete Event of the Rx to trigger the Tx.
In our test, it is found that the latency is variable between 5ms to 32ms, which seems too high for our application.
Is it possible to improve? Do you have any idea on what level the latancy can be achieved?

Could we set the priotiry for the message? I didn't find this in the manual. Wish you can give us some hints.

Hello Andrew,

Since you are using Free Form, if you are using a 29 bit identifier (J1939), the priority is the first three bits of the identifier, ie., the Frame ID in the Message Definition block. Same with the 11 bit identifier. This might help get the message on the bus faster. I don't know that it will affect variance of the latency between the receive transmit.

We haven't actually had to confront varience of latency between receive and transmit. It has been more about the variance between transmits and how can we get a message on the bus every 10ms or xxx ms. So, I don't have much information about the time between receive and transmit. It is difficult to know for sure what part of the processes of the PV450 would take more time. Do you have some big scripts running? Activity programs? If you have other CAN traffic, the display could take more time with it than other times. It probably also depends on when the incoming message is received so that it can be serviced. The message may not be serviced at the exact msec that it is received sometimes, it may need to wait for processor time.

I don't think I have provided much helpful information. Maybe there are others who have been in a similar situation who have some ideas.