Подозревать - это не одно и то-же что "быть уверенным". Посему выскажу следующее мнение:
- лучше всего это подключиться к интерфейсу самого счётчика (или заменить его на такой счётчик (типа "меркурия 230")). Обычно это RS485. Сразу оговорюсь - обратите внимание, что питание интерфейса внешнее т.е. помимо линии данных, необходимо озаботиться и питанием самого интерфейса (делали явно дилетанты эти счётчики - апсолютно НЕ практично).
- обычно энергетические компании не используют дистанционное сканирование. Хотя если такое есть - то интегрироваться в их систему будет проще (имхо конечно-же).
- если сами захотите сканировать, то в гугле куча инфы по интерфейсам подобных счётчиков.
- если лень самим или нет спецов - то можно обратить внимание на готовые интерфейсные решения на рынке - см. bolid и иже (вплоть до крохоборов с "облаками" и другими обдуриловки клиентов).
Кстати счётчики отдают гораздо больше инфы чем ток-напряжение по фазам. Рекомендую глянуть юайные софтинки которые умеют работать со счётчиками.
С уважением
(круглый)
Сразу оговорюсь:
1) эпоксидка
2) НЕ пром вариант
3) Есть ПОБОЧНЫЙ эффект
Про пузырьки все уже высказались - тут вряд ли, что либо новое добавлю. В авиамоделизме применяется
- вакуумирование
- центробежная сила
По поводу разжижения(в том числе и снижение рисков саморазогрева) - очень замечательно подходит(для ЭПОКСИДКИ) это спирт. до 50% можно вливать. Да, сначала побелеет (есть вода естественно в спирте), далее после интенсивного размешивания становится менее тягуч до состояния воды. Время отвердевания увеличивается (не намного). Но при этом побочный эффект - усадка (естественно). Ну и отгезия.
Кстати эпоксидка имеет отгезию и усадку до месяца (это по паспорту).
С уважением
(круглый)
ЗЫ
Стаж работы с ЭДП более 30 лет, если что...
Корова немного не моя :)
Пока фаза сбор инфы. И одна из них - возможно ли изготовить магнит с радиальной намагниченностью. Вот тут выше подсказали, что да возможно.
Буду благодарен за посыл по общему вектору... или любую другую инфу наполняющую копилку знаний ...
С уважением
(круглый)
Добрый день!
Всем известны как устроены обычные динамики.
Формат их магнита - плоский тор, полюса которого располагаются на широких его сторонах (если положить на стол = сверху и снизу).
Вопрос:
Возможно ли изготовить магнит, полюса которого будут располагаться с торцов такой геометрии (один полюс внутрь, второй наружу) ?
С уважением
(круглый)
ЗЫ
Возможно не в ту ветку форума. Поправьте пожалуйста, если так :)
+100500
2TC
странно когда программист говорит компилятору - а теперь сделай красиво как хошь... а потом требует на отладке все стэпы которые ему казались что должны быть. Не находите?
Если вы хотите дебажить выхлоп оптимизатора - то ТОЛЬКО(!) на уровне азма. всё остальное будет от лукавого.
ошибка в 55 строке...
мало данных. начинайте пилить проблему на составляющие. включите-загляните в статистику lwip. Он показывает приём ваших потерянных пакетов? Если нет - сетевой уровень, плюс взаимодействие. Если ему пофигу и приём успешен - значит затык далее. И ещё. У вас в одном потоке или что то многопоточное прикручено? Используется ли пдп, он же дма :) ? аллокатор памяти какой юзаете? Правильно ли используете сам lwip?
удачи вам
(круглый)
PS
Если траблы с lwip-ом - то переносите, заводите топик в сетевов разделе вопросов. Там по сети толковые ответы получите быстрее.
1) юарт - не определяет протокол, формат и взаимодействие по нему. Вы можете сами выбирать разрядность, чётность, и т.д.. А уж по формату фрэйма - вообще что угодно и как угодно.
UDP определён в конкретном документе. Если Вы изобразите нечто отличное от этого определения - то это уже будет не UDP...увы и ах... В этом собственно и отличие.
2) Это не моя логика. Это есть такая фигня как RFC768 (из разряда, а мужики то и не знали)...
3) В RFC написано... This protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. Это из описания собственно. сэнд мэссэдж - собственно передача сообщения. ПЕРЕДАЧА. Не буфферезирование, а ПЕРЕДАЧА. Конечно-же можно как угодно трактовать слово "сенд".... но вот так вот написано само определение.
4) Про обработку ошибочных ситуаций не было речи - не теряйте фокус... Естественно речь идёт об успешном ответе при передачи UDP. Так вот, если стэк протокола ответит OK и при этом забуфферизирует данные и не разрешит MAC адресацию то собственно это уже будет не совсем UDP (по описанию)...
как то так
(круглый)
вот это в правильной реализации не должно быть по определению. если мы отдали уже управление на вызове с уровня программы, забуфферизировали и успешно грохнулись(ну или не разрешился MAC адрес) - то это собственно нарушение контракта UDP интерфейса для юзверов.
(круглый)
ЗЫ
с ходу в рфс ничего конкретного не нашёл...может смотрел не дотошно - хз...
По определению.
Если изернет стэк это не делает - меняйте(правьте) нафик стэк.
UDP - гарантирует ОТПРАВКУ пакета. Т.е. если вам вернулось управление после вызова функции send - то пакет 200% ушёл в сеть.
(круглый)
делал подобное в меге128. на лопапалам её флэш делил. компилял как обычно. но делал софтинку для потрошения hex формата (подправлял адресацию). Менял и вектора так-же...прошивал половинку меги + таблицу векторов.
у Вас без таблицы векторов, насколько я понимаешь.
Общая засада при таких хотелках = проследить чтоб везде была относительная адресация.
имхо: компилять обычно как программу. обязательно везде относительная адресация. дать линкеру честно сформировать таблицу нужных вентилей вызовов (таблица векторов ли или некая своя структура адресов функций - не суть). далее корректируем эту таблицу - до загрузки, если адреса загрузки фиксированы. - в момент загрузки, если адрес загрузки не известен. адрес естественно выровнен на нужное смещение.
как то так
(круглый)
