Пожелания

[Sergey Cherevko]

Цитата

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

Если вам это действительно нужно, можно получить весьма и весьма хорошее быстродействие запрограммировав SMH на Си.

1. Или еще большее, запрограммировав на ассемблере.
Я так думаю, что за очень редким исключением, пользователи используют всё-таки SMLogix. При всех его недостатках, это удобная среда разработки. И ее надо всячески развивать, в том числе расширяя функциональность и повышая скорострельность блоков и шины расширения.
2. Совет несколько не в тему, потому что я писал про Pixel с двумя модулями расширения.
3. Раз пошли советы перейти на Си, предлагаю тему закрыть, ибо мне гораздо проще повысить быстродействие внешней релейной логикой, как я уже писал...

[Arsie]

Я понимаю ваши аргументы. Но в нашем случае есть нехилый ограничивающий фактор - объём ПЗУ контроллера.

[АндрейХ]

Вот намыл интересненький сайт по FBD-блокам - http://www.tinyfbd.com/rus/technolog...htm#derivative Надеюсь что это не баян.
Понравился систематический подход автора к библиотеке FBD-блоков (хотя это не ново, всё давно уже придумано в РЕМИКОНТ-130 и Step7 с библиотеками регулирования, нужно только систематизировать по аксиоме - Необходимо и Достаточно).
Тут есть много интересного, от FBD узмерения (например нелинейные преобразования, правда всего 6 точек, а желательно до 10 точек - для преобразования перепада в расход на сужающем устройстве), регулирования (начиная от фильтров и зоны нечувствительности и заканчивая интегратором и блоком производной, но то-же не безупречно, нет ограничения мин/мах и ограничения скорости), всё что нужно по логическому управлению и мультиплексеры (а вот демультиплексоров почему-то нет) Рекомендую посмотреть.
Еще достойно внимания ПО от AutomationDirect PLC CLICK. В нем мне понравилась очень лаконичная логическая библиотека и математика. К сожалению не полная библиотека работы с аналоговыми сигналами, но прекрасный матблок, пример для подражания.
Ну и опять повторюсь, хоть и не всем нравится Step7 и считают CoDeSys де-факто стандартом мне больше импонирует Step7 с расширениями и документация (в отличии от скундной инфы по CoDeSys к Step7 есть полная документация на русском размером в несколько увесистых томов с диаграммами и примерами, ну прям готовый учебник по ПЛК). Это не реклама, а инфа к размышлению - "Каким Должно Быть ПО?"
С уважением АндрейХ.

[Sergey Cherevko]

Очередное пожелание разработчикам.
Хотелось бы иметь область глобальных переменных. И возможность назначения на вход FBD (даже многократно вложенного в макросы) связи, как индекса/указателя этой области. Если глобальные переменные будут автоматически отображаться на пространство регистров Modbus и им можно будет кроме индекса/указателя назначать еще и символьные имена - было бы вообще замечательно.
Обоснование целесообразности - на примере:
Необходимо в зависимости от условий подставлять в функцию один аргумент из нескольких десятков возможных.
Конечно, можно поставить MUX.
А если таких функций несколько и используют они одни и те же несколько десятков аргументов? Такое замучаешься программировать, да и программной памяти может не хватить.
PS: Контроллеры использую на ПРОМЫШЛЕННЫХ объектах, поэтому Си даже не советуйте...

[lau]

Думаю, что в чисто ФБДшных средах Вы не встретите желаемого.
А вот CoDeSys, который обещает появиться в новых контроллерах (согласно новостей Сегнетикса) поможет решить конкреино Ваш вопрос и , вообще, много в чем "развяжет" руки.
Кстати в новом контроллеле памяти будет побольше да и сам контроллер будет пошустрее, поэтому даже работая с Лоджиксом проблема ПАМЯТИ в Вашем случае может и стоять даже не будет.

[scadaservice]

Отвечая Lau: помучившись с CodeSys оценишь всю простоту и прозрачность SMLogix.

[Sergey Cherevko]

Цитата

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

Думаю, что в чисто ФБДшных средах Вы не встретите желаемого.

Дело не в среде, а в способах адресации переменных.
Насколько я понимаю, в SMLogix для каждого FBD создается локальная таблица указателей входных и выходных переменных. Но сами переменные в глобальной памяти данных.
Если вместо указателя в локальной таблице FBD использовать указатель на указатель, то вместо прямой адресации получим косвенную. А если вместо указателя использовать смещение в заданной области памяти данных, то вместо прямой адресации получим индексную.
Конечно, надо будет контролировать выход указателя за границы области памяти данных, но по моему мнению оно того стоит.
Если будет сложно реализовать универсальные входы и выходы для всех FBD, можно хотя бы ограничиться созданием GET(bool)...GET(real) и PUT(bool)...PUT(real) чтения и записи глобальных переменных соответственно.

[Arsie]

Цитата:

Сообщение от Sergey Cherevko

Очередное пожелание разработчикам.
Хотелось бы иметь область глобальных переменных. И возможность назначения на вход FBD (даже многократно вложенного в макросы) связи, как индекса/указателя этой области. Если глобальные переменные будут автоматически отображаться на пространство регистров Modbus и им можно будет кроме индекса/указателя назначать еще и символьные имена - было бы вообще замечательно.

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

2) Символьные имена модбас не поддерживает. Дальше размышлять на эту тему смысла нет, т.к. это уже будет называться LON.

Цитата:

Сообщение от Sergey Cherevko

Обоснование целесообразности - на примере:
Необходимо в зависимости от условий подставлять в функцию один аргумент из нескольких десятков возможных.
Конечно, можно поставить MUX.
А если таких функций несколько и используют они одни и те же несколько десятков аргументов? Такое замучаешься программировать, да и программной памяти может не хватить.

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




.

[Arsie]

Цитата

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

Можно только поддержать предложение о создании таблицы глобальных переменных с "нормальными" адресами Modbus. Я уже задрался объяснять разработчикам SCADA, почему в SMH такие большие адреса и почему их нельзя изменить.

1) А какая разница программерам, на каких адресах данные? Вообще не вижу проблемы забить вместо адреса 11 адрес 11111, никакие морально-этические нормы это не нарушает

2) В лоджике уже скоро год, как появилась индексная адресация переменных слейва. Назначаете нулевой базовый адрес и все адреса будут смещениями от этой базы: 0, 1, 2 и т.д.

Но повторюсь: что это за странные программеры, для которых цифра адреса вызывает вопросы?



.

[Sergunya]

Цитата:

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

1) А какая разница программерам, на каких адресах данные? Вообще не вижу проблемы забить вместо адреса 11 адрес 11111, никакие морально-этические нормы это не нарушает

2) В лоджике уже скоро год, как появилась индексная адресация переменных слейва. Назначаете нулевой базовый адрес и все адреса будут смещениями от этой базы: 0, 1, 2 и т.д.

Но повторюсь: что это за странные программеры, для которых цифра адреса вызывает вопросы?



.

Цифра адреса может вызывать вопросы, когда она "жестко" зашита на верхнем уровне, т.е. в диспетчерской программе или контроллере, и нет возможности ее там поменять. Такое встречается постоянно на объектах нефтяников, где система телемеханики (так у них называется) опрашивает заранее заданные адреса, и других возможностей не дает.

[Arsie]

Цитата

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

Цифра адреса может вызывать вопросы, когда она "жестко" зашита на верхнем уровне, т.е. в диспетчерской программе или контроллере, и нет возможности ее там поменять. Такое встречается постоянно на объектах нефтяников, где система телемеханики (так у них называется) опрашивает заранее заданные адреса, и других возможностей не дает.

Э нет, уважаемый Сергуня... Вы подмешиваете свох мух в мои котлеты

Подстраивание под чужие адреса - это уже иное. Нет разницы, как подстраиваться под адрес, изменяя цифру 11 -> 20 или 11111 -> 20.

Но подстраивание под чужих - тоже решённый вопрос в лоджике, оно там есть



.

[Sergunya]

Цитата:

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

Но подстраивание под чужих - тоже решённый вопрос в лоджике, оно там есть



.

А, ну про это я знаю, конечно. Тут к Лоджику вопросов уже нет.

[Sergey Cherevko]

Еще одно предложение:
можно ли один из регистров системной страницы "привязать" к клавиатуре по аналогии с буфером экрана? С доступом на запись, разумеется.

[Arsie]

Цитата:

Сообщение от Sergey Cherevko

Еще одно предложение:
можно ли один из регистров системной страницы "привязать" к клавиатуре по аналогии с буфером экрана? С доступом на запись, разумеется.

Думаю это слишком неразумно.

1) Из сети записали "кнопка отпущена", а человек в это время нажал эту кнопку.

2) Из сети записали "кнопка нажата" и связь оборвалась.


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



.

[Sergey Cherevko]

Цитата:

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

Думаю это слишком неразумно.

А если разумно реализовать?

Цитата:

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

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

Можно реагировать не на уровень "сетевого нажатия кнопки", а на фронт. Получится безопасно, но не уверен, что ядро правильно отработает комбинации одновременно нажатых кнопок (например для F1..F4).
Либо ввести тайм-ауты на "сетевые нажатия кнопок". Величины тайм-аутов в 1..3 сек вполне хватит, имхо.

[Arsie]

Цитата:

Сообщение от Sergey Cherevko

А если разумно реализовать?

Вот именно поэтому для контроллера можно написать и такую программу.

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



.

[foton]

Просьба к инженерам сегнетикса

УВЕЛИЧЬТЕ КОММУТИРУЕМУЮ МОЩНОСТЬ ВЫХОДОВ НА БУДУЩИХ СЕРИЯХ (2Gi) хотя бы до 2А, а лучше до 5!
Сейчас IOR делает такие опторелюшки, они нам так помогли бы при частой (более 1000000 срабатываний) коммутации индуктивной нагрузки
и БУДЕТ ВСЕМ СЧАСТЬЕ!

[Partizan]

Цитата

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

Просьба к инженерам сегнетикса

УВЕЛИЧЬТЕ КОММУТИРУЕМУЮ МОЩНОСТЬ ВЫХОДОВ НА БУДУЩИХ СЕРИЯХ (2Gi) хотя бы до 2А, а лучше до 5!
Сейчас IOR делает такие опторелюшки, они нам так помогли бы при частой (более 1000000 срабатываний) коммутации индуктивной нагрузки
и БУДЕТ ВСЕМ СЧАСТЬЕ!

Увеличение коммутируемого тока пока не планируется.
Дело в том, что эти реле относительно дороги и заставлять платить всех за них не хочется. К тому же нагрузки у всех разные и по вольтажу и по току, а данные реле - вещь все-таки специфичная.
Может быть включим более сильноточные реле в модуль MR, если будет много желающих.

...Обычно народ коммутирует нашим реле свое мощное внешнее реле. Так более универсально и в конечном итоге - дешевле.

[ailcat]

Ребята, а может - можно все-таки сделать единственный FBD-элемент "Задержка включения и отключения"???
Главное в нём - возможность задержки задавать в миллисекундах, независимо от времени тика!
Эта возможность - я уверен! - будет очень востребована многими пользователями ваших контроллеров (в первую очередь - благодаря "тико-независимости").
Естественно, что реализацию изменения состояний надо производить во время прогона программы по очередному тику...

Полагаю, что элемент должен иметь булевый вход "данных", а также булевые прямой и инверсный выходы (уже с учетом задержек), величины задержек разумно задавать входами типа хотя бы Int (а уж если реализуете Long или Real с максимальным интервалом минут в 15-30 - честь вам будет и премногая благодарность!)

Если таки на такой элемент можно надеяться - готов дать более подробную инфу по телефону (у меня напряги с инетом), он етсь в профиле

[Arsie]

Цитата:

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

Ребята, а может - можно все-таки сделать единственный FBD-элемент "Задержка включения и отключения"???
Главное в нём - возможность задержки задавать в миллисекундах, независимо от времени тика!

Задержка дискретного сигнала

блок TimeToTick

Цитата:

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

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

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


.

[ailcat]

Цитата:

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

Асинхронная задержка ("тиконезависимая") - абсолютно бессмысленная вещь в насквозь синхронной ("тикозависимой") программе.

Данная вещь более чем актуальна хотя бы в силу того, что человек (в 99% случаев под этим подразумеваем "оператор" либо "наладчик") - оперирует секундами/миллисекундами, а не тиками. Особенно если в его ведоме несколько систем с различными длительностями тиков.

Цитата:

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

Вышеприведённые ссылки практически полностью реализуют ваше желание и без "тиконезависимости".

Они не реализуют его вообще в моем случае.
Уже хотя бы в силу того, что типичная задержка для моих применений - 200-700 миллисикунд (и таких - десятки в программе, притом ощутимая часть доступна наладчику, а некоторые - и оператору), в то время как TimeToTick оперирует только целыми секундами (чего, вполне возможно, более чем достаточно для АВОК - я же пытаюсь использовать ваш контроллер для управления технологической установкой), в силу чего пригоден разве что для сильно медленных процессов, которые тянутся минутами...
Ну а мне поневоле приходится корячить "математику" между вводом данных и счетчиковыми выкрутасами в алгоритме.

Ну а про то, что некоторые программы после "апгрейда" перестают укладываться в старое время тика (которое, сами понимаете, для технологической установки выбирается минимально возможным) - что влечет изменение 30-50 "абсолютно синхронных" задержек, раскиданных по программе - уже просто и говорить не хочется, ибо чувствую бессмысленность...
P.S. На предыдущей установке, аналогичной создаваемой сейчас, стоит "контроллер" Siemens Logo. В первой версии программы тик был меньше 70 мс; во второй (с которой она проработала первые полгода) - 130 мс. В финальной (с расширенной диагностикой и более навороченной "защитой от дурака") - 180 мс. И при этом при апгрейдах я НИ РАЗУ не менял ни одну из 34 имеющихся в программе задержек! Просто в силу того, что все они заданы в миллисекундах.

[New]

То ли мы чего то не можем понять, то ли Вы так объясняете. . Раньше блока TimeToTick вообще не было, и ничего - обходились. Математики там было аж целых два блока: умножить на 1000 и разделить на время тика программы. Если использовать время в миллисекундах, так и умножать не надо.

[Sergey Cherevko]

Цитата:

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

Данная вещь более чем актуальна хотя бы в силу того, что человек (в 99% случаев под этим подразумеваем "оператор" либо "наладчик") - оперирует секундами/миллисекундами, а не тиками. Особенно если в его ведоме несколько систем с различными длительностями тиков.

Кину свои 5 копеек.
Оператор прекрасно может оперировать сотнями миллисекунд.
Просто я с трудом могу себе представить необходимость в задержках с точностью десятков миллисекунд, не говоря уже про единицы. Это должен быть какой-то очень быстродействующий исполнительный механизм типа сервопривода. Но реализовывать такое программно на сегнетиксе - мягко говоря неудачное решение.
Остается показывать оператору задержки либо в виде "*00 мс", либо в виде "* х 100 мс", что в принципе одно и то же: точность в сотни миллисекунд, а остальное -дело вкуса.

Цитата:

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

типичная задержка для моих применений - 200-700 миллисикунд (и таких - десятки в программе, притом ощутимая часть доступна наладчику, а некоторые - и оператору), в то время как TimeToTick оперирует только целыми секундами.

Если выставить тик равным 100 мс, то требуемые задержки легко реализуются счетчиком тиков 2-7 для ваших применений.
Или тик равным 50 мс, 25 мс с соответствующими счетчиками тиков 4-14, 8-28...

Цитата:

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

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

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

Цитата:

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

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

Кстати, грабли могут быть именно в том, что выбрано минимально возможное время тика. Потому что реальное время обработки программы меняется в зависимости от условий, если в ней используются FBD с входами enable. И кроме обработки программы оставшееся время тика тратится на коммуникации, обработку клавиатуры и прочие служебные действия. В итоге тик будет постоянно плавать, а задержки будут непредсказуемые Не стоит выбирать время тика минимально возможным...

[ujin]

Различных задержек в проекте много. Не хочется зависеть от времени тика, поэтому перевод секунд в тики становится практически обязательной задачей, и соответственно при использовании блоков с временным входом практически всегда появляется один дополнительный блок TimeToTick. Блоков вроде бы и много, но когда есть запас и проект быстрее делается, так как не надо ужимать и оптимизировать.
Таким образом имеем некоторое неудобство работы (хотя и небольшое) плюс увеличение количества блоков. Думаю в план работ 25 (125) строчкой поставить можно.

[Arsie]

Цитата:

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

Различных задержек в проекте много. Не хочется зависеть от времени тика, поэтому перевод секунд в тики становится практически обязательной задачей, и соответственно при использовании блоков с временным входом практически всегда появляется один дополнительный блок TimeToTick. Блоков вроде бы и много, но когда есть запас и проект быстрее делается, так как не надо ужимать и оптимизировать.
Таким образом имеем некоторое неудобство работы (хотя и небольшое) плюс увеличение количества блоков. Думаю в план работ 25 (125) строчкой поставить можно.

Тут вся фишка в том, что счётчик с заданием счёта в миллисекундах по сути является комбинацией блоков математики и собственно счётчика. Так что "уменьшение количества блоков" здесь происходит весьма мифическое.

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

В итоге я пока вижу только психологическое неудобство. Которое всё же нужно пересилить, ибо контроллер выполняет не 100-200 ФБ, а тысячи.


.

[Arsie]

Цитата:

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

Данная вещь более чем актуальна хотя бы в силу того, что человек (в 99% случаев под этим подразумеваем "оператор" либо "наладчик") - оперирует секундами/миллисекундами, а не тиками. Особенно если в его ведоме несколько систем с различными длительностями тиков.

Да в чём ваша проблема-то? Вот макрос, я его сделал ровно за 40 секунд - я засекал.

Даже если включить в это время два перекура и чаепитие, то всё равно получается много меньше, чем то внимание, которое уделено этой тематике в переписке

[ujin]

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

[LordN]

Цитата:

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

Тут вся фишка в том, что счётчик с заданием счёта в миллисекундах по сути является комбинацией блоков математики и собственно счётчика. Так что "уменьшение количества блоков" здесь происходит весьма мифическое.

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

В итоге я пока вижу только психологическое неудобство. Которое всё же нужно пересилить, ибо контроллер выполняет не 100-200 ФБ, а тысячи.


.

наличие асинхронного входа для фиксации наличия хотябы одной первой иголки длиной менее тика - неплохая фича. ну или не входа а фбд блока.
сложно реализуемо?
для всей линейки?

[Arsie]

Цитата

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

наличие асинхронного входа для фиксации наличия хотябы одной первой иголки длиной менее тика - неплохая фича. ну или не входа а фбд блока.
сложно реализуемо?
для всей линейки?

Входа какого?



.

[Sergey Cherevko]

Цитата:

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

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

Обычно удобства программиста - его личное дело, а остальным на удобства программиста плевать с высокой колокольни.
Да и программист - программисту рознь У меня, например, после появления группового перетаскивания всего одно маленькое неудобство осталось - отсутствие отмены последней манипуляции. А тики вообще неудобством не были...