Hello,

Using a PV780 display, I receive a J1939-variable beeing sent out from its source cyclically every 100 ms. There is a script which should process this variable every 100 ms.

As far as I know the J1939-variable-has-changed-event is fired only if the variable value has changed between two messages. If the same value is received twice no event is fired. In my case this leads to problems as the script (for accuracy) needs a value every 100 ms, even if it is the same as in the messages before.

Using a 100 ms timer to call the script and reading out the variable leads to inaccuracies.

How can I manage to get the script called every 100 ms, on the one side with the message-has-changed-event, and alternatively with a 100 ms synchronicity, if the event isn't fired from time to time?

All suggestions are welcome.

Thank you and regards

Hello Toni27,

What kind of inacurracy are you concerned about? It seems to me the worst that it could be is 99 msec out of date. If it is for a display gauge, the user isn't going to be able to tell the difference.

Is this is a J1939 parameter that is being received? or is it a proprietary PGN/parameter?

What depends on the parameter in question? Is there an event or a calculation of some kind or a gauge?

Hi Sara,

The non propietary J1939 message I have to process contains as parameter a rotational speed of a shaft. Using this speed I can calculate a covered distance of a special machine. Therefore it is important to get every single value to add it up.

When posting first, I thought there might be a simple trick to sync on a CAN message which is not firing a change event.

I don't know exactly why or what was wrong, but at a previous application, when trying to get a value with a timer every 100 ms and regardless of the incoming messages, the calculated covered distance was every time different to real test distance.

Now, I solved the problem using an incoming message to trigger a timer. If the next expected J1939 message has a different value, the timer is reseted by the variable-has-changed-event and the new value is used. If the next expected J1939 message has the same value as the previous and does not fire the variable-has-changed-event, the timer continues to count and after a bit more than 100 ms the last value is used to sum up the distance - this is until the next message triggers the timer again.

This seems to works pretty good. The first tests on the fast are showing a reproducible accuracy with an error less then 1 m at a test distance of exactly 2 km. So this is much more precise than standard GPS and I dont need to use a further sensor to measure a travelled distance.

Best regards,
toni27