Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - shkiper

Страницы: [1] 2 3
1
всем день добрый
вопрос по подключению промышленного оборудования - тестомесы в пекарне
в устройство приходят три фазы и земля (ноль не приходит)
внутри 3-х фазный трансформатор с выводом нейтрали (т.е. эта штука изображает из себя ТП в которую по высокой стороне приходят 3 фазы, и ноль выводиться из средней точки тр-ра)
основные силовые агрегаты в устройстве - два 3-х фазных двигателя, так что им этот тр-р не нужен, но есть так же еще  панель управления, пару датчиков и электромагнит (на 60 Ватт)
и все это питается от 24 VDC, который берется с моста, подключенного на  выводы тр-ра, "нейтраль" (закороченная с землей) и выход обмотки 24 VAC

вопрос: надо ли подключать этот агрегат через диф. автомат?
схема  заземления TN-C-S

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

потому-что есть проблема, особенно в системах ориентированных на "умный дом" или на подключение оборудования в котельной - большой нагрузки они не любят
когда ПЛК обрабатывает 20 параметров это одно, когда несколько тысяч это другое
обработка происходит в основном по протоколу Modbus, по интерфейсу RS-485

вы скажете - как же так, этот протокол и интерфейс как раз и были созданы для опроса множества датчиков
и таки да будете правы, даже не очень мощный ПЛК способен принять огромное число параметров Modbus
так в чем же дело?
дело в том, что при больших объемах информации которую надо запросить, принять, обработать и передать, нужны принципиально другие механизмы, чем при малых

при при опросе датчиков есть два варианта:
1) простой
2) правильный

в общем все как обычно :)

представьте вам нужно просто опросить датчик, мы обращаемся к ПЛК или к датчику, сначала передаем данные для установки подключения, потом запрос чего надо, потом та сторона ищет (если это ПЛК), потом передает этот кусок данных
если параметров немного, то это нормально, если их много, то становится грустно
вы начинаете искать решение, и т.к. вы не одиноки в этой ситуации, то на профильном форуме вам подскажут, что есть специальное ПО (библиотеки и т.п.), для того что-бы опрашивать датчики быстрее, т.е. за раз скачивать информацию большим куском по нескольким датчикам и разбирать ее на нужные куски при получении, в общем нырнуть с головой туда, куда не собирался и специально для этого покупал "готовое решение"
начнете возмущаться, а вам в ответ - "не мы такие, жисть такая", "без труда, не выловишь рыбку из пруда" и т.п.
вы начнете:
1) увеличивать скорость шины, а это сразу надо увеличивать ее на счетчиках и датчиках (т.е. например при замене, нельзя будет просто достать датчик или счетчик из коробки и послать монтажника, надо будет устройство сначала подключить, настроить)
2) настраивать тайм-ауты опроса везде где можно, а что значит таймаут в 20 секунд при опросе показаний тока или 20 секунд задержки на опрос состояние геркона?

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

я на эти грабли наступил, решение было, но я его просто не тянул, сделал все по "простому", отложил на "потом"
хотя в моем случае проблема была наполовину решена на стороне ПЛК

суть проблемы - при больших объемах данных, эти данные получают не опросами по маленьким кусочкам, а потоком
если вы пытаетесь заместить поток кучей маленьких запросов, то вы огорчитесь результатом
например, вы смотрите IP TV, ваш телевизор не запрашивает каждый кадр у сервера, авторизуясь и устанавливая соединение каждый раз, сервер просто выдает видеопоток и ему по барабану принят он или нет и сколько там вообще клиентов - поток один широковещательный, вашему телевизору надо просто подписаться на него один раз в начале

и такие-же механизмы есть и для работы с датчиками
называется MQTT - очередь сообщений, суть в том что на ПЛК все принимаемые показания с датчиков сразу кидаются в поток и выставляются на IP порт (как фильм или сайт)
можно MQTT опрашивать и командой по отдельным параметрам, но это то сразу тормоза описанные выше
и я уж начал было огорчаться, когда понял, что нужно достаточно глубоко погружаться в программирование чтоб разобраться в этих делах
как вдруг пришла помощь "свыше", Zabbix объявил о поддержке MQTT в очередной версии, это решило проблему сразу, т.е. не нужно утомлять ПЛК миллионом запросов, не надо выставлять таймауты
при том что ПЛК прилично загружены и скорость по шине 9600, все данные теперь приходят сразу
пошла в рост нагрузка - сразу график пошел вверх, выбило автомат или открыли дверь - сразу отразилось в системе
пришлось переписывать все шаблоны на уже работающей системе
и появилось проблема куда девать все эти данные?
потому что столько много (по многим параметрам несколько раз в секунду прилетает) и не надо, приходится отсекать лишнее, но это уже решаемо


3
дальше мой частный случай
при переезде производства (пекарня) в новое здание
обеспечить мониторинг потребления электро-энергии и производственных процессов
начальник сразу говорит - проекта не будет, но время есть
все что есть, это  планы расстановки оборудования и расчет потребляемой мощности

причем что-бы рассчитать мощность на новом месте, надо сначала ее подсчитать на старом, т.к. там "исторически сложившаяся" ситуация - три ввода, никакого мониторинга (хотя попытка была, на одном шкафу в ВРУ, на боковине несколько шт Меркуриев-230, руководитель рассказал, что была попытка на их основе сделать учет, но "не взлетело")
нагрузка круглосуточная и в течении суток цикличная, для заявки на новом месте нужна была пиковая мощность за сутки
я к тому времени выбирал между Овен и Wiren Board, предложил как-раз проверить оборудование - купить небольшой комплект от WB: ПЛК, счетчик и накладные ТТ
и проверить его на подсчете суточного потребления на каждом из вводов
купили, проверили, в общем понравилось
сразу заработало, для простых задач в наличии простые начальные настройки через веб-интерфейс, подключение через wi-fi
очень понравился счетчик и накладные ТТ
сам ПЛК показался слабоват для промышленного применения, а его веб интерфейс однозначно не пригоден для этого
я в начале писал, что в это направление приходят разные люди, так вот, что касается категории "компьютерных людей", то они падки именно на WB
потому что это открытое ПО, Линукс, возможность устанавливать на ПЛК любое ПО
в общем поставил я на данном бренде свой "одобрямс"

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

в общем с приборами учетом определился
общую схему системы решил делать по схеме: датчик (счетчик) - ПЛК - сервер мониторинга

в качестве сервера  мониторинга который будет собирать информацию со всех ПЛК (их получилось не один) и отображать пользователям в нужном виде - Zabbix
это бесплатная, популярная система
учитывать решили всю нагрузку:
- по вводам (их по плану на новом месте тоже 3 шт)
- нагрузку распределения - по каждому РЩ, на которые идет кабель из ВРУ
- нагрузку по производству - некоторое оборудование по которому надо отслеживать режим работы (в комплексе с мониторингом других параметров)

т.е. счетчиков много (3-х фазные 4-х канальные счетчики от WB как раз в тему) и они разнесены в пространстве
одного ПЛК недостаточно, взял сразу два
нагрузка на них оказалась сразу приличная - по 3-4 4-х канальных счетчика на каждый (в стандартном шаблоне один 4-х канальный счетчик передает 340 параметров на ПЛК, а еще к ним же кроме счетчиков  подключаются и другие датчики), предположение что ПЛК слабоваты подтвердилось практикой
шаблон поставил попроще (Basic), там 180 параметров на счетчик
в общем, в случае с WB, 4 4-х канальных счетчика это предел для контроллера (это в сумме 16 3-х фазных линий), больше уже совсем тяжко ему будет

кроме мониторинга энерго-потребления, поставил модули вводов на ПЛК, и подключил к ним сигнальные контакты почти всех автоматов в ВРУ и многих в РЩ, а также гергоны на:
- входную дверь в ВРУ
- двери шкафов в ВРУ
- двери некоторых РЩ

герконы на дверях, это вообще очень полезная вещь, как оказалось

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


4
выбираем ПО, оно бывает двух видов:
1) Платное
2) Бесплатное

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

5
у меня проходка в здание сухая
капает из под брони
решил сначала выкопать колодец рядом с ТП, для откачки воды
потом потихоньку раскопать вход в ТП, и посмотреть внимательно на кабели свои

6
кабельный ввод, кабель - АВБбШв 4х185, бронированный
идет по траншее (свежая, в прошлом году закапывали, старались все соблюдать - песок снизу, песок сверху, потом кирпичи)
входит в здание, потом идет в подвал, там ВРУ
разделан через муфту (муфта - самая низкая точка кабеля, включая ТП)
и вот из под муфты закапала вода, в прошлом году летом и этой зимой не капала
ТП рядом, открыли посмотреть - там разделано без муфты, но разделка не утоплена
но воды много, откачали воду - капать перестало (не сразу, еще сутки покапало и перестало)
вопрос - что в таких случаях делать?
пока работает, не стреляет
подозреваю что повреждение где-то на вводе в ТП, но там трудно что либо увидеть

7
есть же муфты специальные, и в т.ч. с поводками заземления

8
Давненько к нам Artem_ASU не заходил. Уже целый месяц. Наверное, это его темы.
Я тут как раз сейчас работаю с более приземленной тематикой, но связанной с облачным сервером OWEN Cloud. С его помощью можно настроить общение с любым устройством этой фирмы, имеющим RS-485, используя специальное устройство - шлюз. В фильме "Устройство управляющее многофункциональное ПР200" этот шлюз на первых кадрах мелькает, с антеннкой Wi-Fi.
Так вот, мое мнение...
Облачный сервер это хорошо. Но там, где есть устойчивый интернет. И работать он сможет только с теми величинами, по которым надо принимать мгновенные решения. Например, не дай Бог там PID-регулятор какой-нибудь запрограммировать. Данные приходят с опозданием. А если мы говорим о серьезных системах, то местами реакция на ситуацию должна быть мгновенной.
А в остальном - почему бы и нет, если вам надо управлять чем-то с мобильного телефона, то облако реальный выход.
Пы.Сы. озвучивается мнение дилетанта в данном вопросе.
ну свет в дому включить и шторки открыть, можно и с облаком и без
а схемы на производстве с исполняющими механизмами, конечно должны быть локальны и автономны, их не то что в облако, а даже чересчур умным ПЛК доверять не следует, желательно использовать устройства с аппаратной обработкой логики
т.е. облака, это про мониторинг и учет
у меня опыт с автоматизацией (применительно к производству) не большой, но есть мысли
столкнувшись с этой темой, я увидел у разных людей разные подходы и разные страхи относительно "облаков"

1) профессионалы - люди с профильным образованием, работают по профилю (ПЛК Сименс и т.п.), им эти облака по барабану, их зовут в проект, где все уже заранее заложено - ПЛК, модули, сервера, диспетчерские места и т.п., и куда, и для чего это ставить - это все предусмотрено в проектной документации

2) практики, люди уже имеющие опыт работы с Owen и т.п., собирают щиты с ПЛК, умные дома, зачем нужны эти облака им тоже не совсем понятно, ну раз оно идет вместе с Owen, и есть бесплатный функционал, то можно попробовать

3) компьютерные люди (это я), имеют опыт с облаками в смежных областях и поэтому их побаиваются :), более склонны к организации мониторинга у себя, т.к. это уже знакомо и отработано применительно к сетям и серверам и т.п.

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

а вот касательно применения облаков в АСКУЭ и АСУТП, тут другие расклады
здесь надо принять решение, размещать мониторинг у себя или пользоваться облаком?
это надо сделать с точек зрения и тех. специалистов, и руководителя
а для руководителя это черный ящик (и с облаками, и без), и он например смотрит - "а как у всех"?
например бух. учет нынче все чаще пользуют в облаке, виртуальные АТС популярны
и предлагаемые здесь преимущества по сравнению с вариантом размещения серверов у себя аналогичные:
1) экономия на ресурсах - не надо покупать железо и разворачивать свою инфраструктуру
2) девиз всех модных экспертов - "все непрофильные активы в аутсорсинг!", всю работу по обеспечению функционала на себя берет облако, вам не нужны эти непонятные парни, которые чего-то там настраивают

недостатки тоже понятны:
1) это привязка к одному производителю, все датчики и прочее оборудование должны быть одной фирмы или совместимы
2) проблемы с тех. поддержкой, особенно если объект в регионе
3) скорость и возможность подключения новых узлов, если для этого надо платить, то сначала надо доказать директору, потом оплатить ...

а бывает, что надо собрать схему на "попробывать", и не ясно - будет ли у нее дальнейшее развитие
в общем тоже есть о чем подумать

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

сначала нам нужен сервер, он должен быть надежный и отказоустойчивый
отказоустойчивость, в компьютерной всей теме обеспечивается методами дублирования узких мест
т.е. логикой организации системы, само железо конечно тоже добавляет (говорят - 5% примерно, и если наши сервера будут новые за 1 млн. руб. и более каждый - это тоже очень хорошо :) )
например два блока питания в сервере или поставили второй жесткий диск, объединили два диска в "зеркало" и у нас уже дисковая система надежна - выход одного диска из строя не влечет потерю данных
но сервер собранный таким образом получится очень дорогим и все равно будет не надежен, поэтому просто возьмем хороший комп (или недорогой сервер) и продублируем его вторым таким же (как что там будет конкретно дублироваться разберем позже), обеспечим сервера современными твердотельными дисками
и подключим к нашей системе мониторинга и сервера тоже
целых два сервера, надо их подпереть бесперебойником, самый разумный вариант купить ИБП типа "онлайн" (с двойным преобразованием), он позволит в случае потери электропитания, обеспечить работу от бытового бензо-генератора, практически неограниченное время (мощности онлайн ИБП 3000 ВА с режимом "конвертера", т.е. поддержание частоты 50 Гц на выходе, достаточно для обеспечения работы пары серверов и 5 компьютеров )
для возможности подключения к ИБП нескольких компьютеров по сети и мониторинга его состояния поставим в него сетевой модуль и так же подключим к мониторингу
этого в плане железа, вполне достаточно

теперь про ПО, нам понадобится:
1) Операционная система для серверов
2) сервер мониторинга
3) схема архивации

один важный момент, установка рабочего сервера (сервера мониторинга в нашем случае) непосредственно на железный сервер это "шарман и моветон", так уже не делается
гораздо разумней использовать виртуальные сервера, т.е. сервер как бы есть, но физически он представляет файл на жестком диске
в таком виде он гораздо мобильней (его можно легко архивировать или перенести на другой компьютер), он не привязан к конкретному железу,  ни к ОС железного хоста, ни к конфигурации программ на нем, т.е. этот момент тоже влияет на надежность
например, мы настраиваем сервер мониторинга и сохраняем его копию на втором сервере
и в случае чего, вуаля - наш бронепоезд стоит на запасном пути
а с данными как, копия сервера, устареет уже к тому времени?
вот мы плавно подошли  к вопросу архивации
вообще это замечательный проверочный вопрос, на тот случай если вас агитируют перейти на какое-нибудь облако
узнать кот с вами говорит, человек который реально что-то понимает или просто менеджер?
задать вопрос:
- а как у вас происходить обеспечение отказоустойчивости данных и в частности - архивация, при условии, что сервис (доступ к данным) должен функционировать круглосуточно, в режиме 24/7?

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

ну а если у вас, сервер месте с данными занимает немного места, и раз в неделю его можно и остановить на 5 минут, то можно и совсем просто, без изысков - автоматизировать процесс создания архива всего сервера сразу, вместе с данными  и запускать архивацию по расписанию

ну вот и все, осталось выбрать вариант ОС для серверов и ПО сервера мониторинга
это может быть платный проприетарный вариант, так и бесплатное свободное ПО
выбор за вами :)

ах да, надо еще парней найти, которые все это настроят :)
продолжу, чуть позже

и как подключать все наши датчики и ПЛК к нашему серверу тоже придумаем, это в принципе самый простой вопрос

9
предлагаю обсудить общие вопросы возникающие при принятии решения по организации вопросов про сервера, облака и т.п.

10
9) Поставить модули ввода-вывода с запасом. По максимуму, сколько можно. Допустим, одно устройство сбора данных тянет 8 моделей - ставить все восемь. Чтобы был резерв по дискретным входам, выходам и аналоговым сигналам. Потом проще будет что-то новое ввести в систему.
по моему это уже конкретика, т.е. это уже после того как выбрали определенную систему, уже знаем какие модули брать

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

но "сосед электрик", сделает все так, что потом автоматизацию уже не впихнешь

в такой ситуации, есть характерные моменты:
1) отсутствие плана конечно увеличивает сроки реализации (в средне-срочной перспективе), т.е. что-то мелкое может и можно быстро сделать, но чуть покрупнее - логистика, перебор вариантов, покупка не сразу того что надо и т.п.
2) выходит дороже (ставим лотки и РЩ с запасом по размеру, куча деталей про запас и "не взлетевших" вариантов)
3) обязательно что-то будет переделываться, иногда по нескольку раз
4) реакция профильных контор (нет плана четкого и "семь пятниц на неделе") - не любят они таких клиентов

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



11
есть тенденция , что элементы АСУТП становятся все более доступными
и их внедрение все чаще идет не по проекту или плану, который долго и дорого делали
а по мере необходимости, с помощью вполне доступных компонентов

или вот пример, был проект по кап. ремонту 4-5 летней давности, в т.ч. и кап. ремонт электро-хозяйства
там что-то такое было заложено, и вот этот проект созрел до тендера, но частями устарел и требует корректировки
и сейчас не понятно, надо это вообще делать (всякие там АСКУЭ и АСУТП) или не стоит?
в общем монтаж делать уже надо, а что делать с автоматизацией пока непонятно, но может быть в недалеком будущем и утвердят ее целесообразность

какие общие моменты при монтаже, хорошо бы предусмотреть, чтоб потом можно было бы до установить и подключить, компоненты учета и мониторинга состояния например?

вот что приходит сразу:
1) предусмотреть место в щитах, для монтажа доп оборудования или даже дополнительные щиты и шкафы
2) расстояние между рядами динреек, если стандартное 130, то при использовании накладных ТТ для мониторинга нагрузки,  получится тесно, я например делал 170, может это и перебор
3) сразу обеспечить сигнальными (или аварийными) контактами автоматы, состояние которых предполагается мониторить (потом это сложно, особенно в больших автоматах, где это надо монтировать внутрь корпуса), вывести сигнальные провода на отдельный ряд клемников
4) предусмотреть землю для слаботочки, как минимум - отдельные шины заземления
5) предусмотреть автоматы питания для автоматики (и например небольшие шинные блоки, откуда будут брать фазы счетчики)
6) протянуть ко всем РЩ витую пару от сетевого коммутатора или от какой-то планируемой "точки концентрации", или предусмотреть трассы (смонтировать отдельные кабель-каналы или лотки) для слаботочки
7) прикинуть нужна-ли будет еще слаботочка для (RS-485, провода к ТТ и т.д.), и прокинуть ее
8 ) планировать сразу документирование сети - и электро, и всей слаботочки сразу в том виде, в котором она будет готова к использованию в ПО мониторинга

13
прошу про комментировать требование в проекте прокладки кабелей в трубах, например:
Цитировать
В кабинетах к выключателям, установленным на стене со стороны дверной
ручки на высоте 1.5 м. от уровня пола – в штрабах по месту. Применять провод
марки ВВГнгFRLS – 3х1.5 мм2 в металлической трубе. К светильникам рабочего
освещения провод марки ВВГнгFRLS – 3х1.5 мм2. От ВРУ1 и ПР№1.1 к щитам
распределительным проложить кабели марки ВВГнгFRLS – 5х2.5 мм2 в
металлических трубах скрыто по месту.
по моему что-то намутили, провод с кабелем точно перепутали (да и выключатели в школах должны быть на 1,8м, нашел в одном СП), подскажите, где еще есть нестыковки в этом требовании?
я думал , что трубы открыто крепятся ну или за перегородками, подвесными потолками и т.д., но скрывать их в штробы, по моему перебор

еще упоминаются "замоноличеные трубы" но я не нашел четкого определения, что это такое

14
какой чудесный монтаж
надо отодвинуть обои на первом фото, чтоб саморез был виден хорошо
не удивлюсь, если он там не просто так, а заменяет болтовое соединение и через него подключен еще провод

15
Есть трехфазный двигатель 11 кВт. Нужно выбрать к нему питающий кабель.
Не долго думая, я выбрал для него сечение кабеля 2,5 мм2 по токовой нагрузке I= Sдв/(корень(3)*Uл*cosfi*n)=11000/(1.73*380*0.9*0.85)=21 А <  25 А (для кабеля 2,5  квадрата)
Мне сделали замечание, что для него нужен кабель 4-6 квадратов. Из каких соображений делается подобный выбор?
электродвигатель это особенный вид нагрузки, при разгоне он потребляет в 3-5 раз больше номинала, кратковременно конечно (но если его что-то тормозит, то может и не кратковременно)
и cosfi = 0.9, это оптимистичный прогноз, это верхний предел
у меня в среднем получается 0,75 (в пределах 0,5 -0,9), это цех с эл. машинами (там в основном ЭД, ну еще свет), для расчета взял отрезок времени несколько часов, потребляемая цехом активная мощность средняя за этот период - 11 КВт
итого по формуле получаем 26А, плюс запас на разгон
и плюс качество кабеля, так что на короткое расстояние - 4 мм2, это минимум того что нужно

Страницы: [1] 2 3