=AK=
-
Постов
3 234 -
Зарегистрирован
-
Посещение
-
Победитель дней
5
Сообщения, опубликованные =AK=
-
-
Потому что сигнал подается биполярный - схема с конденсатором на выходе не подходит так как совсем низкие частоты отрубаются
Типовая однополярная схема включения прекрасно работает с частотами до 1 Гц, ошибка на этой частоте всего 0.1% при входном кондере 47 мкФ. А вы на каких частотах rms мерять собираетесь? Микрогерцы?
-
Есть микросхема http://cds.linear.com/docs/en/datasheet/1968f.pdf
Ее надо питать биполярным напряжением +-2.5 вольта.
В честь чего вы так решили? В даташите прямо на первой странице черным по белому написано - однополярное питание, от 4.5 до 5.5 В. Среди трех типовых схем включения fig.9 только одна с двуполярным питанием, а две - с однополярным. Зачем вам двуполярное питание?
-
Так что ищу решение по коммутации того, что есть
Существуют специальные разновидности реле для коммутации емкостных нагрузок. У них контакты двойные (bifurcated). При замыкании сначала замыкаются высокоомные тугоплавкие вольфрамовые контакты, затем - низкоомные из серебряного сплава. При размыкании наоборот, вольфрамовые котнакты размыкаются последними, поэтому реле хорошо коммутируют и индуктивные нагрузки тоже - вольфрам довольно устойчив к дуге.
Поищите у Шрака, у них есть недорогие маломощные реле с такими контактами.
-
Ни в коем случае - фторопласт течет под нагрузкой.
А вот здесь, например, изолируют фторопластом, и даже лентой фум советуют пользоваться:
-
Ссылка битая. А сам сайт Эфо - помойка, самостоятельно статью найти невозможно. Таких несолидных поставщиков лучше избегать, поскольку бардак в объявлениях и бардак на сайте скорей всего являются отражением неизбывного бардака в самой компании. :)
-
можно ли передать сигнал управления по видеокабелю самой камеры, чтобы не тянуть еще 2 провода?
Можно. Однако проще видео передавать по обычному эзернет кабелю Cat5/Cat6. В нем 4 витых пары, по одной паре передавать видео, оставшиеся 6 проводов использовать как захочется.
-
Это довольно примитивный протокол клиент-сервер.
Довольно смешно это читать, зная что AllJoyn тоже использует модель клиент-сервер. БАКнет - он старенький, громоздкий и кривой. Зато он уже есть и кое-где применяется, a его опенсорс с либеральной лицензией для разных платформ на Соурсфордже лежит. А AllJoyn будет ли жить или нет - бабушка надвое сказала, особенно учитывая наличие прямого конкурента в виде OIC/IoTivity. Наслушавшись прогнозов, все дружно бросились столбить участки в полях IoT, надеясь на золотые россыпи. Надувают очередной пузырь, а получится как всегда.
-
Ну сравнили, какой-то низкоуровневый протокол родственник MODBUS и целый готовый софтварный фреймворк.
Судя по этой реплике, вы совсем не понимаете, что такое БАКнет. В истоках его лежит точно такая же инициатива, как у AllJoyn: объединить в одно целое разнородные устройства разных производителей. Только проявлена эта инициатива была на 25 лет раньше и, соответственно, названа так, как было модно называть что-то новое в то время - "протокол". Сейчас слово "протокол" вышло из моды, поэтому AllJoyn использует то слово, которое модно в настоящий момент, "фреймворк". А по сути это ничем от БАКнета не отличается, БАКнет тоже можно "фреймворком" назвать, если хочется. И перспективы у AllJoyn точно такие же, как у БАКнета, если не хуже.
-
Литиевые аккумуляторы требуют строгого соблюдения режима зарядки. Они могут взорваться.
LiFePO4 не взрываются. В Новосибирске построен крупный завод Лиотех по их производству. На мелкие литиевые аккумуляторы, действительно, часто ставят контроллеры заряда, но это не универсальное решение, а заплатка, придуманная для ноутбуков и перекочевавшая оттуда даже в китайские электровелосипеды. Для больших аккумуляторов такое решение теряет смысл.
-
А вы разве не слышали про опенсорсный фреймворк AllJoyn?
Лет 10-15 назад точно так же растопыривал пальцы BACnet. И кто его сейчас вспомнит? А MQTT никаких авансов не раздает, в барабан не лупит и флагами не размахивает, а просто работает.
-
Заряжать не полностью свинцовые аккумуляторы можно, ничего плоxого с ними от этого не случится. Беда в другом, их глубоко разряжать нельзя. Должно оставатся хотя бы 30% заряда, иначе они очень быстро испортятся. Вот и получится у вас, что вы будете заряжать до 70%, разряжать то 30%, используя всего 40% от иx емкости.
Глубоко разряжать (до 0) можно щелочные аккумуляторы. Поэтому их используют в подлодках. Литиевые тоже можно глубоко разряжать, но дороговаты они.
Сxодите вот на этот форум, там много инфы полезной: https://www.forumhouse.ru/forums/162/
-
не совсем понял, придется делать XOR всех байт пакета?
Ага. А вас по каким-то причинам напрягает операция XOR? Религия не позволяет, или типа того? Ну тогда не делайте, посылайте как есть, на практике результат будет одинаковый.
с чего это? USB наиболее удален от помех будет. и длина RS-485 будет 5 метров кабеля, а USB меньше 1 см на платеДа хоть миллиметр. Помехи-то все равно пройдут сквозь него. Наведутся они вовне, а пройдут сквозь ваш короткий USB, если им деваться больше некуда. Опторазвязка может помочь частично, но за счет паразитных емкостей помехи все равно пройдут.
-
Надо сделать всё, как вы описали, просто заменить символ 0xF0 на символ 0xFF, и всё будет прекрасно работать на любом контроллере.
Когда используется COBS, то удобнее всего при кодировании как специальный символ использовать 0. Поэтому, если надо получить на физическом уровне специальный символ 0xFF, то проще всего делать XOR 0xFF.
Что же касается 0xF0 в том топике, то там мой (радио)канал требовал, чтобы количество 0 и 1 в последовательности было равно. Поэтому я использовал именно 0xF0 как специальный символ для байт-синхронизации и взвешенное кодирование 6b8b для данных, и все прекрасно работало с обычным микроконтроллерным UART-ом.
-
автору наверное ещё вчера это сдать надо было, а теме уже 10-я страница.
А какая разница? Как ни сделай, хоть бы даже вообще тупо на подтяжки понадеяться, все равно первым сбиваться будет USB, а не RS485. Тем более что у ТС изохронная труба, которая не гарантирует доставку.
-
Символ же 0xFF, переданный перед началом пакета, гарантированно восстановит битовую синхронизацию:
Если уж закладываться на кривизну PC16550, то проще всего делать XOR 0xFF каждого байта при приеме и передаче. Тогда два 0 в начале и 0 в конце передачи на линии появятся как 0xFF.
Предлагаю конец теме — ... делаем задержку ... немного попринимали ... делаем задержку ...Варианты с задержками (в частности, Modbus RTU) обсуждались ранее. Интереснее сделать вообще без задержек, на одном UART-е, без использования таймера.
-
в Википедии "сложный" вариант перекодировки COBS. Где тогда можно простой посмотреть?
"а это уж вы сами" © Щербаков
предложил всунуть между канальным и физическим уровнями кусок транспортного (номер пакета).COBS тут не подходит по указанной выше причине - малейший шум в паузе и пакет вы потеряли.
К сожалению, вы ничего не поняли, даже какой-то "номер пакета" вдруг выдумали и приплели ни к селу ни к городу.
Никакой шум в паузе не повлияет на прием пакета из-за того, что передатчик передает два 0 до начала пакета. После паузы приемник гарантировано получит хотя бы один 0, после чего "шумовой" пакет будет проверен и отвергнут из-за несовпадения CRC, а также из-за несоответствия правилам COBS. А следующий сразу же вслед за этим истинный пакет будет принят без искажений.
-
Нет смысла охватывать номер датчика CRC, он же все равно будет переписан. Хотя может быть испорчен дальше, но дальше все таки дифф пара RS-485.
А вы этот номер передавайте в самом байте дважды: в младших 4 битах сам номер, а в старших четырех битах - его инверсию. Так вы любые одиночные ошибки в этом байте обнаружите.
-
а как? датчик же не знает какой у него номер. все датчики одинаковые, воткнул в 1-е гнездо, значит датчик №1, если в о 2-е, то №2
Тогда пусть все датчики ставят в нужное место номер 1, кодируют и отправляют. А ваш МК1 просто заменит номер 1 в этом месте на действительный номер датчика. Если он не будет равен 0, то на COBS это никак не повлияет.
Однако при этом придется обойтись без CRC на все сообщение, поскольку CRC надо добавлять до того, как кодировать по COBS. Можно, конечно, CRC считать в датчике, а "1" добавлять потом, но при этом номер датчика не будет охвачен CRC. Это не очень хорошо, но работать будет.
Для синхронизации. У меня в USB МК отправляется сначала счетчик фрейма (2 байта), потом данныеКакой счетчик? Взятый в тот момент, когда вы получили сообщение, или в тот момент когда вы его сформировали в буфере для отправки? Неужто вы думаете, что он будет отправлен в том же фрейме? Ведь вы же BULK используете, а он асинхронный.
Специфиkация USB:
5.12.4.1.1 Asynchronous
Asynchronous endpoints cannot synchronize to SOF or any other clock in the USB domain.
-
А мне удобнее COBS преобразование сделать в датчике, а в МК1 добавить байт - номер датчика.
А почему датчик не может сразу добавить свой номер и CRC, а потом закодировать сообщение?
Добавить байт (т.е номер датчика) к уже закодированному COBS сообщению - вообще-то проблема, даже если этот номер не равен 0. Потому что в корректной реализации при раскодировании сообщения на месте этого байта должен быть или 0 (это значит, что сообщение закончено), или число последующих ненулевых байт в сообщении. Конечно, можно наставить костылей, например, если длина сообщения фиксирована, то последний байт обрабатывать не так, как остальные. Только нехорошо это.
почему? данных же мало, всего то 12 байт.Потому иначе намного больше вероятность, что что среди ложных сообщений будет такое, что пройдет проверку.
А этот преобразователь, он же только данные отправляет? А счетчик USB фрейма?SOF-ы автоматически считаются "на нижнем уровне". А накой вам этот счетчик?
-
Я имел ввиду, что у меня есть данные 12 байт плюс считаю контрольную сумму = 13 байт. Преобразую все это дело по COBS-у, получается 14 байт. Это данные от одного датчика. Они поступают на МК через обычный UART, в обработчике DMA я добавляю номер датчика. Так вот эта добавка не будет противоречить COBS-у?
Я не понимаю о чем вы говорите. Выражайте свои мысли яснее. Тот, кто отсылает сообщение, может добавить в сообщение что угодно, затем закодировать и переслать. Приемник раскодирует принятое сообщение обрабатывает как требуется, если надо - добавляет номер датчика. В чем проблема-то? Не играет роли кто является приемником, кто передатчиком. И что вы там в своем железе нагородили, кто у вас там "датчик", кто "МК", причем тут ДМА, и кто чего должен добавлять, то ли на передающем конце, то ли на приемном - так телепатов нет.
Кстати, однобайтная контрольная сумма - это мало, так вы ложные сообщения не отсеете. Используйте двухбайтный CRC.
-
А я смогу это преобразование выполнить на 8-битном процессоре с тактовой частотой 12 Мгц?
На чем угодно. Хоть на брэйнфаке.
Я имею ввиду по скорости, это преобразование много времени занимает?Мизер. Посмотрите сами на код в Википедии и не задавайте таких вопросов. Причем, там приведен "сложный" вариант кода, поскольку они обрабатывают сообщения произвольного размера, а потому перекладывают из одного буфера в другой, чтобы по ходу можно было вставлять дополнительные байты. В случае же коротких сообщений (меньше 255 байт) все гораздо проще, поскольку заранее все известно: один дополнительный байт появится в начале. Поэтому и перекладывать ничего не надо, одного буфера достаточно, просто незакодированное сообщение надо в него класть начиная не с 0-го байта, а 1-го. Потом просто пробегаете по буферу и заменяете нули.
И еще, после передачи от датчиков на МК мне надо как минимум добавить один байт - номер датчика (1,2,3..8). Можно ли это сделать без ущерба протоколу? Кроме того, нули то должен именно этот МК отправлять, потому что он передает по RS-485Да какая может быть разница, что вы там запихнете в свое сообщение? COBS-у это абсолютно по барабану. На передающем узле закодировали, на приемном раскодировали.
-
Что касается Modbus и прочего, то дело в том, что у меня пакет данных от датчика составляет 12 байт плюс могу рассчитать контрольную сумму. Это траффик от датчика до МК1. Там чистый UART и скорость не хочется задирать, она там и так 350 кбит/с. Далее, к МК1 подсоединены несколько датчиков (8). То есть если приделывать к пакетам большие обрамления в МК1, то опять же придется повышать скорость передачи по RS-485 (передача на МК2).
При использовании COBS длина вашего (короткого) пакета увеличится на 1 байт. После преобразования COBS в вашем пакете не будет нулей. Для очистки грязи из приемного буфера надо дважды передать 0 до начала самого пакета. Первый 0 может оказаться испорченным, зато второй дойдет и очистит буфер. Для простоты можно еще раз передать 0 по завершению пакета. "Простота" заключается в том, что это позволяет не парсить приходящие байты "на лету", надо ловить только 0 и проверять валидность пакета целиком после прихода нуля. Итого, 4 байта накладных расходов.
И никаких таймеров и пауз, это лишнее, если делать с байт-стаффингом. Таймеры и паузы нужны для Модбаса RTU и подобных ему протоколов. Правда, не все липовые "специалисты" это способны понять.
-
Многословие, напыщенность, уклончивость, невнятность и иносказательность - есть верный признак отсутствия знаний, особенно когда они демонстрируются вкупе.
-
Достаточно просто проверить, что принятый мусор не совпадает с признаком начала пакета.
Ну а если совпадает? Одного "признака начала" недостаточно. "Байт-стаффинг" - это более точное указание на то, что требуется. Я уже писАл, что байт-стаффинг проще, чем Модбас. Более того, предлагал ТС использовать COBS.
Конечно, можно слепить какой-то "недо-байт-стаффинг", некий упрощенный вариант, играя на том, что требуется не полная сеть, а всего лишь пара мастер-слэйв. А оно надо? Разумнее не плодить ублюдков.
мини PLC.
в Программирование
Опубликовано · Пожаловаться
Ваша задача не имеет никакого отношения к PLC, это полная чушь.
То, что вы тут накалякали, в принципе может быть реализовано путем создания некого скриптового языка. Тем не менее для грамотного решения , вам придется озаботиться и БНФ, и парсингом, и интерпретатором. Однако поскольку вы демонстрируете чрезвычайно низкий уровень знаний и очень много гонора, то шансы на то, что вы сподобитесь решить эту задачу "в общем виде", исчезающе малы.
Один из грамотных вариантов решения, который вам может оказаться посильным, таков: освойте язык Форт, поставьте Форт-систему на вашу целевую платформу и задайте для пользователя словарь только с определенными вами Форт словами, а все остальные Форт слова сделайте недоступными для пользователя. При этом парсингом займется Форт система, правда, синтаксис псевдо-языка будет с обратной польской записью. При желании и это можно изменить, да только вряд ли нужно.