Вы отчасти правы в своих рассуждениях и у нас примерно так все и реализовано, но конкретно в Вашем случае происходит что-то другое. Плавно успеть затормозить можно все же не всегда. Если бы контроллер всегда начинал сбрасывать скорость как только "почувствовал", что скоро будет проблема связи, то мы бы получили дерганую скорость перемещения. Тем не менее, мы подумаем как сделать работу более стабильной.StavRos писал(а):Факт того, что данные перестали поступать, программа отслеживает? Наверняка. Видимо, и знает о том, в какой точно момент времени эта "авария" произошла? Тоже, наверняка. Что стоит "отмотать" историю назад и начать чуть ранее места остановки? Именно с того места, где ещё не началось "уезжание по инерции". Если абсолютно точно нельзя определить этот момент, нужно возвращаться немножко заранее назад, с запасом. Опять же, что у программы такой буфер маленький, что она мгновенно теряется, если происходит потеря связи? Нужно, значит, встроить механизм "смотрим в код намного вперёд, знаем, что будет "за несколькими поворотами впереди", читаем код из "подсмотренного" куска, при потере связи у нас есть запас хода, данные же считаны уже, вот на этом куске и тормозим". Возможно, с точки зрения программистов, я тут чушь несу, но, по-моему, всё прозрачно. Далее, что мешает при такой "аварии" не вставать "колом" с выключением питания, а просто спокойно останавливаться (с учётом реализации вышеописанного механизма), питание не обрубать, а поднять шпиндель на безопасную высоту и только тогда его остановить (повторюсь - питание с ШД не снимать!). И сразу мейл послать - хозяин, беда, беги скорее ко мне
А конкретно Вашим случаем сейчас занимается специалист, скоро ответим.
По поводу отправки сообщения я понял, придумаем что-нибудь.

