Перейти к содержанию
Поиск
    

=AK=

Свой
 Профиль  Обзор контента

  • Постов

    3 234

  • Зарегистрирован

  • Посещение

  • Победитель дней

    5

 Тип контента 

Сообщения, опубликованные =AK=

  1. Опубликовано · Пожаловаться

    Примеры тут ни при чем, тут надо стандарт смотреть, и там отыскивать фразу типа "ассемблером ПЛК должен быть язык IL"

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

     

    Кстати, не надейтесь, что излишнее цитирование придаст веса вашим высказываниям. Оно лишь свидетельствует, что вы не способны отделить главное от второстепенного.

  2. Опубликовано · Пожаловаться

    в ... PLC реализации сделать нельзя.

    Цитаты из 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.

  3. Опубликовано · Пожаловаться

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

  4. Опубликовано · Пожаловаться

    потому что такие взаимодействия требуют очень развитой асинхронности (параллелизма задач)

    Вот в этом и дело, а не в "мировом сговоре МЭК с мегакорпорациями". Чем выше эта асинхронность (на одном проце), тем ниже надежность. Поэтому 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 (ведь правда не знаю, может, не догоняю чего-то)?

  5. Опубликовано · Пожаловаться

    Чем, ну чем устройство на AMD186, под DOS-ом не ЭВМ! Где коренное отличие от других,

    Надежностью отличается.

    неужели бренд сам по себе придаёт надёжности в "цеховых условиях"!

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

  6. Опубликовано · Пожаловаться

    Зато нужны, например, Geode, которые на 700-800Мгц даже не теплятся (без каких либо средств охлаждения, естественно, за ненадобностью).

    Угу. Если при 1ГГц он рассеивает 6W, то при 0.7ГГц, конечно, "даже не теплится" ;)

     

    Наверное, видели советский ВМ86? Никогда не обращали внимания, что, в отличие от i8086, у него DIP корпус был не сплошной, а состоял как бы из трех квадратиков, чем-то напоминая костяшку домино? У "фирменного" 8086 рассеивание было, помнится, 1Вт. А отечественный, в силу недостатков технологии, рассеивал чуть больше, около 1.2Вт. Так вот, при таком рассеивании "сплошной" корпус постепенно трескался вследствии термоударов при каждом включении, и проц сдыхал раньше времени. Тогда какой-то умелец (снимаю шляпу!) предложил делать "прорези" в кропусе, чтобы уменьшить тепловой стресс. Даже "фирменный" при 1Вт был горячий...

     

    Вы способны по внешнему виду платы сказать, работают ли какие-то ее компоненты в режимах, близких к максимально допустимым?

    Я, во многих случах - способен.

    "В чем секрет вашего мастерства?" (с) Может быть, техническая эзотерика вкупе с многолетней медитаций? :)

     

    Ладно, шутки шутками, но пора завязывать треп. Все это совершенно бесплодно. Тянутся такие разговоры аж с 60-х годов, со времен первых "кавалерийских наскоков" ЭВМ-щиков на пром автоматику. В конце 60-х появились PLC, только они оказались способны надежно работать в цеховых условиях и заменить релейные шкафы. И в 70-е тоже пытались "ЭВМ в цеха" ставить, и в 80-е, и даже с частичным успехом, однако в среднем - не прижились. С моей точки зрения, softPLC ничего в этом раскладе не меняют, и никакого нового слова не говорят. Еще одна реинкарнация пром-РС, которые появились всего-то на несколько лет позже самих писюков, и раздавали те же самые обещания. А заглянешь в цех серьезного завода (скажем, автомобильного) - где они? Нету. Стоят у любых более-менее серьезных пацанов в цехах на ответственных местах AB. Вот у виноделов, говорят, действительно, всякий сброд встречается, и Сименс, и Мицубиши, и даже Адвантек. Вы же на железнодорожниках своих поэксперементируйте, они стерпят, они и не такое терпели.

  7. Опубликовано · Пожаловаться

    Modbus - это особая песня... это уже в то время, когда была проработана 7-ми уровневая модель ISO

    "Не надо пороть чушь, ей же больно" (с) Первая редакция ISO/OSI вышла в 1984г, когда Модбасу исполнилось уже лет 10, наверное.

     

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

     

    вот по такому примитивному формальному признаку: если PLC шкафу титулованного брэнда подменить PLC "голову", и оно всё продолжит работать и не поймёт, что его "подставили" - лепится это каким-то боком в гордое имя PLC, или не лепится?

    Не лепится. В лучшем случае лепится имя "эмулятор", а в худшем (но более правдоподобном) - "симулятор".

     

    Вам никогда не приходилось материться перед чёрным экраном висящего DOS?

    Угу. Вы еще скажите, что это врожденная и неустранимая ошибка в функции void main(void){ } к этому приводит. Наверное, "инверсия приоритетов" в ней, или какие-то еще боковые эффекты ;)

  9. Опубликовано · Пожаловаться

    Так об какой "надёжности" мы говорим?

    1. О надёжности "железки" PLC? чем она возрасла, от того, что AMD186 процессор затолкали в ящик под названием PLC?

    Как вершину айсберга, упомяну:

    -- Наработку на отказ, которая хоть много от чего еще зависит, но на нынешнем этапе развития техники прямо связана с наличием/отсутствием движущихся частей. Поэтому "супер-пупер быстрые и дешевые" пентюхи, рассеивающие полсотни ватт, в PLC никому не нужны, т.к. без вентиляторов работать не могут. Кроме того, наработка на отказ вообще находится в обратной зависимости от температуры компонентов. Быстрее проц --> больше потребление --> выше температура --> ниже надежность. Наконец, наработка на отказ в среднем находится в обратной зависимости от сложности изделия, т.е. от кол-ва компонентов и кол-ва связей между ними. Настоящие PLC имеют наработку на отказ (MTBF) порядка 10 лет, писюки и "пионэрские" недо-PLC - примерно на порядок меньше.

    -- Устойчивость к воздействию помех. Настоящие PLC примерно на порядок более устойчивы к помехам, чем бытовые писюки или недо-PLC.

     

    Как этого добиваются разработчики PLC - даже не каждому посвященному будет видно. Что дает простор шапкозакидателям для кудахтанья: "открыл фирменный дорогущий PLC, а там такое старье стоит, сейчас мы им революцию устроим". Вы способны по внешнему виду платы сказать, работают ли какие-то ее компоненты в режимах, близких к максимально допустимым? Например, при покупке ПК, обращаете ли внимание на то, что написано на электролитах, стоящих на материнке (температура, брэнд)? И способны ли сходу оценить температурный рельеф материнки в рабочем режиме, чтобы получить оценочное представление, сдохнет ли она через пару лет из-за высыхания электролитов, или будет служить 10+ лет без проблем?

     

    Еще мне вспоминается разговор с одним электронщиком из ЮАР, лет десять назад. Его фирма разрабатывала несложную электронику для автоматизации тех процессов, типа нормализаторов сигналов и т.п. Он рассказывал примерно так: "Вроде делаем все правильно, по науке. Смотрим, как наши конкуренты из японского Омрона делают, никакой особой разницы не видим. Начинаем испытывать на помехоустойчивость: наше устройство сбоит при 500В помехи, а омроновское - при 4кВ продолжает работать. Чудеса!" И ведь не чайник был, весьма грамотный инженер.

     

    хотя, как не странно, ведёт себя ПО похоже положениям теории надёжности.

    Я тоже так считаю. Чем сложнее - тем ненадежнее. Поэтому, если задача позволяет, в PLC лучше поставить простую однозадачную MS DOS, чем вынь или даже линукс. При этом желательно возложить на "основной" х86 проц вспомогательные задачи (связь, диагностика, и пр.), а пользовательскую прогу исполнять специализированным сопроцессором, то ли в виде PLC-on-Chip, то ли FPGA.

     

    Почему я должен считать, что в закрытом ПО закрытого PLC Siemens, Schneider Electric, etc. ... - скрытых внутренних ошибок меньше, чем в ОС Linux или QNX

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

     

    А надолго ли хватит на 100% функций оставшегося без "головы" PLC ... чтоб не "рвануло"

    Надолго. Тем более что в грамотно спроектированной системе эта ситуация является штатной. Например, что будет, если кабель связи с верхним уровнем ненароком обрезали? Только "пионэры" проектируют системы управления без учета деградации. Рванет если у самих PLC крышу снесет, и то, правильный PLC при этом сделает все возможное, чтобы встать и оставить свои выходы в предусмотренном заранее, "безопасном" с точки зрения объекта управления, состоянии.

     

    посмотрите ПО AutimationX для aXcontroller (soft PLC)

    Вот это, что ли http://www.mnrcan.com/xtreme_qa.phtml ? И каким боком это можно назвать PLC?

  10. Опубликовано · Пожаловаться

    Основной из которых - эксплуатационные издержки, сопровождаемость, стоимость разработки.

    Для PLC это не является доминирующими факторами. Главное - надежность, это окупает все. Раз вы этого не знаете, все ваши рассуждения на темы PLC не имеют ни капли смысла.

     

    Возможная задержка на сотню миллисекунд на "уборку мусора" для 95% приложений ПЛК роли не играет.

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

     

    Так ничего с 1997 года не изменилось, как IL был похож на сименсовского собрата, так и остался...

    Это не довод. Все IL-подобные языки похожи, это всего лишь ассемблер виртуальной машины, оптимизированной на исполнение LD. Все компании (включая Сименс) "срисовывали" LD и IL с того, что сделали основоположники PLC, т.е. Modicon и Allen-Bradley. С учетом того, что разработка IEC 61131-3 началась с доклада Allen-Bradley, разумнее предположить, что за основу IL и LD были взяты наработки этой компании.

     

    что это ассемблероподобный язык. Что (и это очевидно) это не ассемблер и смысла в таком низкоуровневом по сути языке нет.

    Еще раз, IL - это ассемблер виртуальной машины. А в некоторых PLC это настоящий ассемблер процессора. Даже без ссылки на старый Симатик S100, сейчас однокристальные процы заточенные на МЭК 61131-3 стали доступны (cм. PLC Chip164, PLCHIP-M2-12800 и др). Не надо бредней про "отсутствии такого соответствия". Это в вашем Рефлексе смысла нет, никому он не нужен.

     

    Зачем мне пытаться кого-то убеждать, что на ассемблере программировать не надо? Это действительно глупо!

    Несмотря на то, что убеждать кого бы то ни было в ненужности программировать на ассемблере (в том числе на мэковском IL) действительно очень глупо, вы многократно пытались это сделать, в том числе в своих статьях.

     

    Кстати, спросите у эмбедщиков, как они к Паскалю относятся... ;-)

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

  11. Опубликовано · Пожаловаться

    А смогу ли я добиться уменьшения его разрядности предварительно поделив где-то внешний клок. И затем синхронизировать счетчик от него? Наверно это или еще один счетчик

    Конечно. Какжый разряд счетчика требует одного триггера ресурсов. И в этом смысле неважно, делит ли этот триггер входной клок или входит в состав другого счетчика, ресурсы в общем-то те же.

     

    Однако становятся важными другие обстоятельства. Если все работает от одного клока, то меньше вероятность ошибок, а софт может легко выловить ошибки во времянках. Поэтому лучше клок не делить, если можно.

     

    И вообще где-нибудь можно глянуть текст кода VHDL: делитель частоты больше чем на два?

     

    ...
signal counter14 : unsigned(13 downto 0);
...
my_cnt14_p:process(Clk, counter14)
begin
  if rising_edge(Clk)
    counter14 <= counter14 + "00000000000001";
  end if;
end process;

  12. Опубликовано · Пожаловаться

    Ну зачем же сразу GPS, антенны эти ставить, погоду хорошую ловить. Можно обойтись обычным рубидиевым генератором.

    Причем здесь погода? И зачем нужен невесть-какой-дорогой рубидиевый генератор, если можно обойтись дешевым GPS-ом?

  13. Опубликовано · Пожаловаться

    А какая версия Циклона 2 у вас? Имеется ввиду версия силикона. Есть версия А, с багами, и версия В, поправленная.

    Не знаю, не обращал внимания.

     

    Синхронизация ТХ и RX сделана так: у ТХ tx_outclock Divide factor = 10. Т.е. предполагается, что на каждые 10 бит данных будет 1 перепад клока. И ресивер сможет правильно "нарезать" входной битовый поток, зная, что на 10 бит есть 1 перепад клока.

    Синхронизация между чипами должна передаваться отдельной линией. Если передавать "родную" частоту, придется прокладывать еще одну LVDS линию. Можно передавать частоту, поделенную на 8 или на 10, тогда удастся обойтись одиночным сигналом (CMOS), однако на приемном конце придется использовать PLL, а также точно настроить сдвиг фазы, чтобы биты сэмплировались посередине битового интервала.

     

    Насчет того, как приемный поток нарезается на куски по 8 или 10 бит. Насколько я знаю, ALTLVDS нарезает как ему бог на душу положит. Я так и не смог найти, как заставить его синхронизировать байтную нарезку в нужный мне момент времени.

  14. Опубликовано · Пожаловаться

    Усиливать все равно придется, явно или неявно. Даже если на гираторах будете делаеть - ОУ будете использовать. А чем гираторы лучше, чем те же самые ОУ в качестве усилителя, а уж потом фильтр? Ничем.

  15. Опубликовано · Пожаловаться

    Почти наверняка человеку нужна не абсолютная точность измерения, а разрешение. Если нужна именно абсолютная точнось в доли ppm, то проще всего для задания интервала измерения использовать секундные импульсы от GPS.

  16. Опубликовано · Пожаловаться

    Ваши заявления про утечку памяти интересны, но неубедительны.

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

     

    Опять Вы про этот IL и STEP5. Разумеется, у меня нет стенограмм заседаний МЭК, где представители Сименс предлагали включить IL в МЭК.

    Это не я "опять". Посмотрите свою статью 2005 года "Программирование ПЛК: языки МЭК 61131-3 и возможные альтернативы", там примерно половина текста скопирована из первой статьи 98 года ("автоплагиат" своего рода). Включая измышления о том, что IL произошел от STEP5. Причем подано в безапелляционной форме, поэтому кто-то принимает за чистую монету. Свои аргументы против я привел ранее, ищите где-то на 4-й странице этого топика.

     

    попытайтесь убедить окружающих, что программировать ПЛК надо на ассемблере

    То есть, на IL? Вы уже оскомину всем набили своими глупыми нападками на IL. Скачайте книгу http://www.fen-net.de/karlheinz.john/Bookview.htm, там подробно написано какой МЭК-овский язык для чего используется. (ST+IL) в PLC образуют такую же пару, как (C+ассемблер) при программировании микроконтроллеров. Попытайтесь эмбедщиков убедить, что на С им можно писать, а на ассемблере и на смеси С+ассемблер нельзя, так вас засмеют, и правильно сделают.

     

    Кстати, в этой книге есть немного истории создания МЭК-овского стандарта.

  17. Опубликовано · Пожаловаться

    К сожалению, ООП для этого класса задач просто не подходит...
    У меня нет опыта работы с PLC, но из всего Вами описанного не следует неприменимость ООП в том или ином виде для решения задач PLC.

    Конечно не следует. ООП в PLC почти не применяется по совсем иным причинам.

     

    сделать несложный транслятор с этого языка в нечто ООП. И метаязык, и транслятор надо стандартизовать, и тогда это PLC

    Нет, от стандартизации мало что зависит. Устройство можно назвать PLC только если оно работает надежно. ООП в смысле надежности имеет не только плюсы (программу писать/отлаживать быстрее), но и минусы (требует больше памяти и производительности проца, а "вкусности" ООП вроде сборки мусора вообще загоняют надежность и предсказуемость поведения в болото). Минусов больше, поэтому в PLC обычно не применяется.

     

    конкурентная борьба - главная причина появления МЭК 61131-3. Возможно, что Сименс, АББ и т.д. (см. список авторов МЭК) как раз ООП-"революции" испугались...

    Вот где собака зарыта во всей это МЭК философии!!!

    Чушь это, бред и паранойя. Причины лежат на поверхности. PLC многие годы развивались сами по себе, без МЭК. Однако у пользователей были проблемы с программированием: диалекты PLC языков разных производителей сильно отличались друг от друга. МЭК свел всю эту разноголосицу воедино, в результате производительность труда программистов-пользователей возросла.

     

    Нда, надо будет как-нибудь революцию во всем этом PLC мире устроить.

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

     

    Какие из моих утверждений, Вам кажутся бредовыми?

    Долго перечислять, много их. Про "тайные мотивы" МЭК и PLCopen пишите бред, про МЭК языки - бред, про ООП в PLC - бред (см. выше), про языки программирования "вообще" - тоже бред, часто противоречивый (то можно С/С++/Паскаль и пр. применять для автоматизации, то нельзя), и т.п.

     

    Вы, например, про то, что IL произошел от STEP5, пишите начиная с 1997 года, но ни разу не назвали источник этой информации. Вот и сейчас не назвали, вместо этого зубы заговариваете, перескакивая на похожесть. Вам что, Armin Steinhoff сказал году так в 96-м при личной встрече, что МЭК взял IL из STEP5, проигнорировав соответствующие языки других производителей? А он откуда это знает, он же специалист по QNX, а не по истории создания МЭК языков? Давайте, признавайтесь, где эту сплетню подхватили, и почему она заслуживает доверия.

  18. Опубликовано · Пожаловаться

    Длина провода на частоте 480 МГц ограничена лишь его индуктивными свойствами. Слишком длинный провод будет иметь на такой частоте весьма высокое сопротивление.

    Нет, она не ограничена ни "емкостными" ни "индуктивными" свойствами как таковыми. Идеальная длинная линия может быть сколь угодно длинной. Длина реальной длинной линии ограничивается потерями в линии и неоднородностью линии. На низких частотах больше влияют потери и наведенные помехи. Из-за потерь сигнал ослабляется, так что в очень длинной линии приемник не сможет выделить сигнал из шумов и помех. На высоких частотах больше влияют неоднородности линии. Из-за неоднородностей возникают частичные отражения в линии, с увеличением длины форма сигнала все больше искажается, так что приемник в конце концов становится неспособным выделить сигнал из этого "звона".

     

    В USB2 сигнал передается по одному и тому же кабелю в обе стороны. Задержки между приемом и передачей должны быть малы, и кабель длиной более 5м может оказаться непригодным из-за слишком большого времени распространения сигнала по нему. Если считать, что в кабеле скорость распространения равна, скажем, 20см за 1нс, то 5м кабель даст задержку в 25нс в один конец. То есть, передатчик послал сообщение, а потом должен будет переключиться на прием и 50нс слушать - отвечают с того конца или нет. С учетом задержек в микросхемах и пр. ему на самом деле приходится слушать еще дольше. Это "мертвое время", его нельзя делать большим, иначе снизится эффективность работы USB2. Так что 5м - это некий компромисс.

  20. Опубликовано · Пожаловаться

    На генераторе тока, выполненном на основе LM317, будет падение напряжения не менее 2.5В (если схема "правильная") или даже 3.75В (если схема включения плохая). Действительно, неэкономично. Однако лучше всего не заморачиваться преобразователем напряжения, а решать саму задачу питания светодиодов. Для чего надо просто повысить экономичность генератора тока.

     

    Генератор тока по приведенной ниже схеме требует падения напряжения менее 1В. То есть, если его применить, то даже при 12В питании экономичность может оказаться выше, чем в случае с LM317 при питании от 24В.

    post-2483-1146023109_thumb.jpg

  22. Опубликовано · Пожаловаться

    2. По какой причине может быть не готов пакет? (устройство несколько раз отвечает NAK)

    Устройство не успело подгрузить/выгрузить кусок данных в/из буфера. Для USB2 это обычное дело, больно интерфейс шустр. Устр-во при этом сначала отвечает NYET, хост начинает его пинговать, а устр-во NAKает пока не будет готово (это для USB2, в USB1 пингов не было, там запрoс шел по полной программе).

×
×
  • Создать...