Первый абзац раздела 2.2:
"… причем нелинейность САУ может определяться различным причинами" — различнымИ
После «Разложим левую часть уравнения (2.2.2) в ряд Тейлора в малой окрестности точки равновесного состояния» вторые скобки с заключенным в них выражением лишние.
"«простое» разложение функции в ряд Тейлора в окрестности точки" записано с ошибкой. Не проставлены степени (x-x0). И не очень понятно зачем оно вообще приводится, если дальше используется формула разложения в рад Тейлора функции многих переменных, а не одной.
После «C учетом вышеприведенного разложение принимает вид:» везде должны использоваться частные производные.
(2.2.4) Из аргументов F(...) в левой части почему-то пропал последний аргумент t. Это следует пояснить. На первый взгляд формальных оснований для этого не вижу.
Что значит «В самом деле, разделив уравнение (2.2.5) на (y0, u0) и выполнив некоторые преобразования, получаем:»? (y0, u0) это что?
(2.2.7) У b0 звездочка «уехала» из верхнего индекса. И еще здесь следует добавить «Где:» и выписать формулы для коэффициентов со звездочками, как это делалось везде до и после этой формулы. Иначе очень неудобно отслеживать правильность «некоторых преобразований».
В целом, я уже начинаю уставать от обилия опечаток. Если и дальше нужно будет так продираться, то вряд ли мне захочется учиться именно по этому тексту.
Ну тогда по порядку. Статья «2. Математическое описание систем автоматического управления».
Первая же картинка (и рис. 2.1.2 тоже). Масса поршня на картинке обозначена M, а в формулах (в том числе и на этой же картинке) везде m. Кроме того, на схеме (тот же рисунок) первый входной параметр не учитывает массу. Надо бы g на нее домножить.
Не понимаю вторую строку в формуле без номера после слов «перейдем к отклонениям от стационарного состояния:» Там что, квадратные скобки заменяют взятие производной по времени? Или все же к квадратным скобкам в последних двух формулах системы следует дописать по одному штриху?
Формула без номера после «Вычитая из уравнения (2.1.3) уравнение (2.1.4), получаем уравнение динамики демпфера в отклонениях:» (перед (2.1.6)) в левой части затесался лишний множитель g.
(2.1.6a) после «где:» в выражении L(p)=T2^2*p+… должно быть L(p)=T2^2*p^2+…
Ниже не пронумерованная формула после «Введем новые нормированные (безразмерные) переменные:» — Потерялся штрих в правой части первого уравнения последней системы (при y~(t))
Взялся читать с первой части статьи. Конечно в комментариях к первой части были интересные предложения как сделать книгу не такой сухой (и я их в целом поддерживаю), но прекрасно понимаю что это полностью зависит от стиля автора, переделать его под рекомендации практически невозможно. В целом я привычен к старому советскому стилю изложения и он меня устраивает. Поэтому больше это обсуждать не буду. Но встречаются опечатки. Особенно много во второй части. Комментировать их там уже не могу (прошло больше 30 дней). Вас интересуют замечания такого рода или будете потом сами вычитывать и исправлять? Просто читаю для себя чтобы вспомнить предмет (статьи попались под руку в такой момент когда понадобилось освежить знания) и, по своему обыкновению, прослеживаю внимательно вывод всех формул. Где-то значок производной потеряли, где-то степень оператора, где-то коэффициент и т. д.
На мой взгляд, дополнительная проблема схемы (б) в том, что оба конденсатора должны выдерживать пиковое напряжение и при этом общая емкость составляет лишь половину емкости каждого. Т.е. проигрыш сразу вдвое и по емкости и по напряжению.
Расскажите пожалуйста какие технологии, кроме Nanoloc и UWB, рассматривались и почему они были отброшены? Выбор не велик?
И еще один вопрос, если позволите. Это дорогая технология? Только горняки могут себе позволить? Потенциально ведь опасные объекты это и стройки и цеха и даже уличное движение.
Вы Московские карты для проезда в метро видели? Они не выгорают во время грозы. Это потому, что защита от наводок делается совсем просто. Диодная сборка вроде BAT54S, крайние выводы на землю и питание, средний на сигнал. Но аналогичные диоды уже есть в микроконтроллере. Внешние могут понадобиться только если их не хватает, в чем я сомневаюсь.
Вы правы. Физическое отключение микрофона дает спокойствие. Например, на моем нетбуке камера физически закрывается шторкой и это действительно убеждает меня что камера ничего не подсматривает. Хорошее решение.
Справедливости ради замечу, что скорость перерисовки экрана вы явно занизили. Все не так плохо :) Скорость может быть гораздо больше.
Но давайте оставим оптику и посмотрим внимательнее на звук и RFID. Не настаиваю, но предлагаю рассмотреть варианты. Во-первых антенну передатчика можно подключить к звуковому разъему смартфона и получить полудуплексную связь. Стоимость аудиоджека и кусочка провода копеечная. Можно прилагать к каждому устройству.
А во-вторых почему бы не отказаться от микрофона или антенны вообще и соединять аудиовыход смартфона с устройством напрямую обычным аудиокабелем? Хотите чтобы пользователю не нужно было ничего искать? Припаяйте провод 10 см к устройству, а на другой конец аудиоразъем и сложите в нишу корпуса. Предсказуемое качество канала, не нужна тишина на время прошивки и т. д. Как следствие, намного бОльшая скорость. А звуковой сигнал, как вы гениально предложили, генерируется скриптом с веб-страницы.
Кроме того, хочу обратить внимание насколько важна обратная связь. Пока у вас производится одно устройство проблемы не заметите. Но появится другое и пользователи тут же начнут заходить на неправильную веб-страницу и пытаться запрограммировать устройство не предназначенными для него настройками. Конечно устройство отвергнет такую попытку, но отреагирует мигающим светодиодом т. к. не сможет отличить такую ситуацию от ошибки передачи. А пользователь после трех попыток будет уже сильно нервничать и не понимать что происходит. Лучше бы сразу закладывать возможность опроса устройства на предмет его модели, а еще лучше на скачивание всех текущих настроек и отражать их на в форме веб-страницы в качестве исходных.
Понятно что вы ищете и технически решение приемлемое. Спасибо за статью. Но хочу обратить внимание на не технический вопрос. Вам комфортно было бы жить в доме, где каждое устройство от розетки до выключателя и от лампочки до микроволновки обладают микрофоном и связью с внешним миром одновременно? Все они от разных производителей из разных стран и с закрытым кодом. Вот я упомянутую выше кнопку от Амазона не хотел бы иметь дома т. к. от этого бренда в первую очередь можно ожидать нововведений типа целевой рекламы по ключевым словам, прозвучавшим в помещении. Не говоря уже о других способах использования аудиоинформации, которые вы легко можете себе представить. И даже если не злобные производители, то всегда есть злобные хакеры. Конкретно вы можете решить свои задачи и через аудио, но массовым явлением это не станет никогда. Надеюсь.
Стараюсь придерживаться правила «критикуешь — предлагай». Первый вариант: Гораздо меньше опасений вызывает передача световых сигналов. Используйте мигание экрана смартфона и фототранзистор в 5 мм корпусе (чтобы встроенная линза собирала побольше света) на устройстве. Такое решение вроде уже применялось. Обратная связь через светодиод на устройстве и переднюю камеру на смартфоне. Сложное приложение? Из пушки по воробьям? Да! А что делать если у вас есть только пушка?
Второй вариант: RFID-образный обмен. Устройство просто слушает спиральную антенну, а для ответа замыкает ее ключом. Все идет к тому, что эта функция станет стандартной в смартфонах и скорее всего, что бы мы не придумали из костылей, со временем именно она станет стандартом.
За поднятую тему спасибо. Проблема программирования простых устройств действительно существует. Обязательно буду следить за обсуждением и вообще за вашими статьями.
Не нужно верить мне на слово. Просто посмотрите что получается, где идет поток тепла. Я утверждаю, что основные потери происходят на элементе Пельтье и по его краям, а вынесение из стенки ничего не меняет. Вам все равно придется его утеплять по периметру, но придете к тому же с чего начали. Конечно, вам может быть конструктивно необходимо прикрепить радиаторы к холодной и горячей стороне чтобы увеличить площади теплообмена, но сама «дырка» между ними в виде элемента Пельтье останется в любом случае.
Не очень понимаю ваш вопрос. Да, вы можете вынести элемент Пельтье из стенки холодильника, но поток тепла от горячей стороны элемента к холодной останется тем же самым. И это при условии что боковые стенки и тепломагистраль утеплите не хуже холодильника. Если вы посмотрите на общий поток тепла в системе до и после такой операции, то увидите что разницы нет, только добавилась ТТ и некоторое количество теплоизоляции. В этом нет смысла.
У меня было время поразмышлять над этим вопросом. Пришел к следующим выводам:
Если необходимо знать фазные ЭДС, то начинать следует с измерения линейных ЭДС по описанной выше методике в режиме холостого хода. Затем необходимо оценить насколько близко эти графики могут быть апроксимированы синусоидами. Если получилось, то можно воспользоваться виртуальной средней точкой и напрямую измерить фазные ЭДС. Если линейные ЭДС на синусоиду не похожи, то виртуальную среднюю точку использовать нельзя, ее потенциал будет колбасить с тройной частотой и амплитудой до десятков процентов от амплитуды фазной ЭДС в зависимости от степени ее несинусоидальности. В этом плохом для нас случае все еще можно попытаться численно решить задачу. Будет попроще, если экспериментальные графики ЭДС имеют близкую форму, отличающуюся только фазой и возможно амплитудой. Если они заметно отличаются по форме, то задача усложнится еще на порядок.
Вывод:
Лучше разобрать двигатель и найти среднюю точку. Это будет надежно, точно и без мучений. Численное решение или измерения с виртуальной средней точкой при отличии линейных ЭДС от синусоиды могут дать плохую точность и трудно предсказать насколько.
Последнее замечание, наверное самое интересное, но и самое голословное:
Пока это интуитивно, доказательства не проводил. Назовем это гипотезой. Хайли лайкли, нам совершенно не нужно знать как ведет себя средняя точка обмоток относительно земли драйвера и соответственно не нужно пытаться ее просчитать. Более того, у нас есть значительная свобода в способе формирования линейных напряжений, которую и используют при «инжекции третьей гармоники» в виде синуса, треугольника или любой другой формы по желанию разработчика, выигрывая тем самым в понижении минимально необходимого напряжения на DC шине драйвера. Гипотеза состоит в том, что должна существовать методика, которая позволяет вычислять правильный закон управления для драйвера прямо из экспериментальных линейных ЭДС двигателя, минуя промежуточное вычисление фазных ЭДС. Причем, решение не единственное, если не задать дополнительные условия.
Как-то так. Не знаю только нужно ли это кому-нибудь из практиков. Им расковырять двигатель попроще будет. А вот для диплома или курсовой кто-нибудь мог бы и попробовать.
Мне просто любопытно. Задумался как бы сам измерял ЭДС PMSM со звездой без вывода средней точки. А если есть возможность узнать как делают корифеи, так это очень даже любопытно. Конечно, если средняя точка была доступна, то вопросов у меня точно не возникает. Поэтому и уточняю так настойчиво.
Чисто интуитивно вариант со «слабой» искусственной средней точкой мне не очень нравится. Сам бы наверное начал с того, что посадил землю осциллографа на одну из фаз и измерил относительно нее ЭДС на двух других. Третий сигнал получил бы как разность двух полученных. Но может и не прав. Хочу разобраться.
Нет. Не знакомы. Просто был невнимателен при первом прочтении к шапке. Во вводном слове авторство раскрыто, а в комментарии ниже признано под этим ником. Ну и еще вспомнил что видел такую фамилию на обложке. Пользуясь случаем, — спасибо за ваши книги.
Так понял, что автор текста вы. Позвольте еще раз уточнить сколько выводов было у двигателя? Вы ответили так, что их как-бы четыре — три фазы и средняя точка, а ваш директор чуть выше ответил так, что их как-бы три, а среднюю точку сформировали тремя резисторами по 100 кОм. Пожалуйста, можно припомнить не «как-бы», а «как было»? Спасибо.
Об этом и речь. Их не стоит смешивать. В моей «программе» субъект представлен одномерным массивом строк. Это не метаязык, а просто язык. В самом коде метаязыка вообще нет.
Чуть выше ответил synedra как раз по этому поводу. Утверждаю, что в данном выражении Самореференции нет, нет и смешивания языка и метаязыка, а есть абсолютно нормальное математическое утверждение, однако в условиях недоопределенности задачи. Подробнее посмотрите пожалуйста одним уровнем выше.
Совсем нет. Фактически она двоичными цифрами и записана. Вы же ее на экране монитора прочитали? Каждую букву можно обозначить двоичным кодом и получить взаимно однозначное отображение двух множеств. Т. е. подмена алфавита ни на что повлиять не может (это просто «замена переменной в уравнении»), только количество нужно тоже менять во фразе поскольку оно зависит от алфавита.
В исходной фразе просто нет самореференции, нет описания себя через себя, поскольку обозначению в виде текстовой строки (имени переменной) задается значение в терминах каких-то вычислений, не использующих саму эту переменную. Попробую изобразить в чертикаком коде, но должно быть понятно:
very_long_int description_len(very_long_int i) {
/* Здесь должно быть определение понятий субъекта на данный момент времени в виде одномерного массива строк, которое не определено в исходной задаче. Каждому индексу соответствует строка обозначения числа равного индексу.*/
return len(description_string[i]);
};
Это просто нормальное математическое утверждение (при условии полного определения задачи, как писал об этом выше). Наверняка вы могли бы написать код и поизящнее чем это сделал я. Но особо и не старался, честно говоря. Главная цель — показать, что в определении значения переменной ни сама переменная ни ссылка на нее не используется и значит Самореференции быть не может. Просто не следует отождествлять строку символов (обозначение) с ее смысловой нагрузкой в понимании субъекта.
"… причем нелинейность САУ может определяться различным причинами" — различнымИ
После «Разложим левую часть уравнения (2.2.2) в ряд Тейлора в малой окрестности точки равновесного состояния» вторые скобки с заключенным в них выражением лишние.
"«простое» разложение функции в ряд Тейлора в окрестности точки" записано с ошибкой. Не проставлены степени (x-x0). И не очень понятно зачем оно вообще приводится, если дальше используется формула разложения в рад Тейлора функции многих переменных, а не одной.
После «C учетом вышеприведенного разложение принимает вид:» везде должны использоваться частные производные.
(2.2.4) Из аргументов F(...) в левой части почему-то пропал последний аргумент t. Это следует пояснить. На первый взгляд формальных оснований для этого не вижу.
Что значит «В самом деле, разделив уравнение (2.2.5) на (y0, u0) и выполнив некоторые преобразования, получаем:»? (y0, u0) это что?
(2.2.7) У b0 звездочка «уехала» из верхнего индекса. И еще здесь следует добавить «Где:» и выписать формулы для коэффициентов со звездочками, как это делалось везде до и после этой формулы. Иначе очень неудобно отслеживать правильность «некоторых преобразований».
В целом, я уже начинаю уставать от обилия опечаток. Если и дальше нужно будет так продираться, то вряд ли мне захочется учиться именно по этому тексту.
Первая же картинка (и рис. 2.1.2 тоже). Масса поршня на картинке обозначена M, а в формулах (в том числе и на этой же картинке) везде m. Кроме того, на схеме (тот же рисунок) первый входной параметр не учитывает массу. Надо бы g на нее домножить.
Не понимаю вторую строку в формуле без номера после слов «перейдем к отклонениям от стационарного состояния:» Там что, квадратные скобки заменяют взятие производной по времени? Или все же к квадратным скобкам в последних двух формулах системы следует дописать по одному штриху?
Формула без номера после «Вычитая из уравнения (2.1.3) уравнение (2.1.4), получаем уравнение динамики демпфера в отклонениях:» (перед (2.1.6)) в левой части затесался лишний множитель g.
(2.1.6a) после «где:» в выражении L(p)=T2^2*p+… должно быть L(p)=T2^2*p^2+…
Ниже не пронумерованная формула после «Введем новые нормированные (безразмерные) переменные:» — Потерялся штрих в правой части первого уравнения последней системы (при y~(t))
(2.1.7) Тоже T2^2*p+… должно быть T2^2*p^2+…
И еще один вопрос, если позволите. Это дорогая технология? Только горняки могут себе позволить? Потенциально ведь опасные объекты это и стройки и цеха и даже уличное движение.
Справедливости ради замечу, что скорость перерисовки экрана вы явно занизили. Все не так плохо :) Скорость может быть гораздо больше.
Но давайте оставим оптику и посмотрим внимательнее на звук и RFID. Не настаиваю, но предлагаю рассмотреть варианты. Во-первых антенну передатчика можно подключить к звуковому разъему смартфона и получить полудуплексную связь. Стоимость аудиоджека и кусочка провода копеечная. Можно прилагать к каждому устройству.
А во-вторых почему бы не отказаться от микрофона или антенны вообще и соединять аудиовыход смартфона с устройством напрямую обычным аудиокабелем? Хотите чтобы пользователю не нужно было ничего искать? Припаяйте провод 10 см к устройству, а на другой конец аудиоразъем и сложите в нишу корпуса. Предсказуемое качество канала, не нужна тишина на время прошивки и т. д. Как следствие, намного бОльшая скорость. А звуковой сигнал, как вы гениально предложили, генерируется скриптом с веб-страницы.
Кроме того, хочу обратить внимание насколько важна обратная связь. Пока у вас производится одно устройство проблемы не заметите. Но появится другое и пользователи тут же начнут заходить на неправильную веб-страницу и пытаться запрограммировать устройство не предназначенными для него настройками. Конечно устройство отвергнет такую попытку, но отреагирует мигающим светодиодом т. к. не сможет отличить такую ситуацию от ошибки передачи. А пользователь после трех попыток будет уже сильно нервничать и не понимать что происходит. Лучше бы сразу закладывать возможность опроса устройства на предмет его модели, а еще лучше на скачивание всех текущих настроек и отражать их на в форме веб-страницы в качестве исходных.
Стараюсь придерживаться правила «критикуешь — предлагай». Первый вариант: Гораздо меньше опасений вызывает передача световых сигналов. Используйте мигание экрана смартфона и фототранзистор в 5 мм корпусе (чтобы встроенная линза собирала побольше света) на устройстве. Такое решение вроде уже применялось. Обратная связь через светодиод на устройстве и переднюю камеру на смартфоне. Сложное приложение? Из пушки по воробьям? Да! А что делать если у вас есть только пушка?
Второй вариант: RFID-образный обмен. Устройство просто слушает спиральную антенну, а для ответа замыкает ее ключом. Все идет к тому, что эта функция станет стандартной в смартфонах и скорее всего, что бы мы не придумали из костылей, со временем именно она станет стандартом.
За поднятую тему спасибо. Проблема программирования простых устройств действительно существует. Обязательно буду следить за обсуждением и вообще за вашими статьями.
Если необходимо знать фазные ЭДС, то начинать следует с измерения линейных ЭДС по описанной выше методике в режиме холостого хода. Затем необходимо оценить насколько близко эти графики могут быть апроксимированы синусоидами. Если получилось, то можно воспользоваться виртуальной средней точкой и напрямую измерить фазные ЭДС. Если линейные ЭДС на синусоиду не похожи, то виртуальную среднюю точку использовать нельзя, ее потенциал будет колбасить с тройной частотой и амплитудой до десятков процентов от амплитуды фазной ЭДС в зависимости от степени ее несинусоидальности. В этом плохом для нас случае все еще можно попытаться численно решить задачу. Будет попроще, если экспериментальные графики ЭДС имеют близкую форму, отличающуюся только фазой и возможно амплитудой. Если они заметно отличаются по форме, то задача усложнится еще на порядок.
Вывод:
Лучше разобрать двигатель и найти среднюю точку. Это будет надежно, точно и без мучений. Численное решение или измерения с виртуальной средней точкой при отличии линейных ЭДС от синусоиды могут дать плохую точность и трудно предсказать насколько.
Последнее замечание, наверное самое интересное, но и самое голословное:
Пока это интуитивно, доказательства не проводил. Назовем это гипотезой. Хайли лайкли, нам совершенно не нужно знать как ведет себя средняя точка обмоток относительно земли драйвера и соответственно не нужно пытаться ее просчитать. Более того, у нас есть значительная свобода в способе формирования линейных напряжений, которую и используют при «инжекции третьей гармоники» в виде синуса, треугольника или любой другой формы по желанию разработчика, выигрывая тем самым в понижении минимально необходимого напряжения на DC шине драйвера. Гипотеза состоит в том, что должна существовать методика, которая позволяет вычислять правильный закон управления для драйвера прямо из экспериментальных линейных ЭДС двигателя, минуя промежуточное вычисление фазных ЭДС. Причем, решение не единственное, если не задать дополнительные условия.
Как-то так. Не знаю только нужно ли это кому-нибудь из практиков. Им расковырять двигатель попроще будет. А вот для диплома или курсовой кто-нибудь мог бы и попробовать.
Чисто интуитивно вариант со «слабой» искусственной средней точкой мне не очень нравится. Сам бы наверное начал с того, что посадил землю осциллографа на одну из фаз и измерил относительно нее ЭДС на двух других. Третий сигнал получил бы как разность двух полученных. Но может и не прав. Хочу разобраться.
Позвольте уточнить сколько выводов было у этого двигателя (6? 4? 3?) и как был подключен к ним осциллограф?
В исходной фразе просто нет самореференции, нет описания себя через себя, поскольку обозначению в виде текстовой строки (имени переменной) задается значение в терминах каких-то вычислений, не использующих саму эту переменную. Попробую изобразить в чертикаком коде, но должно быть понятно:
very_long_int Самое_маленькое_число_для_обозначения_которого_недостаточно_восьмидесяти_букв;
very_long_int description_len(very_long_int);
Самое_маленькое_число_для_обозначения_которого_недостаточно_восьмидесяти_букв = min(
description_len(1) > 80 ? 1 ; NULL,
description_len(2) > 80 ? 2; NULL,
...
description_len(35^80+1) > 80 ? 35^80+1 ; NULL
)
very_long_int description_len(very_long_int i) {
/* Здесь должно быть определение понятий субъекта на данный момент времени в виде одномерного массива строк, которое не определено в исходной задаче. Каждому индексу соответствует строка обозначения числа равного индексу.*/
return len(description_string[i]);
};
Это просто нормальное математическое утверждение (при условии полного определения задачи, как писал об этом выше). Наверняка вы могли бы написать код и поизящнее чем это сделал я. Но особо и не старался, честно говоря. Главная цель — показать, что в определении значения переменной ни сама переменная ни ссылка на нее не используется и значит Самореференции быть не может. Просто не следует отождествлять строку символов (обозначение) с ее смысловой нагрузкой в понимании субъекта.