Maybe 60-70 is fine.
I can’t see anything suspicious in the log, so I can’t say anything strong here.
Looks like CAN is fine, everything is fine, and maybe PWM arrived too late.
I can only guess by process time that maybe there is just not enough CPU time.
Those, though, can be caused by thermal trolling if your CB1 is capable of it.
(IDK).
In the log:
Sent 88 16269.201879 16269.201661 16: seq: 1f, queue_digital_out oid=10 clock=2455005585 on_ticks=5492334
Sent 89 16269.224301 16269.224099 14: seq: 10, tmcuart_send oid=0 write=b'\xea\x03\xe8\xad\xe1' read=10
Sent 90 16269.230329 16269.230127 14: seq: 11, tmcuart_send oid=0 write=b'\xea\x03( \xc3' read=10
Sent 91 16269.910387 16269.910296 6: seq: 12, get_clock
Sent 92 16270.102014 16270.101796 16: seq: 13, queue_digital_out oid=10 clock=2512605646 on_ticks=5824098
Sent 93 16270.303933 16270.303723 15: seq: 14, queue_digital_out oid=6 clock=2515118106 on_ticks=371200
Sent 94 16270.304440 16270.304230 15: seq: 15, queue_digital_out oid=7 clock=2515118106 on_ticks=371200
Sent 95 16270.305853 16270.304969 64: seq: 16, set_next_step_dir oid=5 dir=1, queue_step oid=5 interval=58121126 count=1 add=0, queue_step oid=5 interval=201963 count=1 add=0, queue_step oid=5 interval=108725 count=2 add=-23959, queue_step oid=5 interval=68568 count=4 add=-6294, queue_step oid=5 interval=46149 count=7 add=-1795, queue_step oid=5 interval=35689 count=9 add=-577, queue_step oid=5 interval=31245 count=26 add=80
Receive: 92 16269.149599 16269.122279 15: seq: 1f, analog_in_state oid=9 next_clock=2454493442 value=14881
Receive: 93 16269.228508 16269.224301 18: seq: 11, tmcuart_response oid=0 read=b'\n\xfa\xef-\x808\x02\x08 \xbb'
Receive: 94 16269.234496 16269.230329 18: seq: 12, tmcuart_response oid=0 read=b'\n\xfa/ \x80\x00\x02\x08\xa0\x89'
Receive: 95 16269.449618 16269.230329 15: seq: 12, analog_in_state oid=9 next_clock=2473693442 value=14881
Receive: 96 16269.749658 16269.230329 15: seq: 12, analog_in_state oid=9 next_clock=2492893442 value=14878
Receive: 97 16269.910932 16269.910387 11: seq: 13, clock clock=2484461168
Receive: 98 16270.049619 16269.910387 15: seq: 13, analog_in_state oid=9 next_clock=2512093442 value=14877
Receive: 99 16270.308111 16270.305853 12: seq: 17, shutdown clock=2509832400 static_string_id=Timer too close
Like get_clock got response.
After that, you see TTC, so the next command will probably add a timer, which will be too late.
shutdown clock is less than all of the queue_digital_out commands, which confuses me a little.
We know that ebb runs at 64000000, so 2512605646-2509832400 = 2773246 and 2773246/64_000_000 = 0.043s which is pretty close (AFAIK, it should be closer to +150ms).
But technically, it should not cause TTC, because, according to the shutdown clock (2509832400), it happens before they should be scheduled (2512605646). According to the seq 17 they are received - 17 > 13, 14 and 15.
Either way, I suggest you pull the latest changes and maybe reflash the main mcu.
One of the patches may slightly reduce CPU load by GC changes, while other patches may optimize the USB CAN bridge.
Also, you may want to upgrade your system to Python 3.11, it should be just a little faster in everything, which I hope will help farther reduce your CPU load in the end.
Hope it helps.
