=AK=
-
Постов
3 279 -
Зарегистрирован
-
Посещение
-
Победитель дней
5
Сообщения, опубликованные =AK=
-
-
Modbus - это особая песня... это уже в то время, когда была проработана 7-ми уровневая модель ISO
"Не надо пороть чушь, ей же больно" (с) Первая редакция ISO/OSI вышла в 1984г, когда Модбасу исполнилось уже лет 10, наверное.
Вообще, Модбас - штука совершенно удивительная. У него, конечно, есть болячки и "родимые пятна". Однако просто поразительно, что разработчикам удалось заложить в него такие крепкие и добротные основы тогда, в далекие 70-е. Сколько после него всяких "передовых" интерфейсов возникло и сгинуло без следа, а старик все живет и здравствует. Попробуйте-ка, сваяйте свой протокольчик на RS485, и почти наверняка место ему будет на помойке, т.к. будет он сбоить безбожно, особенно в условиях индустриальных помех. И ни ISO/OSI не поможет, ни (тем более) куча RFC, которые понятием "помехоустойчивость" не оперируют вообще, просто не знают такого слова. А Модбас RTU, хоть не идеален, но с точки зрения помехоустойчивости сделан вполне правильно.
вот по такому примитивному формальному признаку: если PLC шкафу титулованного брэнда подменить PLC "голову", и оно всё продолжит работать и не поймёт, что его "подставили" - лепится это каким-то боком в гордое имя PLC, или не лепится?Не лепится. В лучшем случае лепится имя "эмулятор", а в худшем (но более правдоподобном) - "симулятор".
Вам никогда не приходилось материться перед чёрным экраном висящего DOS?Угу. Вы еще скажите, что это врожденная и неустранимая ошибка в функции void main(void){ } к этому приводит. Наверное, "инверсия приоритетов" в ней, или какие-то еще боковые эффекты ;)
-
Нафига ((T1/T2)-0.5)/0.04 считать в плисине? Отправить измеренное T1 "наверх", в мелкоконтроллер или в писюк, пусть они считают чего им надо.
-
Так об какой "надёжности" мы говорим?
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?
-
Основной из которых - эксплуатационные издержки, сопровождаемость, стоимость разработки.
Для 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 индустрию, отношусь плохо.
-
А смогу ли я добиться уменьшения его разрядности предварительно поделив где-то внешний клок. И затем синхронизировать счетчик от него? Наверно это или еще один счетчик
Конечно. Какжый разряд счетчика требует одного триггера ресурсов. И в этом смысле неважно, делит ли этот триггер входной клок или входит в состав другого счетчика, ресурсы в общем-то те же.
Однако становятся важными другие обстоятельства. Если все работает от одного клока, то меньше вероятность ошибок, а софт может легко выловить ошибки во времянках. Поэтому лучше клок не делить, если можно.
И вообще где-нибудь можно глянуть текст кода 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;
-
Ну зачем же сразу GPS, антенны эти ставить, погоду хорошую ловить. Можно обойтись обычным рубидиевым генератором.
Причем здесь погода? И зачем нужен невесть-какой-дорогой рубидиевый генератор, если можно обойтись дешевым GPS-ом?
-
А какая версия Циклона 2 у вас? Имеется ввиду версия силикона. Есть версия А, с багами, и версия В, поправленная.
Не знаю, не обращал внимания.
Синхронизация ТХ и RX сделана так: у ТХ tx_outclock Divide factor = 10. Т.е. предполагается, что на каждые 10 бит данных будет 1 перепад клока. И ресивер сможет правильно "нарезать" входной битовый поток, зная, что на 10 бит есть 1 перепад клока.Синхронизация между чипами должна передаваться отдельной линией. Если передавать "родную" частоту, придется прокладывать еще одну LVDS линию. Можно передавать частоту, поделенную на 8 или на 10, тогда удастся обойтись одиночным сигналом (CMOS), однако на приемном конце придется использовать PLL, а также точно настроить сдвиг фазы, чтобы биты сэмплировались посередине битового интервала.
Насчет того, как приемный поток нарезается на куски по 8 или 10 бит. Насколько я знаю, ALTLVDS нарезает как ему бог на душу положит. Я так и не смог найти, как заставить его синхронизировать байтную нарезку в нужный мне момент времени.
-
Усиливать все равно придется, явно или неявно. Даже если на гираторах будете делаеть - ОУ будете использовать. А чем гираторы лучше, чем те же самые ОУ в качестве усилителя, а уж потом фильтр? Ничем.
-
Почти наверняка человеку нужна не абсолютная точность измерения, а разрешение. Если нужна именно абсолютная точнось в доли ppm, то проще всего для задания интервала измерения использовать секундные импульсы от GPS.
-
Ваши заявления про утечку памяти интересны, но неубедительны.
Про утечку памяти я ни слова не сказал. Что за манера приписывать что-то другим, а потом с умным видом это опровергать.
Опять Вы про этот 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+ассемблер) при программировании микроконтроллеров. Попытайтесь эмбедщиков убедить, что на С им можно писать, а на ассемблере и на смеси С+ассемблер нельзя, так вас засмеют, и правильно сделают.
Кстати, в этой книге есть немного истории создания МЭК-овского стандарта.
-
У меня нет опыта работы с PLC, но из всего Вами описанного не следует неприменимость ООП в том или ином виде для решения задач PLC.К сожалению, ООП для этого класса задач просто не подходит...Конечно не следует. ООП в PLC почти не применяется по совсем иным причинам.
сделать несложный транслятор с этого языка в нечто ООП. И метаязык, и транслятор надо стандартизовать, и тогда это PLCНет, от стандартизации мало что зависит. Устройство можно назвать PLC только если оно работает надежно. ООП в смысле надежности имеет не только плюсы (программу писать/отлаживать быстрее), но и минусы (требует больше памяти и производительности проца, а "вкусности" ООП вроде сборки мусора вообще загоняют надежность и предсказуемость поведения в болото). Минусов больше, поэтому в PLC обычно не применяется.
Вот где собака зарыта во всей это МЭК философии!!!конкурентная борьба - главная причина появления МЭК 61131-3. Возможно, что Сименс, АББ и т.д. (см. список авторов МЭК) как раз ООП-"революции" испугались...
Чушь это, бред и паранойя. Причины лежат на поверхности. PLC многие годы развивались сами по себе, без МЭК. Однако у пользователей были проблемы с программированием: диалекты PLC языков разных производителей сильно отличались друг от друга. МЭК свел всю эту разноголосицу воедино, в результате производительность труда программистов-пользователей возросла.
Нда, надо будет как-нибудь революцию во всем этом PLC мире устроить.Валяйте, пробуйте. Вон, китайцы вроде Адвантека и др. уж который год пытаются, и все равно их сравнительно дешевые поделия серьезного успеха в консервативном мире PLC не имеют. "Дешевка - она и есть дешевка" (с)
Какие из моих утверждений, Вам кажутся бредовыми?Долго перечислять, много их. Про "тайные мотивы" МЭК и PLCopen пишите бред, про МЭК языки - бред, про ООП в PLC - бред (см. выше), про языки программирования "вообще" - тоже бред, часто противоречивый (то можно С/С++/Паскаль и пр. применять для автоматизации, то нельзя), и т.п.
Вы, например, про то, что IL произошел от STEP5, пишите начиная с 1997 года, но ни разу не назвали источник этой информации. Вот и сейчас не назвали, вместо этого зубы заговариваете, перескакивая на похожесть. Вам что, Armin Steinhoff сказал году так в 96-м при личной встрече, что МЭК взял IL из STEP5, проигнорировав соответствующие языки других производителей? А он откуда это знает, он же специалист по QNX, а не по истории создания МЭК языков? Давайте, признавайтесь, где эту сплетню подхватили, и почему она заслуживает доверия.
-
Длина провода на частоте 480 МГц ограничена лишь его индуктивными свойствами. Слишком длинный провод будет иметь на такой частоте весьма высокое сопротивление.
Нет, она не ограничена ни "емкостными" ни "индуктивными" свойствами как таковыми. Идеальная длинная линия может быть сколь угодно длинной. Длина реальной длинной линии ограничивается потерями в линии и неоднородностью линии. На низких частотах больше влияют потери и наведенные помехи. Из-за потерь сигнал ослабляется, так что в очень длинной линии приемник не сможет выделить сигнал из шумов и помех. На высоких частотах больше влияют неоднородности линии. Из-за неоднородностей возникают частичные отражения в линии, с увеличением длины форма сигнала все больше искажается, так что приемник в конце концов становится неспособным выделить сигнал из этого "звона".
В USB2 сигнал передается по одному и тому же кабелю в обе стороны. Задержки между приемом и передачей должны быть малы, и кабель длиной более 5м может оказаться непригодным из-за слишком большого времени распространения сигнала по нему. Если считать, что в кабеле скорость распространения равна, скажем, 20см за 1нс, то 5м кабель даст задержку в 25нс в один конец. То есть, передатчик послал сообщение, а потом должен будет переключиться на прием и 50нс слушать - отвечают с того конца или нет. С учетом задержек в микросхемах и пр. ему на самом деле приходится слушать еще дольше. Это "мертвое время", его нельзя делать большим, иначе снизится эффективность работы USB2. Так что 5м - это некий компромисс.
-
Схему не увидел :-(
В окошке есть внутри прямоугольника стрелочка, показывающая влево. Это ссылка на цитируемый пост. Кликните на нее.
-
На генераторе тока, выполненном на основе LM317, будет падение напряжения не менее 2.5В (если схема "правильная") или даже 3.75В (если схема включения плохая). Действительно, неэкономично. Однако лучше всего не заморачиваться преобразователем напряжения, а решать саму задачу питания светодиодов. Для чего надо просто повысить экономичность генератора тока.
Генератор тока по приведенной ниже схеме требует падения напряжения менее 1В. То есть, если его применить, то даже при 12В питании экономичность может оказаться выше, чем в случае с LM317 при питании от 24В.
-
MAX275? http://www.maxim-ic.com/quick_view2.cfm/qv_pk/1452
Правда, всего 100Hz - 300kHz
-
2. По какой причине может быть не готов пакет? (устройство несколько раз отвечает NAK)
Устройство не успело подгрузить/выгрузить кусок данных в/из буфера. Для USB2 это обычное дело, больно интерфейс шустр. Устр-во при этом сначала отвечает NYET, хост начинает его пинговать, а устр-во NAKает пока не будет готово (это для USB2, в USB1 пингов не было, там запрoс шел по полной программе).
-
-
B Циклонe 2 использую ALTLVDS RX, cкорость > 400 Mbps, проблем нет.
Почему Вы используете только ALTLVDS TX? Как синхронизировaны TX и RX?
-
Проще всего использовать буфер с хорошей нагрузочной способностью, например 74xx373, 74xx573 ( xxxИР22).
-
В несогласованной линии надо смотреть, насколько отражения влияют на обмен.
Например, пусть передатчик и один приемник находятся с противоположных сторон линии, несогласованной с одного конца. Если линия несогласована на передающем конце, это ни на что не повлияет, т.к. отражений все равно не будет. Если линия несогласована на приемном конце, то отраженный сигнал "бьет" по передатчику, однако хорошему передатчику это по барабану, так что тоже ни на что не влияет.
Теперь добавим в линию еще один приемник, но поставим его рядом с передатчиком. В "плохом" случае, когда линия несогласована со стороны, противоположной передатчику, этот второй приемник "увидит" сигнал ступенчатой формы. Первую ступеньку дает сигнал от передатчика, вторую - отраженный сигнал. В худшем случае приемник сработает не по первой ступеньке, а по второй, т.е. с опозданием. Время опоздания пропорционально длине линии. Очевидно, это заставит нас снизить частоту переключений до такой величины, чтобы отраженный фронт приходил не в середине битового интервала, а существенно раньше, например, на 2/5 битового интервала.
Выбор 2/5 (или 1/3, или 1/4, или 1/10) довольно произволен. Если приемник берет одну выборку сигнала в середине битового интервала, как обычный UART в PC, то это должно быть меньше 1/2, чтобы вторая ступенька успела прийти чуть раньше момента выборки. Однако что мешает сделать приемник, который брал бы выборку, скажем, в точке 3/4 битового интервала? Тогда макс. длину несогласованной с одного конца линии можно было бы увеличить примерно на четверть.
Скажем, для бодовой скорости 9600 (битовый интервал чуть больше 100 мкс) и обычного UARTа "эхо" должно закончиться не позднее чем через 50 мкс (это чуть меньше 1/2 битового интервала). Если бы сигнал распространялся в вакууме, то макс. длина несогласованной с одного конца линии не должна была бы превышать 7.5 км. Для кабеля скорость будет меньше, скажем, всего 2/3 от скорости света в вакууме, и макс. длина уменьшится до 5 км.
Если линия несогласована с обоих концов, то в линии без потерь при полном отражении каждый фронт сигнала будет звенеть вечно, и по такой линии вообще ничего передать нельзя, какой короткой бы она ни была и как бы медленно мы ни передавали. К счастью ;) все реальные линии обладают потерями, а отражение не полное. Однако абстрактно считать для этого случая довольно муторно и долго, проще померять живьем.
-
Кажется, нашел в чем мулька. Похоже, что во втором случае он "воровал" результаты предыдущей компиляции вместо того чтоб заново компилировать. Кроме того, я в какой-то момент удалил ассайнмент "cut timing path" с одного из сигналов, но не до конца, и он стал глобальным. Как выяснилось, "cut timing path" не соответствует своему имени, как я понял, это команда не фиттеру (мол, сделай задержки поменьше), а анализатору ("не обращай внимания"). Так что репорт получился липовый c такой настройкой.
Вообще, удивительно дерьмово сделан Assignment Editor, хрен поймешь что делает та или иная настройка и как ею правильно пользоваться.
-
Компилирую проект для Cyclone II в двух вариантах, все настройки сделаны на макс. скорость. Ничего не меняю кроме настройки фиттера:
1. Fitter settings --> Standard Fit (highest effort)
Standard Fit will use maximum effort to achieve the highest design performance.
Bремя компиляции проекта ~40 min, получаю 61% использования ресурсов. Timing Analyser не ругается (нет critical warnings), однако в Slow Model есть одна нестыковочка по времени.
2. Fitter settings --> Auto Fit (reduce Fitter effort after meeting timing requirements)
Auto Fit adjusts the fitter optimization effort to minimize compilation time, while still achieving the design timing requirements.
Bремя компиляции проекта ~4 min, получаю 48% использования ресурсов. Timing Analyser не ругается (нет critical warnings), и в Slow Model тоже все OK.
Почему, блин?
-
Ограничения связаны в основном с двумя параметрами:
-- с задержкой распространения сигнала (из-за конечной скорости света), примерно 1нс на 30см длины
-- с емкостью проводника, которая зависит не только от длины, но и ширины, а также от окружения.
Длина может быть в общем-то любой, т.к. физически невозможно изготовить плату такого размера, чтобы длины проводников начали сказываться на такое сравнительно медленное устройство, как сигналовский проц. Для примера, в USB2 при скорости 480 Мбит/сек макс. длина проводника (кабеля) равна 5м.
-
В смысле, с компатором ничего интерполировать-вычислять не надо, потому он хуже? Типа, куражу нет? :)
Когда не нужна ОС РВ?
в Операционные системы
Опубликовано · Пожаловаться
Угу. Если при 1ГГц он рассеивает 6W, то при 0.7ГГц, конечно, "даже не теплится" ;)
Наверное, видели советский ВМ86? Никогда не обращали внимания, что, в отличие от i8086, у него DIP корпус был не сплошной, а состоял как бы из трех квадратиков, чем-то напоминая костяшку домино? У "фирменного" 8086 рассеивание было, помнится, 1Вт. А отечественный, в силу недостатков технологии, рассеивал чуть больше, около 1.2Вт. Так вот, при таком рассеивании "сплошной" корпус постепенно трескался вследствии термоударов при каждом включении, и проц сдыхал раньше времени. Тогда какой-то умелец (снимаю шляпу!) предложил делать "прорези" в кропусе, чтобы уменьшить тепловой стресс. Даже "фирменный" при 1Вт был горячий...
"В чем секрет вашего мастерства?" (с) Может быть, техническая эзотерика вкупе с многолетней медитаций? :)
Ладно, шутки шутками, но пора завязывать треп. Все это совершенно бесплодно. Тянутся такие разговоры аж с 60-х годов, со времен первых "кавалерийских наскоков" ЭВМ-щиков на пром автоматику. В конце 60-х появились PLC, только они оказались способны надежно работать в цеховых условиях и заменить релейные шкафы. И в 70-е тоже пытались "ЭВМ в цеха" ставить, и в 80-е, и даже с частичным успехом, однако в среднем - не прижились. С моей точки зрения, softPLC ничего в этом раскладе не меняют, и никакого нового слова не говорят. Еще одна реинкарнация пром-РС, которые появились всего-то на несколько лет позже самих писюков, и раздавали те же самые обещания. А заглянешь в цех серьезного завода (скажем, автомобильного) - где они? Нету. Стоят у любых более-менее серьезных пацанов в цехах на ответственных местах AB. Вот у виноделов, говорят, действительно, всякий сброд встречается, и Сименс, и Мицубиши, и даже Адвантек. Вы же на железнодорожниках своих поэксперементируйте, они стерпят, они и не такое терпели.