Easyelectronics.ru

Здравствуйте! Есть система команд устройством с адресом 1, каждая команда это последовательность Аски ii символов , у каждой допустимой команды есть начальный символ , адрес, тело несколько символов и конечный символ, возможны как ответы на правильную команду так и на неправильную. Вопрос как должно и должно ли вообще ответить устройство если совпадает начальный символ команды, адрес, но не совпадает длина команды- как на не неправильную команду или вообще никак(т.е. считать, что адресована не ему)?и должно ли отвечать, если адрес не совпадает(думаю не должно)?

Это вопрос вообще о принципе, с каким-то гипотетическим конструируемым устройством, или же устройство конкретное и готовое?
Если вопрос о гипотетической разработке нового устройства, то конечно - если нет полного совпадения вплоть до каждой буквы, значит, команда пришла неверная. Её можно либо полностью игнорировать, либо отправить в ответ сообщение типа #{адрес_устройства}*BAD COMMAND*<CR><LF>, что более правильно с точки зрения ответной реакции и обнаружения ошибок. То есть, почему это вдруг длина команды не верная? Не хватает параметров в команде, неправильно она сформирована? И почему это произошло? Но мало просто отправить сообщение об ошибке. Надо же как то исправить ошибку на передающей стороне. Надо повторно сформировать команду, проверив ее правильность. Тут тоже как бы не следует шибко то очеловечивать тупой железный МК, он же не в состоянии совершать человеческие ошибки типа "ай, блин, отвлекся, проехал нужный поворот".
Хотя, ответное сообщение BAD COMMAND является полезным для интерфейса терминалки, когда сам человек может текстом передавать комманды.

Когда не совпадает адрес, отвечать конечно ничего не нужно. Пусть ответит тот, чей адрес был передан в команде.
Так же, в том случае, когда любые команды, в том числе и ошибочные, предполагают ответы при совпадении адреса, то таким образом получаем еще одну возможность: если в течение интервала времени не пришел ни один ответ, значит можно на передающем устройстве сформировать оповещение "Такого адреса в сети не существует".

Возможно это стандартный Modbus ASCII, почитайте о нем...

Устройство не готовое, вопрос о принципе как это правильно делают, спасибо, вроде пока понятно

Оконечное устройство, не распознавшее адресованную ему команду, просто отправляет '?' <cr> в ASCII. Так, например, определено в протоколе многих проекторов (Sanyo в частности). Если адрес не совпадает, ответ не отправляется.

Я обычно использую фреймы ошибок с кодами, соответствующими:
UndefinedHeader - нет такой функции.
WrongDataLength - длина фрейма данных не соответствует ожидаемой.
WrongDataFormat - какая-то общая проблема при анализе фрейма данных.
WrongArgsTotal - количество аргументов неверное.
WrongArgsData - формат верный, но данные вне диапазона, или не совпадают по ожидаемому типу.
Ok - Все в порядке.
и т.д.
(Состав ошибок может быть разным в зависимости от задачи и протокола. Тут же ошибки связанные с природой изделия (их можно обрабатывать автоматически)).

Фрейм возврата имеет вид статус-данные. Это общий вид и для ошибки и для коректного ответа. Это позволяет при необходимости конкретизировать ошибку. На практике, правда, это обычно не нужно. Просто вывода ошибки достаточно для диагностики.

Диагностировать возвращенный код ошибки проще, чем пытаться разобраться, почему изделие молча проигнорировало команду.
Здесь, правда, есть техническое противоречие. Возврат ошибки требует синхронного взаимодействия запрос-ответ. Клиенту приходится ждать фазу прямой-обратной передачи. Это сильно замедляет работу. Безответный вариант значительно быстрее.

Я пришел к выводу, что на ответственных, связанных с возможными неисправностями применениях, всегда стоит использовать формат запрос-ответ.
Это позволяет вовремя остановить поток команд, что помогает не допустить аварии.