It is a representation of how much of your hardware’s dedicated resources are being used to process through all the RapidCode objects at the sample rate. This might be useful to let you know if you need to consider an upgrade. This can be accessed using MotionController.ProcessorUsageGet().
We take the foreground execution time and divide it by the target sample rate.
- We cap the return at 100%.
- We have a Frame Send and Receive Sleep which should act as a floor for the returned value. (See Below)
- The sample rate heavily influences this.
- The number of Axes and other processed rapidcode objects will increase processor usage.
If you are constantly seeing 40%+ to 80%+, it is likely that you are using a sample rate of 2 kHz or 4kHz respectively. The Frame Send and Receive sleep we use defaults 200 microseconds. This can be adjusted if desired to better reflect your system’s performance.
We picked a general value that works for many systems. We determined that most system should complete this within ~175us. When selecting a value, you want to put something that is a factor of the INtime Kernel Clock Rate (50 us if you are configured correctly). You may use INScope (an INtime utility) to measure the time between the EcatCyclic and RxTask Semaphores. Round up to the nearest factor of 50 (150, 200, 250, etc). You can set this value using MotionController.MemorySet using the address from MotionController.AddressGet(RSIControllerAddressTypeFRAME_SEND_RECEIVE_MICROSECOND).
Setting a value to less than the time it takes to get the RxTask Semaphore will end badly. Don’t do it.