=AK=

Не зная задачу, что-то конкретное советовать трудно. Если в нормальном режиме ток маленький, я бы просто поставил резистор в несколько Ом.

И что, на 50 Гц у него проницаемость изменится? Или потери возрастут? "Не делайте мне смешно" (с) Ферриты прекрасно и без малейших аномалий работают на любых низких частотах, начиная от dc. Кроме даташитов есть физика и материаловедение, так что предсказать поведение известного материала на других частотах (особенно на низких) труда не представляет. Да и применяются ферриты не только в ИИП, работающих на фиксированной и относительно высокой частоте. PS: Кстати, приведенная в даташитах индукция насыщения - именно статическая, на постоянном токе, а не на сотне килогерц, как Вы, похоже, думаете, судя по репликам.

Опять со своими вредными советами лезешь? Hе всегда алюминиевый электролит можно заменять танталовым. С танталовыми надо быть осторожным: они обычно не держат большие импульсные токи, а при пробое дают не хх, а кз. Поэтому в БП как правило тантал не используют, им место в развязке, и то лишь при условии что БП имеет ограничение тока при старте.

Можно подумать, что они на низкой частоте насыщаются, а на высокой - нет. Что, конечно, неверно. Просто у ферритов индукция насыщения 0.3...0.4 Тл, а у дешевого трансформаторного железа - примерно 1 Тл. Поэтому на низких частотах, где трансформаторное железо еще хорошо работает, нет никакого резона применять ферриты, на железе транс получится меньше размером и дешевле.

К сожалению, то, что он показывает, совсем не то. Он, например, показывает ячейки в виде квадратиков и непонятно, какая функция внутри реализована. Можно, конечно, заниматься декодированием LUT_MASK, но это для любителей этого дела (и кому заняться нечем). Синплифай же показывает схемную реализацию - сразу видно, что получается. В квартусе есть RTL Viewer, показывает схемную реализацию. А Синплифай чего показывает? Правда, я никак не пойму, нафиг это нужно - смотреть схемную реализацию? Ну, посмотришь какой-то кусочек, подивишься, толку то что? Eсли у меня несколько тыс. лог элементов и регистров в проекте, и сам черт ногу сломит, пока хотя бы разберется, как поддающийся обзору мизерный кусочек схемы соотносится с исходным кодом. А уж выудить потом из этого хоть один бит полезной информации - просто не представляю как...

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

"в своем выступлении Вербицкая еще раз назвала проблему русского языка в России и странах СНГ «проблемой национальной безопасности»" Может, она и преувеличивает, но не сильно. :(

Что такое "терристор"? Это как-то связано с терроризмом? :blink:

http://www.caxapa.ru/faq/emc_immunity.html

Чтобы удвоить ресурс при записи счетчика, я пишу четные значения по одному адресу, а нечетные - по другому. При чтении читаются оба значения и выбирается бOльшее.

Повторяю: по вочдогу ресетится, пока прерывание телепается сотни мс - вочдог никто не сбрасывает, oн ресетит проц. Я зато вижу прямую связь между грамотностью и техническим уровнем. Как правило, если человек не усвоил правила русского языка, то и в технике он не разбирается. Потому что читал мало. Ибо грамотность обычно сама приходит к тем, кто читает книги, включая технические.

Потому что писать в таком стиле - значит ходить по граблям. Прерывания всегда "интерферируют" с основной прогой, а иногда и друг с другом. Чем дольше исполняется обработка прерывания - тем сильнее "интерференция по времени", т.к. время исполнения основного кода становится нeвозможно предсказать (например, управление вочдогом летит к чертям, и т.п.). Чем длиннее код обработки прерывания - тем больше вероятность "интерференции по коду", т.е. неатомарный доступ к переменным, неучтенный захват ресурсов (портов и пр.), и т.д. Вот по вочдогу и ресетится.

Oбработки прерываний занимают огромное время - с какого-то бодуна там везде стоят огромные задержки. "Вредных советов" начитались?

Ясно, спасибо за информацию. На сайте Фиорда в презенташке нашел: "IL - Подобен SIEMENS (Step 5)" т.е. наверное Step 5 подобен IL :) На всякий случай я задал вопрос о том, действительно ли IL произошел от Step5 г-ну von Ingo Rolle, члену IEC от Германии, автору книги "IEC 61131, Wozu?". К сожалению, книга написана на немецком, которым я не владею, однако уважаемый автор не поленился мне ответить. Он пишет: "the book says in chapter 4.2 that German contributions to IEC 61131-3 were DIN 19239 and VDI Richtlinie 2880 which already contained precursors of IL, FBD and LD." Как видим, о сименсовском Step5 речи не идет, т.е., как и ожидалось, Зюбин бредит.

А страх, прочно базируется на незнании :-( и нежелании/неспособности постигать новое после некоторого освоения и изобретения первого "лома". Безапелляционность при отсутствии аргументов, то есть голые понты. Кроме пресловутого "страха" (который вообще можно было и не упоминать, т.к. случаев наверняка мало, мне, например, они вообще неизвестны), есть много других, гораздо более веских причин. Например, ограниченность кругозора, когда человек просто не знает о существовании подходящего продукта, или, если и знает, то (ошибочно) думает, что продукт неприменим для его задачи. Кроме того, существует множество случаев, когда нет ровно никакого смысла осваивать это чужое "новое", поскольку затраты времени на освоение не окупаются. То есть, нередко бывает, что быстрее, проще и надежнее написать свое, чем копаться в тоннах док и наступать на чужие грабли. Причем часто эти грабли даже не самого "чужого" кода, а зарыты в дурно сделанных описаниях. Не говоря уж о том, что "универсальные" продукты просто гарантированно избыточны для каждой отдельно взятой задачи, а расплатой за оную универсальность будет не только размер кода, но и объем информации, который надо перелопатить. Хорошо еще если этот универсальный продукт можно будет применять снова и снова, причем не "механическим повтором", т.к. такой повтор сводит потенциальные преимущества универсального продукта к нулю - проще написать свое и повторять в каждом проекте. Я отнюдь не пытаюсь умалить роль "чужих" решений, они нужны, но они не являются панацеей. В сущности я еще раз другими словами сказал то, что здесь много раз говорили разные ораторы, так что довольно странно видеть здесь процитированные реплики. Если уж такие простые вещи и с пятого раза не доходят, то что же можно ожидать от описаний на относительно сложные продукты, сколько раз их придется перечитать, пока информация усвоится?

Где это я такое утверждал? Второй раз ловлю вас с поличными, вы приписываете мне слова, которые сами придумываете. Первый раз было про утечки памяти, хотя речь шла о сборке мусора. Теперь о другом, я говорил, что во многих реализациях ПЛК IL (уточняю: или подмножество его команд) является ассемблером виртуальной машины, а в некоторых даже ассемблером железного проца. Соответственно, отсутствие какой-то фразы в стандарте МЭК никак это мое истинное утверждение опровергнуть не может. Так кто бредит? :cranky: Вырисовывается определенная закономерность. Вы превратно понимаете то, что вам говорят, выхватываете какие-то слова из контекста, перевираете их, а затем спорите с тем, что сами напридумывали. Точно на такой же основе построены ваши бредовые статьи про МЭК. :maniac: Я буду только рад, если вы перестанете отвечать на мои посты, т.к. никакой полезной информации в ваших ответах нет. Тратить свое время на то, чтобы втолковать вам прописные истины, я тоже не намерен, потому как не верю, что это может привести к положительным результатам. Судя по тому, что вы несете свой бред уже 8 лет подряд, вразумить вас невозможно. Чтобы ваши глупые пространные сообщения, состоящие по большей части из ненужного цитирования, не мозолили глаза, посылаю вас в игнор.

Рекомендую прочитать http://akouz.e-access.com.au/zip/chokes_rev2.zip, там написано как рассчитать дроссель

Отсутствие какой-то фразы не может служить оправданием ваших домыслов. Идите с такими аргументами, мелкомягким доказывайте, что MSIL не имеет права на существование, т.к. .NET исполняется на машинах, ассемблером которых MSIL не является. Кстати, не надейтесь, что излишнее цитирование придаст веса вашим высказываниям. Оно лишь свидетельствует, что вы не способны отделить главное от второстепенного.

Цитаты из NI, чтобы яснее понимать области применимости: Experts from ARC, Venture Development Corporation (VDC), and the online PLC training source PLCS.net estimate that: * 77% of PLCs are used in small applications (less than 128 I/O) * 72%of PLC I/O is digital * 80%of PLC application challenges are solved with a set of 20 ladder-logic instructions The PC presented three main challenges: 1. Stability: Often, the PC’s general-purpose operating system was not stable enough for control. PC-controlled installations were forced to handle system crashes and unplanned rebooting. 2. Reliability: With rotating magnetic hard drives and non-industrially hardened components, such as power supplies, PCs were more prone to failure. 3. Unfamiliar Programming Environment: Plant operators need the ability to override a system for maintenance or troubleshooting. Using ladder logic, they can manually force a coil to a desired state, and quickly patch the affected code to quickly override a system. However, PC systems require operators learn new, more advanced tools.

Если дроссель на кольце, значит он без зазора? Если дроссель без зазора, значит, феррит в насыщении при больших токах нагрузки (DC). При этом его индуктивность мала, и через дроссель прут большие импульсные токи.

Вот в этом и дело, а не в "мировом сговоре МЭК с мегакорпорациями". Чем выше эта асинхронность (на одном проце), тем ниже надежность. Поэтому PLC стараются ее вообще не допускать, насколько возможно. Синхронно они работают, или почти синхронно. Здесь напрашивается аналогия с синхронным/асинхронным стилями разработки для ПЛИС. Не то чтобы асинхронно нельзя было бы сделать в принципе, можно, однако настоятельно рекомендуется его всеми силами избегать и делать все синхронно. Помнится, когда-то попадалась мне на глаза статья специалиста по QNX, живущего, как я понял, сейчас в Канаде. В которой не было ни капли телячьего восторга ни по поводу QNX, ни по поводу хард риал тайм вообще. Он там вполне так твердо доказывал, что принципиальной разницы между хард и софт риал тайм нет и не может быть, так что QNX от Выни в сущности ничем не отличается. Всех подробностей не помню, но одна мысль была примерно такая: чем наверченнее система, тем больше она отбирает ресурсов "на самоё себя", и тем выше вероятность, что когда-то она навернется. Поэтому, конечно, более простая QNX работает чуть понадежнее более сложной Выни. Пример приводился, когда реальная, годами эксплуатировавшаяся QNX система благополучно накрылась при определенном стечении обстоятельств, потому что персонал повадился на ней обсчитывать (с низким приоритетом, ессно) огроменные спредшиты (мол, все равно она недогруженная и супер-надежная). Ошибки есть в любом софте выше определенного уровня сложности. С дальнейшим ростом сложности кол-во ошибок нарастает, причем, вряд ли линейно. Дело даже не в неспособности человека писать код без ошибок. Дело в том, как их выявить, какими тестами. Для сложной системы формальное тестирование займет вечность, а неформальное не покроет всех вариантов входных воздействий. Вот и получается, что в сложных асинхронных системах полно ошибок, причем ошибок латентных, не проявляющих себя в "обычном" режиме. Поскольку эти "обычные" режимы как раз протестированы хорошо. Наверное, самый известный пример - авария Арианы, когда они перешли на новый носитель с большей тягой, а в момент старта подул хороший боковой ветер. Такие сравнительно простые псевдосинхронные системы, как PLC, могут быть протестированы досконально, и ведут себя предсказуемо. Потому что в синхронных системах "исчезает ось времени", все события происходят "одновременно". В отличие от softPLC и RTOS, что бы там маркетологи ни плели про их надежность. Для верхнего уровня распределенных систем чаще всего не трeбуется та надежность, которaя необходима "внизу", где работают PLC. Xотя бы из-за низкой надежности связи, а также из-за меньшей требуемой реактивности. Однако для них и softPLC непонятно зачем был бы нужeн, там "PLC-шность" и языки МЭК неуместны, имхо. Я же явственно назвал Аллен-Брэдли, нарочито обозвав остальных "сбродом". :) PS: Вы так выдeляeтe QNX в плане надежности, объясните, почему это oна надежнее DOS или той же Выни? Или она с открытым кодом (пока что только это выдавалось за волшебную палочку), а я просто не в курсе? C учетом того, что Вынь в ~80% случаев падает за счет хреновых драйверов (написанных бог весть кем, не мелкомягкими), расскажите, как в QNX пишутся драйверы, и за счет чего они будут безошибoчными. Или почему ошибки в драйверах не будут ронять QNX, хотя Линукс от них не то что падает, а частенько даже и не встает :) Может, в QNX все драйверы юзер мод, с кучей проверок? A как же с реактивностью быть? Чем для писателей кернел мод драйверов любая ось отличается от DOS-a (ведь правда не знаю, может, не догоняю чего-то)?

Надежностью отличается. Как это ни смешно... Хороший брэнд означает школу, т.е. аккумулированный и систематизированный многолетний опыт в предметной области, базирующийся на результатах труда поколений (хорошо оплачиваемых) инженеров. Еще он означает ответственность, которая вытекает из стабильности фирмы.

Угу. Если при 1ГГц он рассеивает 6W, то при 0.7ГГц, конечно, "даже не теплится" ;) Наверное, видели советский ВМ86? Никогда не обращали внимания, что, в отличие от i8086, у него DIP корпус был не сплошной, а состоял как бы из трех квадратиков, чем-то напоминая костяшку домино? У "фирменного" 8086 рассеивание было, помнится, 1Вт. А отечественный, в силу недостатков технологии, рассеивал чуть больше, около 1.2Вт. Так вот, при таком рассеивании "сплошной" корпус постепенно трескался вследствии термоударов при каждом включении, и проц сдыхал раньше времени. Тогда какой-то умелец (снимаю шляпу!) предложил делать "прорези" в кропусе, чтобы уменьшить тепловой стресс. Даже "фирменный" при 1Вт был горячий... Я, во многих случах - способен. "В чем секрет вашего мастерства?" (с) Может быть, техническая эзотерика вкупе с многолетней медитаций? :) Ладно, шутки шутками, но пора завязывать треп. Все это совершенно бесплодно. Тянутся такие разговоры аж с 60-х годов, со времен первых "кавалерийских наскоков" ЭВМ-щиков на пром автоматику. В конце 60-х появились PLC, только они оказались способны надежно работать в цеховых условиях и заменить релейные шкафы. И в 70-е тоже пытались "ЭВМ в цеха" ставить, и в 80-е, и даже с частичным успехом, однако в среднем - не прижились. С моей точки зрения, softPLC ничего в этом раскладе не меняют, и никакого нового слова не говорят. Еще одна реинкарнация пром-РС, которые появились всего-то на несколько лет позже самих писюков, и раздавали те же самые обещания. А заглянешь в цех серьезного завода (скажем, автомобильного) - где они? Нету. Стоят у любых более-менее серьезных пацанов в цехах на ответственных местах AB. Вот у виноделов, говорят, действительно, всякий сброд встречается, и Сименс, и Мицубиши, и даже Адвантек. Вы же на железнодорожниках своих поэксперементируйте, они стерпят, они и не такое терпели.

"Не надо пороть чушь, ей же больно" (с) Первая редакция ISO/OSI вышла в 1984г, когда Модбасу исполнилось уже лет 10, наверное. Вообще, Модбас - штука совершенно удивительная. У него, конечно, есть болячки и "родимые пятна". Однако просто поразительно, что разработчикам удалось заложить в него такие крепкие и добротные основы тогда, в далекие 70-е. Сколько после него всяких "передовых" интерфейсов возникло и сгинуло без следа, а старик все живет и здравствует. Попробуйте-ка, сваяйте свой протокольчик на RS485, и почти наверняка место ему будет на помойке, т.к. будет он сбоить безбожно, особенно в условиях индустриальных помех. И ни ISO/OSI не поможет, ни (тем более) куча RFC, которые понятием "помехоустойчивость" не оперируют вообще, просто не знают такого слова. А Модбас RTU, хоть не идеален, но с точки зрения помехоустойчивости сделан вполне правильно. Не лепится. В лучшем случае лепится имя "эмулятор", а в худшем (но более правдоподобном) - "симулятор". Угу. Вы еще скажите, что это врожденная и неустранимая ошибка в функции void main(void){ } к этому приводит. Наверное, "инверсия приоритетов" в ней, или какие-то еще боковые эффекты ;)

Нафига ((T1/T2)-0.5)/0.04 считать в плисине? Отправить измеренное T1 "наверх", в мелкоконтроллер или в писюк, пусть они считают чего им надо.