Тормоза Owen Logic

[rovki]

Вы сами то поняли что сказали- со своими задачами сам ОЛ не тормозил .??? А задачи он в магазине покупает ?

[Вольд]

.
Даже если поймут ,то времени и средств не хватает на более мелкие задачи (нужные) .Я в начале был то же сторонник разных ОЛ .Много сил ушло на поддержание всех ПР и проектов в одном ОЛ ,сковали себя по рукам и ногам .Универсальность вещь хорошая ,но все имеет цену....Завтра появиться ПР300 ,например и опять несколько лет на отладку...

А почему CoDeSys одна, а ПЛК, которые из под нее работают великое множество ? А потому, что чем прежде большое дело начинать надо мозгами хорошо пошевелить. Вот разработчики CoDeSys мозгами хорошо шевелят.

[melky]

rovki прекрасно понял о чем сказал. Если есть ПР200, ПР114 и т.д., которые поддерживает ОЛ, то забив все поле макросами и FBD, которые в состоянии вместить память этих приборов, то тормозов быть не должно, от слова СОВСЕМ... и плювать, сколько в итоге мс будет выполняться программа в ПР, процессор выполняет действия по шагам и его мощность Х, если он будет выполнять эту программу 50 мс, значит 50. Но это не значит, что ОЛ должен выполнять действия по 10 минут.

На лицо недоработка программистов продукта.

Кстати для разработчиков ОЛ, вроде когда-то они говорили, что ОЛ на С# написан, так вот (Int32)double оказывается не одно и то же, что Convert.ToInt32(double) по выходному значению от входного.
Куда писать, в Microsoft ?

Так что код в зубы и оптимизировать.

[rovki]

Фантастика .Значит время цикла ПР зависит от количества компонентов ,а время компилятора не должно зависеть от количества .Если меня не устраивает время цикла ПР (15мс ,а надо 1мс) ,я беру другой инструмент .А если транслятор тормозит 5сек для задач что требует футбольного поля даже при наличии макросов , то он не работает или плохой .А я думаю это родимое пятно ....от которого просто не избавится (чревато раком).

[ASo]

А не проще компилировать перед загрузкой или по кнопке? Как это сделано в КДС и всех других нормальных системах.
Или сила есть - ума не надо?

[rovki]

А почему CoDeSys одна, а ПЛК, которые из под нее работают великое множество ? А потому, что чем прежде большое дело начинать надо мозгами хорошо пошевелить. Вот разработчики CoDeSys мозгами хорошо шевелят.

Вы еще скажите что ОЛ должна поддерживать все виды ПР всех производителей (как кодесис) .На сколько я видел ,с ОЛ работает плотно 1 человек .

[melky]

Да уж, нам ваших не понять .....

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

я не говорил что 5 мс это много или мало для ПР, я говорил о том, что при разницах в процессорах ПК и ПР эти 5 мс в ПР почему то превращаются в минуты на ПК а это уже явно странность.

[rovki]

А не проще компилировать перед загрузкой или по кнопке? Как это сделано в КДС и всех других нормальных системах.
Или сила есть - ума не надо?

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

[melky]

Так проверкой "синтаксических" ошибок только и должен заниматься ОЛ когда "рисуешь", потом компиляция - проверка алгоритмических ошибок с указанием где и как. и только потом запуск.
Сразу то нафига ?

Вот по поводу тормозов - простое выделение макроса с его переменными (сетевые и внутренние) - 2,22 сек с момента отпускания кнопки мыши после обводки до выделения макроса и захваченных элементов . Я еще не решил что с выделенным делать, перемещать или удалять, только выделил.

И чем больше выделяешь элементов, тем больше уходит времени.

[Василий Кашуба]

А я на 100% уверен, что программа составлена не оптимально и вся проблема в этом.