Первое - совершенно не страшно.
Следствие того что в шаблоне есть запись в регистр нулевого значения.
А вот второе - указывает косвенно на неверно распределенные времена (таймеры) опросов в настройках. То есть регистры с выбранной скоростью опроса на текущей скорости шины опрошены быть не могут, не помещается опрос в тайминг. Надо пересчитать проектный план опроса или поднять времена.
На контроллере работает tailscale, nodered. Да, может не уложится в отведенное время Про это есть, кстати, исправления в актуальном testing и будут в релизе.
Соответствующие сервисы не установлены - поэтому и файлов нет.
А попробуйте несколько раз выполнить - сколько времени займет?
Подскажите где об этом поподробнее почитать. Этот проект совсем маленький, сейчас скорость шины 1 и 2 9600, устройств на шине 1: MDM-3=1, MR6C=2, MR6CU=1; на шине 2 MSW-3=2. Можно сказать совсем очень мало … В настройках все времена (таймеры) опросов по умолчанию. Если поднять скорость шины до 115200 - поможет?
Количество устройств - тут не особо важно. Гораздо важнее количество опрашиваемых регистров.
Один из шагов, важных, при проектировании шины - это определить как часто нужно читать регистры и их количество.
Если (для 9600 расчетное количество чтений в секунду 25-60) превышает ширину шины - то либо читать реже либо уменьшать количество либо увеличивать скорость.
На аналогичном контроллере но без стороннего ПО занимает:
time systemctl list-unit-files --all --output=json
[{"unit_file":"mnt-sdcard.automount","state":"generated","vendor_preset":null},{"unit_file":"proc-sys-fs-binfmt_misc.automount","state":"static","vendor_preset":null},{"unit_file":"-.mount","state":"generated","vendor_preset":null},{"unit_file":"dev-hugepages.mount","state":"static","vendor_preset":null},{"unit_file":"dev-mqueue.mount","st>
real 0m11.148s
user 0m0.023s
sys 0m0.046s
А насколько заняты ресурсы, CPU например в момент выполнения команды?