HMI cMT2078x Ограничение на кол-во задач в Codesys

[Jackson]

Velt, Ну. это игры с TCP-портами у конкретных производителей, как я понимаю. Чудны дела....

[dennis_asytp]

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

Почему ерундой? Вы можете дать ответ по существу вопроса? "Ерунда" - это что значит!? Если вы профессионал и вам есть что аргументированно ответить, я с удовольствием почитаю и приму к сведению.

[Jackson]

Вы можете дать ответ по существу вопроса?

Какого вопроса? Конкретно. Да, в панели ограничение на 5 потоков кодесис - это факт. Уже установлено. Что дальше?

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

О каком существе идёт речь?

[SBeaRM]

"Ерунда" - это что значит!?

То и значит. Вы сами придумываете себе ограничения которые вам мешают жить, хотя на самом деле это не так.
Я вам уже написал, что вам достаточно задачи для ПИДов, задачи для основного цикла и подпрограмм этого цикла и (как справедливо заметил Jackson) задачи для опроса ваших 60 устройств. Зачем вам отдельные задачи для алармов, графиков и архивов ответить можете? Почему эти подпрограммы нельзя вызывать и обрабатывать в основном цикле программы? В чем заключается "гибкость" о которой вы всё время пытаетесь рассказать?
Каких аргументов вы от меня ждете?

[Jackson]

И почему это всё нельзя сделать в EbPro. :)

[dennis_asytp]

И почему это всё нельзя сделать в EbPro. :)

Я вам уже выше писал, почему. Мне непонятно зачем создавать проект на скриптах в билдере... Например если вам надо построить ПИД-регулятор, как вы это делаете в скриптах? Мне надо было написать простой таймер, т.е. что бы с определенной периодичностью скажем раз в 20 дней в определенное время формировалось событие... не сложное дело вроде... в билдере на макросах нужно писать все с нуля, нет готовых функций, нет библиотек... потрачено время на такое простое дело, которое в нормальной IDE, можно сделать за пару минут, используя готовые библиотечные функции... в CODESYS вы можете создавать типы данных, что бы было проще создавать, а потом и модифицировать софт, собирать их в массивы, использовать указатели... и много еще чего... использовать библиотеки стандартных функций... Потом сама среда, в которой есть большинство фишек ускоряющих процесс создания кода(подсветка синтаксиса... и т.д.) . Я понимаю у каждого есть предпочтения, но вот мне непонятно зачем так усложнять себе жизнь.

Отправлено спустя 54 минуты 34 секунды:

Почему эти подпрограммы нельзя вызывать и обрабатывать в основном цикле программы?

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

Зачем вам отдельные задачи для алармов, графиков и архивов ответить можете?

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

В чем заключается "гибкость" о которой вы всё время пытаетесь рассказать?

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

В любом случае спасибо за совет...

[SBeaRM]

Я писал так же выше, что это один из вариантов

Знаете почему все, в том числе и техподдержка, удивились что есть ограничение на 5 задач и это ограничение вызывает у вас какие-то трудности? Потому что это не один из вариантов, а основной вариант.

Например если вам надо построить ПИД-регулятор, как вы это делаете в скриптах?

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

[Jackson]

Я вам уже выше писал, почему.

Нет, не писали. Смотрите внимательно. Свои предпочтения и вкусы писали - это факт.

Мне непонятно зачем создавать проект на скриптах в билдере

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

Например если вам надо построить ПИД-регулятор

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

мне непонятно зачем так усложнять себе жизнь

Вы сами себе её усложнили изначально кривой структурой. Грубо говоря, на Lamborghini поехали в лес за грибами. И продолжаете усложнять, отказываясь это признать. Хотя что тут такого - ну ошиблись, с кем не бывало. Я тоже однажды в лес уехал в костюме с галстуком и в лаковых ботинках. Да, было смешно. :) А то что Вы написали про "гибкость" - что-то я её там не разглядел. Общие фразы какие-то про возможности кодесиса, из даташитов. Среда программирования при этом вообще никакого значения не имеет - как будто в других местах всех этих возможностей нет. Не говоря про то, что когда объект построен и запущен, кому нужна эта гибкость и возможность всё легко модифицировать? На работающем объекте софт работает годами, десятилетиями, никто его не трогает и даже не все догадываются о том что он там есть. Код написали, отладили, запустили и забыли на всю оставшуюся жизнь, а рационализаторов типа "дай-ка я там чёнть оптимизирую и улучшу" гонят палками (иногда в буквальном смысле) - обычно бывает так. На кодесисе там написано, в билдере скриптами, или на бейсике, красиво и рационально или с тысячей закольцованных циклов и полтыщами массивов - вообще никому не интересно, и объекту не интересно.

Короче, ответов на вопросы мы не увидим, схемы тоже. Не хотите ответов - разбирайтесь сами. Вам уже дали огромное количество информации, как Вы и просили - по существу. Вполне можно принять решение. Это я только своё личное мнение выражаю. Дискуссия продолжается, но в таком ключе толку от неё мало, поэтому без меня. Потому что мы тут обсуждаем оптимальность программного кода, а у нас, точнее - у Вас, 60 слейвов на одном 485-м интерфейсе - насколько там код оптимален, будет вообще всё равно. Не там и не ту Вы проблему решаете.

Вот что у Вас сейчас тут происходит.