Questions about cyclic messages using the Worker class.

[LudovicC]

Hello,

I am developing a C# wrapper to the worker class to be able to collect data (with DeQueue) and send cyclic message (with broadcast) or single message (with transmit).
I have to make an easy-to-use library which can be used in software like TestStand.
So far, the stability of the cyclic messages looks quite good. I would say +/-3ms whatever the cyclic rate is. I have tested several hours with 10 messages simultaneously with a cyclic rate from 10ms to 1000ms.

I would like to ask to the experienced users, how stable are the cyclic messages when testing during days with a lot of messages (such as 50 or even 100 messages)? I can see that the maximum amount of cyclic message possible is 100.
I guess that if a lot of "Transmit" would be called, it could impact the stability of the cyclic messages, but in my previous question you can consider that "Transmit" is not being used (or only few messages per seconds).
And, if the PC has a big lag, could it impact this cyclic rate? Or this broadcast happens in "embedded" within the PCAN device (such as PCAN-USB Pro)?

Also, is it possible to have dynamic data in the broadcast? Specifically, I would like to support some CAN messages with alive counter and checksum within the CAN data (other data would be fixed).
I can only find the method "UpdateBroadcast" but I don't think it's really suitable for modifying the CAN message content manually between each time that the CAN message is sent.
Especially my main script would not know when a specific CAN message has already been sent by the Worker class... Except if there is a way to send an event every time a specific CAN message inside the broadcast is sent out?
Then I could catch the event, and update the alive counter and checksum bytes with "UpdateBroadcast" before the next cycle of the CAN message. I guess that could work even for a CAN message with 10ms scheduling.

Alternatively, I could make my own cyclic message when I need this dynamic data, using "System.Timer" and the method "Transmit", but I have already tested and the cyclic rate is not very stable for a 10ms scheduling when using System.Timer...

I am of course open to any other suggestions .

[K.Wagner]

Hello,

So far, the stability of the cyclic messages looks quite good. I would say +/-3ms whatever the cyclic rate is.

Not sure if this measurement is correct. Actually, the library has a very small jitter (+/- 1ms). I have attached a video here where I send one message each 10ms. Ich i do the same with 3ms, for example, the behavior is the same.

I can see that the maximum amount of cyclic message possible is 100.

Yes, this is a limitation within the API.

And, if the PC has a big lag, could it impact this cyclic rate? Or this broadcast happens in "embedded" within the PCAN device (such as PCAN-USB Pro)?

If you have problems in your PC, then you could have also problem when sending. The messages are written directly after calling Transmit (internally a PCAN-Basic call to CAN_Write). The messages are passed to the device driver which tries to send the message as soon as possible. If the call to CAN_Write is delayed, then the message goes out also delayed.

Also, is it possible to have dynamic data in the broadcast? Specifically, I would like to support some CAN messages with alive counter and checksum within the CAN data (other data would be fixed).

No, there are no "smart messages" implemented. But it is a good idea, that we can consider for future releases.

I can only find the method "UpdateBroadcast" but I don't think it's really suitable for modifying the CAN message content manually between each time that the CAN message is sent.

You do not need to use always the UpdateBroadcast method. The broadcast does exist as an object. Having this you can directly modify its data. When the time comes to send the message again, the updated data is taken. Nevertheless, you still do not known of course, when the last was sent.

Especially my main script would not know when a specific CAN message has already been sent by the Worker class... Except if there is a way to send an event every time a specific CAN message inside the broadcast is sent out?

This is not supported, and actually it would be quite overkill if you have 100 messages sending each 1ms and triggering an event. NEvertheless, we will check the possibility to have an event triggered, when a broadcast was written.

Alternatively, I could make my own cyclic message when I need this dynamic data, using "System.Timer" and the method "Transmit", but I have already tested and the cyclic rate is not very stable for a 10ms scheduling when using System.Timer...

System.Timer is based on the Windows timer, which has a resolution of ~16ms. For this reason we have created a performance-counter-based timer, which has a resolution of 1ms. We deliver this together with the same PCANBasic.NET assembly. Check the documentation of the PerformanceTimer Class for more infromation.

[LudovicC]

Thank you Keneth for your detailed feedback!

Not sure if this measurement is correct. Actually, the library has a very small jitter (+/- 1ms). I have attached a video here where I send one message each 10ms. Ich i do the same with 3ms, for example, the behavior is the same.

Yes, actually I was looking at the time between two consecutive messages, and only with millisecond resolution. So for example with a 10ms scheduling message, if message (n) has a jitter of +1.3ms, and the message (n+1) has a jitter of -1.3ms, then my test would return 7ms time spent between both messages (7.4ms rounded down) instead of expected 10ms.
Hence the +/-3ms of my initial message (which was not really about jitter). But it seems to be in line with the +/-1ms jitter that you mention.

System.Timer is based on the Windows timer, which has a resolution of ~16ms. For this reason we have created a performance-counter-based timer, which has a resolution of 1ms. We deliver this together with the same PCANBasic.NET assembly. Check the documentation of the PerformanceTimer Class for more infromation.

Thanks for this tip, I have been testing the last few days, and this "PerformanceTimer" accuracy is very good. I can successfully sends dynamic data "manually" using this "PerformanceTimer" and the "Transmit" function.
Is the "Broadcast" function also based on this "PerformanceTimer"?
There is actually a drawback when using the worker class with "Broadcast". I cannot manually log all messages into a .txt file, and there doesn't seem to have a ready-to-use trace function from the worker class.
Indeed, I can log all RX messages and all TX messages which i am sending with "Transmit". But I don't really have "access" to the messages sent out with "Broadcast" to be able to log them...

I am thinking of using the basic API which can handle Trace (with "SetValue" and "TPCANParameter.PCAN_TRACE_LOCATION"), and sending manually the cyclic message with the "PerformanceTimer" and the "Write" function.
Do you think it would work? Is the "Write" function from the basic API as efficient/fast as the "Transmit" function of the worker class?
But I don't know how the PC would behave if 100 PerformanceTimer would run in the background (in the example of 100 cyclic messages) compare to the broadcast of the worker class.

[K.Wagner]

Hello,

Is the "Broadcast" function also based on this "PerformanceTimer"?

Yes

There is actually a drawback when using the worker class with "Broadcast". I cannot manually log all messages into a .txt file, and there doesn't seem to have a ready-to-use trace function from the worker class.

There are indeed several properties that were not mapped directly within the Worker class, just because you can set those easily with an Api.SetValue call.

I am thinking of using the basic API which can handle Trace (with "SetValue" and "TPCANParameter.PCAN_TRACE_LOCATION"), and sending manually the cyclic message with the "PerformanceTimer" and the "Write" function.

You can keep using the Worker class and then call Api.SetValue(TPCANParameter.PCAN_TRACE_STATUS) with the same handle connected by the Worker. This will generate a trace file with all sent and written messages (also those generated by a broadcast).