Пожелания к SMLogix'у

[Николай Ушаков]

наверное кто долго работает с этой logix'ом уже привык, но есть в нем фишки, которые делают работу с ним не такой приятной
1 передвижение по рабочему полю, возможно же наверное сделать перемещение нажатием колесика мышки - типа как в автокаде
2 невозможно передвинуть группу обьектов - ужасно неудобно, каждый раз перетаскивать кучу блоков, кстати и сетка есть, а выравнивания по ней нет...
3 нет отмены действий - случайно удалил какой то блок с кучей связей, да еще и автоматом нажал Ctrl+S, и все - можешь убить себя головой ап стену

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

[AlexG]

Кто-ж вам мешает программировать SMH на ассемблере, Си и вообще чем угодно для чего сможете найти компилятор?

Если добавлять дополнительные языки, то, вероятно, стоит посмотреть на SFC, как это сделано у Крузета со Шнайдером. Довольно удобно оказалось писать программы на смеси SFC и FBD. Можно бысто описать последовательность действий алгоритма на SFC, а сами действия уже программировать на FBD.

[Николай Ушаков]

то есть можно программировать SMH каким то другим редактором? можно поподробнее пожалуйста, какими, как...

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

[AlexG]

Основа SMH - микроконтроллер ATmega128, соответственно, для программирования подходят любые компиляторы для AVR. Нет никакой существенной разницы между написании программы на C для SMH и для любого другого изделия на этих микроконтроллерах. "биос" это приятное, но совершенно не обязательное дополнение. Компиляторов масса, самые мощные и развитые это IAR EWAVR и WINAVR (GCC).

Есть правда одно большое НО. Для контроллеров класса SMH программирование на С (а также С++, Pascal, Basic, asm) мягко говоря нецелесообразно (хотя мы этим занимались и занимаемся). Получается слишком большая трудоемкость написания и отладки программы по сравнению со специализированными языками.

[Николай Ушаков]

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

[Arsie]

Думаю, по трудоёмкости создания программ, лоджику ещё очень далеко до кодесиса. Даже если принимать во внимание его огрехи в интерфейсе с пользователем.

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

В будущей версии (3.17) драг-н-дроп уже есть, осталось только внедрить управление группами в структуру.

[Николай Ушаков]

возможно LAD и FBD в кодесисе и оставляют желать лучшего, но зато там есть ST, основные алгоритмы в нем, а все вместе через LAD, но это все конечно споры насчет вкуса и цвета...
но вот такие фичи как HMI(без специальных дополнений к программе) и симулятор дают большое преимущество при отладке.
а когда планируется выпустить версию 3.17?

[SMH]

Сообщение от Николай Ушаков

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

Х.З. Мне вот кодесис нахер не нужен, лоджик хотя и имеет некоторые неудобства, но это, на мой взгляд, дело привычки... Если работать в нём постоянно, проблемы типа "невозможности группового перемещения ФБД" не являются особо значимыми. И Овен этот... достаточно почитать их форум на сайте... Когда у меня изредка появляется желание купить контроллер Овен "на пробу", я так и делаю. Желание сразу пропадает. Хотя, ради справедливости, следует признать, что за время производства ПЛК ОВЕН проделана громадная работа по доведению ПО для него до ума.
У меня вызывает большое уважение стратегия Сегнетикса при продвижении своей продукции - по возможности не выпускать "сырых продуктов". Овен в этом плане "нервно курит за углом".

Сообщение от Николай Ушаков

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

??? Много - это сколько именно? По моей оценке, все недоработки Лоджика укладываются в увеличение времени разработки среднестатистической программы на 2-3 рутинных часа, не более.

[Николай Ушаков]

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

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

[AlexG]

Я тоже очень уважаю Сегнетикс, но считаю что над SMLogix нужно еще работать и работать. А пока при выборе контроллеров для очередного проекта, если контроллеры примерно равны по основным параметрам, я выбираю тот, который удобнее программировать.

[Arsie]

Сообщение от Николай Ушаков

возможно LAD и FBD в кодесисе и оставляют желать лучшего, но зато там есть ST, основные алгоритмы в нем, а все вместе через LAD, но это все конечно споры насчет вкуса и цвета...
но вот такие фичи как HMI(без специальных дополнений к программе) и симулятор дают большое преимущество при отладке.
а когда планируется выпустить версию 3.17?

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

Сообщение от Николай Ушаков

симулятор дают большое преимущество при отладке.

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

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

Что касается симуляции в лоджике: сделать эффективный симулятор нам пока не под силу. А на полуфабрикат силы тратить не хочется.

Сообщение от Николай Ушаков

а когда планируется выпустить версию 3.17?

Уже скоро. Бета-версии проходят масштабное тестирование. Но копи-паста я там не обещаю.

[LordN]

Сообщение от Arsie

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






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

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

Что касается симуляции в лоджике: сделать эффективный симулятор нам пока не под силу. А на полуфабрикат силы тратить не хочется.






Уже скоро. Бета-версии проходят масштабное тестирование. Но копи-паста я там не обещаю.

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

[vladun]

Мне нравится симулятор у LOGO!, лучше не видел пока.
ЗЫ: но там "файла" фсякого в паке установки... наверное составляющие симулятора ???

[Arsie]

У нас есть более приземлённая цель: пошаговое выполнение программы в контроллере. Осилим к следующей версии лоджика.

Думаю, вполне с успехом заменит симуляцию

[Николай Ушаков]

удобство симулятора именно в том что для отладки не требуется контроллер.
тем более кто давно работает с лоджиком блоки свои по большей части отладил, а новички будут больше мучиться от неудобства интерфейса(по себе сужу )
лучше добавьте копи-паст, групповое перемещение, да отмену действий

[АндрейХ]

Сообщение от AlexG

Я тоже очень уважаю Сегнетикс, но считаю что над SMLogix нужно еще работать и работать. А пока при выборе контроллеров для очередного проекта, если контроллеры примерно равны по основным параметрам, я выбираю тот, который удобнее программировать.

Совершенно согласен с данным товарищем. По железу Pixel очен удачен, для полного счастья не хватает только модуля аналоговых входов и что-бы была поддержка всех термометров сопротивления и желательно термопар. В ПО одним из основных режимов отладки является режим эмуляции как в of-line on-line. Хоть и желателен, но не обязателен реал-тайм. Главное адекватная эмуляция. Это черезвычайно важно при отладке системы на действующем объекте где всё решают минуты и недопустимы гадания на кофейной гуще, и поиск багов в слепую...
Это я говорю из опыта использования nano-PLC Mitsubishi ALPHA XL, CROUZET Millenium III, и еще сейчас SIEMENS LOGO! v6.
Качественное ПО разработки это 90% успеха как производителя так и интегратора ПЛК! ПО должно быть лаконичным, т.е. не перегруженным FBD-блоками, т.е. должна быть возможность формирования библиотеки, что не используется то прячется. Имхо за шесть лет использования нано-ПЛК для систем малой автоматизации пришли к выводу что вполне достаточно целочисленной 16-битной арифметики за малым исключением 32-битная целочисленная, и ни разу не потребовалась арифметика с плавающей запятой, косинусы, синусы, тангенсы и т.д. А вот что нужно так это для аналоговых сигналов низкоуровневые FBD-блоки: фильтры первого порядка (демпфирование), а не макрос, блоки ограничений сигналов, блок зоны нечувствительности, блок нелинейных преобразований X->Yс выбором до 10-и реперных точек (например преобразование перепада давления в расход для сужающего устройства, и т.д.), блок дискретизации с заданием шага дискретизации, например с шагом 5 - X=1,2,3,4,5,6,7,8,9,10... -> Y=5,10... Есть у вас "баги" (эта не ваша вина а МЭК) например в блоке интегратора имеется грубая недоработка, нет ограничений интеграла по максимуму и минимуму, приходится городить огород, а без ограничения вы получите неработающий ПИ-ПИД регулятор с очень плачевными результатами вплоть до аварий (хорошо если без жертв ). Должна быть возможность задания мин. и макс. как внешне переменными, константами или с дисплея, так и внутренними константами. Можно еще привести кучку недостающих для КИПиА функцианальных блоков, при этом выкинув кучу ненужных блоков.
Вааще-то минимальный набор FBD-блоков достаточно хорошо описан в книге Петров И.В. Программируемые Контроллеры Глава 8. но вот с интегралом и у него, а точнее в МЭК засада. Так-же нужен блок дифференциатора с аналогичными ограничителями и нормальный ПИ и ПИД регуляторы. Например самый удачный на сегодня вариант ПИ-регулятора реализован в LOGO! v6 с выдачей тренда прям около блока как в режиме эмуляции так и в режиме он-лайн. Весьма недурственно в совковские времена была реализована библиотека алгоблоков для РЕМИКОНТ-130, в интернете можно найти документацию по данному устройству.
Надеюсь что тема будет конструктивно развиваться. Самое главное имхо, это ориентация ПО разработчика на КИПовцев с ПТУшным и колледжным образованием (а не на программёров) без заморочек со всякими таргетами, конфигурированием, согласованием как у ОВЕНа, т.е. максимально приближенный к стилю "plug and play" и тогда спрос на сей гаджет будет расти.

[Arsie]

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

Нужен ПИД с ограничением - есть макрос. Нужен дифференциал с ограничением - блок дифференциала + блок ограничителя Мин-Макс...

[АндрейХ]

Сообщение от Arsie

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

Нужен ПИД с ограничением - есть макрос. Нужен дифференциал с ограничением - блок дифференциала + блок ограничителя Мин-Макс...

А то я не знаю что такое макрос и посмотрел все имеющиеся макросы... Они съедают массу ресурсов и так не шибко быстрого ПЛК, тогда как низкоуровневые FBD будут шустрее и менее глючны (при правильной реализации). Имхо макросы нужны не для реализации недостающих FBD, а для реализации алгоблоков законченных устройств, например алгоблок управления группой насосов, и т.д. и т.п. А создание макросов для реализации недостающих блоков это крайность для слабых ПЛК. :p

[Arsie]

У "слабых" две проблемы: малО быстродействие и мАло памяти.

Это, как правило, порождает две крайности: попытка освободить память приводит к урезанию функциональности и попытка освободить быстродействие приводит к урезанию свободной памяти, т.е. функциональности.

Вы, на мой взгляд, больше тяготеете ко второй крайности. Причём не всегда обоснованно.

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

Реализация всего и вся на FBD приведёт к тому, что под программу останется мизер памяти. Память будет занята под ненужные вам в текущей задаче функции.

[АндрейХ]

Сообщение от Arsie

Реализация всего и вся на FBD приведёт к тому, что под программу останется мизер памяти. Память будет занята под ненужные вам в текущей задаче функции.

Я не разработчик но знаю что существует множество вариантов создания исполняемого кода. В частности целевая компиляция с использованием библиотеки блоков используемых в конкретной прикладной программе. Есть варианты где используется только единожды тело кода блока, а потом в программе только экземпляры блоков. И т.д.
А макрос он и есть макрос, как минимум в FBD не оптимизированный (избыточен) на исполнение и в конечном счете более громоздкий чем аналог на ассемблере или на IL. Как компромиссное решение может быть редактор FBD-блоков на IL с возможностью тестирования и интеграции в пакет разработчика. Такая фича есть в CoDeSys. Тогда и у разработчика голова не болит и у интегратора руки развязаны. Главное установить чёткие "правила игры".

[AlexG]

Вам не кажется что КИПовцы из ПТУ и разработка FBD-блоков на языках низкого уровня плохо сочетаются?
В принципе, возможность подключить дополнительные FBD-блоки могла бы быть полезна как компромис между расходом памяти и функциональностью. Но для SMH это не так важно как для Millenium 3, где память кончается оччень быстро.

[Arsie]

Алекс меня опередил, это был мой следующий вопрос

Если стремиться к универсальности кодесиса, то пожно попросту купить лицензию на сам кодесис и не мучать разработчиков. Одна незадача, при всей своей универсальности и "редактируемости" блоков ядро кодесиса для AVR займёт практически всю память процессора SMH2010.

А если вспомнить, насколько кодесис "тяжеловесен" и в интерфейсе, то лоджик уже не кажется таким уж "гадким утёнком". Вполне взрослый продукт. И главное - при всех его недостатках им очень легко пользоваться.

[АндрейХ]

Сообщение от AlexG

Вам не кажется что КИПовцы из ПТУ и разработка FBD-блоков на языках низкого уровня плохо сочетаются?
В принципе, возможность подключить дополнительные FBD-блоки могла бы быть полезна как компромис между расходом памяти и функциональностью. Но для SMH это не так важно как для Millenium 3, где память кончается оччень быстро.

По поводу памяти. У Millenium III памяти было на 250 FBD-блоков с чётким расчетом времени исполнения (программа двухпроходная Nms x 2). Расширение библиотеки производится по необходимости автоматически при добавлении блока из расширенной библиотеки в программу пользователя, а в контроллере находится только базовая библиотека. В последней модификации ПЛК CROUZET сделал до 700 FBD-блоков что на мой взгляд избыточно. Практика показывает что для SAS (систем малой автоматизации) достаточно 300-350 блоков без учёта сети и меню терминала (дисплея). По поводу разработки FBD-блоков, желательно оба варианта:
1. Заказные по ТЗ заказчика (естественно за деньги) FBD-блоки, если интегратор сам не в состоянии их разработать.
2. Инструмент разработки, тестирования и интеграции FBD-блоков для тех кто способен их разработать. Этот-же редактор используется для создания заказных FBD-блоков.
По поводу того кто должен программировать контроллеры. Однозначно специалист электрик и (или) КИПиА. Для этого и был сначала разработан язык LD, причём практически одновременно с IL при создании первого промышленного ПЛК. LD идеально вписывался в концепцию текстовых терминалов без каких либо дополнительных доработок, не требовалась даже псевдографика I----N----II-----<Y>-I При программировании ПЛК нужны не знания программирования, а знания по ПУЭ и КИПиА, а программирование на ЯВУ ПЛК сродни чтению и (или) созданию электричеких схем. Для создания программ достаточно иметь знания по основам ПУЭ и КИПиА, документацию на программирование.
Создание программ по принципу электрических схем является фундаментальным для промышленных ПЛК, и тот-же Сименс и Митсубиси строго придерживаются этого правила в течении более чем сорока лет. Конечно имеется возможность создания программ на IL и ST, но это скорее вспомогательные языки для "кусков" программы, которые затруднительно реализовать на LD и FBD. Если Сигнетикс это не поймет то не получит широкого круга пользователей до тех пор пока не создаст ПО на уровне того-же LOGO!comfort, с удобным интерфейсом и не перегруженный всякими "фичами" как CoDeSys. Закон прост: время - деньги. Чем меньше тратится времени на изучение ПО и написание на нём пользовательских программ с адекватным предсказуемым исполнением (без неприятных глюков) тем больше покупателей.
По поводу всяких Си, диалектов Бэйсика и т.д. Есть целый ряд специализированных ПЛК в которых программирование производится на Си, Бэйсике и т.д. (например B&R), но они скорее всего предназначены для АСУ, а не для "полевых" локальных ПЛК. Пришлось мне сталкнуться с программистами на B&R, ребята которые отлично знают Си, шпарят строки в лёт, но не знающие даже как работает термометр сопротивления (я уже молчу про определение характерной точки установки датчика на объекте измерения (регулирования), подключения и проверки датчика) не говоря уже про понятия о САУ... Ну и какая тут нафиг может быть качественная автоматизация. Вот и получается что к такому контроллеру нужно прикладывать пару спецов - программёра и инженера КИПиА, а такая роскошь не позволительна для малышек nano-PLC.
Отступление по поводу программёр-КИПовец - это редчайший зверек занесенный в красную книгу. А если честно то я не видел такого настоящего спеца, либо спец программёр, либо спец КИПовец, либо никакой программёр-КИПовец.

[АндрейХ]

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

[Max2114]

Сообщение от AlexG

Вам не кажется что КИПовцы из ПТУ и разработка FBD-блоков на языках низкого уровня плохо сочетаются?
В принципе, возможность подключить дополнительные FBD-блоки могла бы быть полезна как компромис между расходом памяти и функциональностью. Но для SMH это не так важно как для Millenium 3, где память кончается оччень быстро.

А вот у меня возник вопрос... ведь во время компиляции проекта в SMlogix в конечном итоге мы получаем исполняемы код? Я правильно понимаю? Почему бы не дать возмодность писать fbd блоки на каком либо языке (типа IL) и потом его компилировать в конечный исполяемы код? От этого разве увеличится место, занимаемомое ядром СМлоджика?
Хочу еще вот что добавить:
1. Я прекрасно понимаю компанию Сегнетикс, которая сделав ставку на Конструктор и Pixel пренебрегла усоврешенствованием Смлоджика, по причине бОльшей доходности от Pixelа и конструктора, так как это увеличило продажи данных продуктов.
2. Более удобный Смлоджик, с возможностью тестировать программы без контроллера, и включенным в установку PID реуглятором несомненно даст дополнительных покупателей, НО не так быстро и не сразу много, как по сравнению с эффектом от конструктора.
Подведу итог: Хочу пожелать компании Сегнетикс как можно скорее добить конструктор и реэсэмэйыч, и уже взяться как следует за Смлоджик и сделать из него полноценный продукт. Тогда будут довольны все.

[Arsie]

Сообщение от Max2114

А вот у меня возник вопрос... ведь во время компиляции проекта в SMlogix в конечном итоге мы получаем исполняемы код? Я правильно понимаю? Почему бы не дать возмодность писать fbd блоки на каком либо языке (типа IL) и потом его компилировать в конечный исполяемы код? От этого разве увеличится место, занимаемомое ядром СМлоджика?

Нет, в итоге получаются таблицы, которые "проходит" ядро SMLogix.

Сообщение от Max2114

Хочу еще вот что добавить:
1. Я прекрасно понимаю компанию Сегнетикс, которая сделав ставку на Конструктор и Pixel пренебрегла усоврешенствованием Смлоджика, по причине бОльшей доходности от Pixelа и конструктора, так как это увеличило продажи данных продуктов.

Прямо в точку

Сообщение от Max2114

2. Более удобный Смлоджик, с возможностью тестировать программы без контроллера, и включенным в установку PID реуглятором несомненно даст дополнительных покупателей, НО не так быстро и не сразу много, как по сравнению с эффектом от конструктора.
Подведу итог: Хочу пожелать компании Сегнетикс как можно скорее добить конструктор и реэсэмэйыч, и уже взяться как следует за Смлоджик и сделать из него полноценный продукт. Тогда будут довольны все.

Планы именно такие и именно в такой последовательности

[АндрейХ]

Обращаюсь к представителям Сегнетикса (по никам я не знаю кто есть кто, да и в подписях нет ссылок)
Меня на данный момент интересуют такие вопросы:
1. Есть ли фирмы в Москве торгующие продукцией Сегнетикса?
Если есть то хотелось-бы адресок с телефончиком. (в интернете ничего нет).
2. Если нет режима эмуляции в off-line то есть-ли оно в on-line?
Если в on-line можно видеть сработки сигналов то насколько всё это юзабельно?
2.1 Какова скорость компиляции и перезагрузки проекта в секундах?
2.2 Сколько раз можно безболезненно перезагружать проект?
В некоторых типах контроллеров с расширенным ОЗУ можно это делать быстро и бесконечное кол-во раз (например в ПЛК ОВЕН), и только после отладки записывать в ПЗУ.
2.3 В режиме on-line высвечиваются-ли логические сигналы цветом?
2.4 Выводятся текущие значения переменных около FBD-блоков?
2.5 Можно ли активировать дискретные входы кликом мыши, или только физически внешним сигналом?
2.6 Возможен ли оперативный вывод трендов с выбором точек аналоговых сигналов в программе?
2.7 Как ведет себя ПО и ПЛК при изменении данных в ПЛК не с компьютера, а например с дисплея ПЛК?
(Например у Mitsubishi ALPHA XL сразу рвётся связь on-line и выдаётся ошибка, по этому можно менять данные только с компа. И если потом в ПЛК меняли данные с дисплея возникают проблемы связи с компьютером из-за несовпадения значения данных).
3. На сколько проблематично создать сетевую систему с один мастер- много слайв ПЛК?
К сожалению мы не имеем опыта для работы в открытых сетях (делали сетевой ОПС на "БОЛИД", но это другое дело, там модули надо соединить витой парой и запрограммировать адреса, дальше система сама знает что делать с сетью, остается только конфигурировать приборы. Ну млин система тормозная... )
4. Предполагается использование безпроводных радио каналов на "Невод-5". Будет сеть работать?
Далее возможно возникнут дополнительные вопросы. :p
С уважением Андрей. ООО "Системы Автоматики".

[Arsie]

Сообщение от АндрейХ

Обращаюсь к представителям Сегнетикса (по никам я не знаю кто есть кто, да и в подписях нет ссылок)
Меня на данный момент интересуют такие вопросы:
1. Есть ли фирмы в Москве торгующие продукцией Сегнетикса?
Если есть то хотелось-бы адресок с телефончиком. (в интернете ничего нет).

Хм... Обратиться в sales@segnetics.com пробовали?

Сообщение от АндрейХ

2. Если нет режима эмуляции в off-line то есть-ли оно в on-line?
Если в on-line можно видеть сработки сигналов то насколько всё это юзабельно?

Если программа маленькая, то юзабельно, если большая, то чем хуже связь с контроллером, тем менее юзабельно. Самое зло - это программа 2500 блоков и связь 9600. Обновление экрана будет длиться около 2 минут.

Сообщение от АндрейХ

2.1 Какова скорость компиляции и перезагрузки проекта в секундах?

У меня на компьютере компонует примерно 5 секунд, на соседнем компьютере около полуминуты. Компьютеры одинаковы.

Загрузка также зависит от качества связи и размера программы. Аппаратная скорость перезаписи памяти около 1 кб/сек, всего до 64 кб.

Сообщение от АндрейХ

2.2 Сколько раз можно безболезненно перезагружать проект?
В некоторых типах контроллеров с расширенным ОЗУ можно это делать быстро и бесконечное кол-во раз (например в ПЛК ОВЕН), и только после отладки записывать в ПЗУ.

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

Сообщение от АндрейХ

2.3 В режиме on-line высвечиваются-ли логические сигналы цветом?

Цифрами.

Сообщение от АндрейХ

2.4 Выводятся текущие значения переменных около FBD-блоков?

Цифрами.

Сообщение от АндрейХ

2.5 Можно ли активировать дискретные входы кликом мыши, или только физически внешним сигналом?

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

Сообщение от АндрейХ

2.6 Возможен ли оперативный вывод трендов с выбором точек аналоговых сигналов в программе?

Силами SMLogix - нет, связка сервер+эксель или сервер+скада нарисует трендов столько, сколько нужно (до 4 тысяч).

Сообщение от АндрейХ

2.7 Как ведет себя ПО и ПЛК при изменении данных в ПЛК не с компьютера, а например с дисплея ПЛК?
(Например у Mitsubishi ALPHA XL сразу рвётся связь on-line и выдаётся ошибка, по этому можно менять данные только с компа. И если потом в ПЛК меняли данные с дисплея возникают проблемы связи с компьютером из-за несовпадения значения данных).

Так, как написана ваша программа.

В программах Конструктора и AutoSCADA, например, принято правило: кто последний записал, тот и прав. Запись с компа попадает на панель и запись с панели попадает в комп.

Ну а ПО в Мицубисях комментировать не буду, они позор какой-то устроили из этого простого по сути дела

Сообщение от АндрейХ

3. На сколько проблематично создать сетевую систему с один мастер- много слайв ПЛК?

Учитывая автоматизацию, имеющуюся в SMLogix, программно довольно-таки просто.

Аппаратно - зависит от кривизны рук создателя. Ничем от других modbus устройств не отличается.

Сообщение от АндрейХ

К сожалению мы не имеем опыта для работы в открытых сетях (делали сетевой ОПС на "БОЛИД", но это другое дело, там модули надо соединить витой парой и запрограммировать адреса, дальше система сама знает что делать с сетью, остается только конфигурировать приборы. Ну млин система тормозная... )

В SMLogix примерно также только без тормозов. Адреса в явном виде программировать не нужно, если сеть из наших контроллеров.

Сообщение от АндрейХ

4. Предполагается использование безпроводных радио каналов на "Невод-5". Будет сеть работать?

Смотря что вы от неё захотите. В принципе, работать будет. Но медленно и если это не учесть в программах, то раком.

Сообщение от АндрейХ

Далее возможно возникнут дополнительные вопросы. :p
С уважением Андрей. ООО "Системы Автоматики".

Добро пожаловать в support@segnetics.com Или приезжайте на обучение, если хотите серьёзно этим заниматься.



.

[АндрейХ]

Сообщение от Arsie

Хм... Обратиться в sales@segnetics.com пробовали?

Хм... пробовал, посылал письмецо... ни привета, ни ответа...
Пошлю еще разок, лишь бы меня не послали...
С остальными ответами бум разбираться...

В режиме отладки состояние логических связей обозначаются цыферками 0 и 1? А синим и красным цветом соединительные линии высветить не судьба? Так легче воспринимается вся картина происходящего в реал-тайме, не нужно цыферки по отдельности разглядывать.

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

[Arsie]

Позвоните! У нас последнюю неделю почта что-то подглючивает