Я так понимаю, что диаграмма затормозится на это время лишь в случае отработки этих задержек.

Нет, это не так.
Каждый блок, добавляемый на диаграмму, увеличивает продолжительность одного цикла исполнения диаграммы на некоторую, условно фиксированную величину, порядка 30-50 микросекунд, в зависимости от типа блока и больше ни от чего. Условно говоря, все блоки на диаграмме исполняются параллельно, не задерживая друг друга.

Оптимизировать звук пожалуй не буду. Ваш алгоритм не проще....

А вот про затормаживание работы диаграммы вопрос был в задержках 1500мс, 200мс и т.п.
Я так понимаю, что диаграмма затормозится на это время лишь в случае отработки этих задержек.

Сделал практически законченную диаграмму. Прошу оценить.

Особых замечаний нет. Но. В диаграмме работа идет только с положительными значениями температуры, ее знак нигде не проверяется. Знак может быть у каждой температуры свой, но нигде не проверяется кому он принадлежит... отдельно сохраняются только целые части значений температуры. Но он (знак) выводится в UART.

Режим сна сделан правильно. Просыпаться будет. Но запрет сна по наличию принятых данных CAN тут не нужен. Активность задействованных интерфейсов уже содержится в соответствующем регистре (подробнее см. wiki)
Дополнительный вход запрета сна может использоваться для того, чтобы не разрешить контроллеру уйти в сон при выполнении критических частей пользовательского алгоритма, например, чтобы он не уснул когда воспроизводится звуковой сигнал и т.п.

Добавление любых новых блоков немного удлиняет цикл выполнения диаграммы. В данном случае на диаграмме блоков не много, сколько-нибудь чувствительного замедления работы диаграммы это не вызовет (подробнее см. wiki).

Оптимизировать можно, но возможно что этого не требуется. Вариант альтернативного решения во вложении качестве примера того, что есть и другие подходы.

Правильно ли выполнен режим сна?  Сон просто по неактивности CAN. Будет ли просыпаться?

Изменил формироватьель для UART. На отладочной плате всё выводит правильно.

Добавил большой блок с формирователем звуковых предупреждений на пьезоизлучателе. Подключен к выходу 7.

Не будет ли он тормозить всю схему, если нет предпосылок для сработок?

И мне не нравится его огромный вид. Как оптимизировать? Если можно.

Нарисовал близкую к финальной диаграмму.  Прошу оценить.

В общем, ошибок не обнаружено, все должно корректно работать.
Нет смысла находить среднее арифметическое показаний скорости, достаточно использовать какое-либо одно показание, т.к. разница между ними не превышает 0,5км/ч, что не является принципиальным - погрешность показаний спидометра больше (графики скоростей по разным показаниям во вложении).

На практике, когда CAN не спит, нет особого смысла переводить контроллер в спящий режим, т.к. его потребление на фоне остальных устройств и систем незначительно.
Организовать такое решение на CANNY7 возможно, но задача достаточно нетривиальная: требовалось бы менять конфигурацию драйвера CAN, что в свою очередь влечет автоматическую перезагрузку контроллера.
Нужно исходить из целесообразности данного решения. Возможно просто следует использовать управляющий сигнал с входа №2 для активации работы алгоритма, а в сон уходить при отсутствии активности CAN - когда и автомобиль спит.

Находясь в режиме пониженного энергопотребления контроллер периодически просыпается на 1 проход диаграммы. Это можно использовать для моргания красным светодиодом (вариант решения - см.вложение: используя особенности режима сна, светодиод будет включаться 1 раз в 2 секунды на 1 секунду).
Также следует подумать о целесообразности применения такой индикации. Можно индицировать рабочий режим, а в режиме сна - выключать светодиод вообще.
Более подробная информация о режиме сна доступна в Wiki.

Это делается аналогично выводу строки с температурой датчиков. Нужно определиться с форматом строки вывода (что должно выводиться и в каком виде), помня при этом что на один проход диаграммы в UART может быть отправлено не более 16 байт. Можно отправлять и более длинные строки, но за несколько проходов диаграммы.

Часть которая взаимодействует с CANом - проверена, и работает. (ещё раз спасибо за ID speed & rpm)
Часть формирователь для RS232 - работает.
Часть с термометрами - не проверял.

Есть три вопроса:
1. Как организовать спящий режим при отсутствии, и пробуждение при наличии +5в (лог.1) на входе 2 ?
     При том, что по CAN есть непрерывный обмен.
2. Как организовать в спящем режиме периодическое моргание красного светодиода (например 1 раз в несколько секунд)
3. Как организовать оптимальней выдачу в строку через UART информации о включении/выключении насоса/вентиллятора например символом "*", или строкой "ON" ?

Математику прогонял в симуляторе. Конечные значения выдаёт корректные.

Смысл сего действа: Под id 010C выдаётся значение в виде двух байтов (A и B) соответственно. Их требуется обработать по формуле ((A*256)+B)/4. Результатом будут обороты. (И это подтверждено практикой на другом оборудовании)

Вот я и сгородил "формулу". Сначала выделяем байты, потом считаем. Хотя промежуточный итог - озадачивает )

http://elm-scanner.ru/obd-2/obd-pids   информация для примера.

Из регистра чтения CAN D7:D6 в именованную сеть "RPM_Word" передается 16-битное (двухбайтовое) числовое значение (0х0000...0хFFFF=0...65535), с которым можно сразу работать как с числом.
Из него, при необходимости, можно выделить отдельные байты, но в данном случае достаточно просто выполнить деление на 4 (либо сдвиг вправо на 2) чтобы получить требуемый результат.

А назначение на клавиши ПК было-бы в некоторых случаях гораздо удобней. (как кто-то писал на форуме)

Или я чего-то недопонял?

В режиме симулятора, можно принудительно изменить значение любой сети через контекстное меню, доступное по нажатию на ней правой кнопки мыши: http://wiki.canny.ru/index.php?title=%D … 0.B8.D0.B9

Плохо, что нет никаких  "тумблерров" служебных отладочных чтобы менять входные параметры в процессе выполнения программы.
Полупроверка получается.
Приходится выходить из симулятора, менять параметр и смотреть дальше

Или я чего-то недопонял?

Смысл сего действа: Под id 010C выдаётся значение в виде двух байтов (A и B) соответственно. Их требуется обработать по формуле ((A*256)+B)/4. Результатом будут обороты. (И это подтверждено практикой на другом оборудовании)

Вот я и сгородил "формулу". Сначала выделяем байты, потом считаем. Хотя промежуточный итог - озадачивает )

http://elm-scanner.ru/obd-2/obd-pids   информация для примера.

Вопросы:
работоспособность...

Внешне диаграмма выглядит вполне работоспособной. Явных ошибок не обнаружено, все хорошо структурировано.
Не дожидаясь получения контроллера можете проверить работоспособность диаграммы и отладить ее в симуляторе CannyLab.

Способ подключения CANNY7 к ПК показан, например, тут: http://forum.canny.ru/viewtopic.php?id=46
Может потребоваться переходник COM->USB.

Нужно запрограммировать CANNY7 для работы в качестве CAN-монитора (см. http://wiki.canny.ru/index.php?title=CA … N)_monitor, снять LOG с автомобиля в разных режимах его работы и провести анализ полученных данных.

В математике для RPM выходное значение блока №51 (Сложение) равно значению сети RPM_Word. Какое именно преобразование требовалось сделать? Проверьте работу этого фрагмента в симуляторе.

В Формирователе для UART регистр установки сообщения UART1 D3:D2 должен быть, как в примере, откуда взято решение, равен " :" (пробел и двоеточие), в представленном варианте на месте D3 - непечатный символ '/0'. Но это не критично.