Вы сами то поняли что сказали- со своими задачами сам ОЛ не тормозил .??? А задачи он в магазине покупает ?
Вид для печати
Вы сами то поняли что сказали- со своими задачами сам ОЛ не тормозил .??? А задачи он в магазине покупает ?
rovki прекрасно понял о чем сказал. Если есть ПР200, ПР114 и т.д., которые поддерживает ОЛ, то забив все поле макросами и FBD, которые в состоянии вместить память этих приборов, то тормозов быть не должно, от слова СОВСЕМ... и плювать, сколько в итоге мс будет выполняться программа в ПР, процессор выполняет действия по шагам и его мощность Х, если он будет выполнять эту программу 50 мс, значит 50. Но это не значит, что ОЛ должен выполнять действия по 10 минут.
На лицо недоработка программистов продукта.
Кстати для разработчиков ОЛ, вроде когда-то они говорили, что ОЛ на С# написан, так вот (Int32)double оказывается не одно и то же, что Convert.ToInt32(double) по выходному значению от входного.
Куда писать, в Microsoft ?:)
Так что код в зубы и оптимизировать.
Фантастика .Значит время цикла ПР зависит от количества компонентов ,а время компилятора не должно зависеть от количества .Если меня не устраивает время цикла ПР (15мс ,а надо 1мс) ,я беру другой инструмент .А если транслятор тормозит 5сек для задач что требует футбольного поля даже при наличии макросов , то он не работает или плохой .А я думаю это родимое пятно ....от которого просто не избавится (чревато раком).
А не проще компилировать перед загрузкой или по кнопке? Как это сделано в КДС и всех других нормальных системах.
Или сила есть - ума не надо?
Да уж, нам ваших не понять :).....
При редактировании линий на поле, не надо заниматься перекомпилированием на лету, если я не оторвал линию от входа или выхода, кстати насколько помню в ОЛ этого сделать нельзя.
А так поддерживаю, лучше компилирование сделать по кнопке, раз уж ума нет сделать иначе.
я не говорил что 5 мс это много или мало для ПР, я говорил о том, что при разницах в процессорах ПК и ПР эти 5 мс в ПР почему то превращаются в минуты на ПК а это уже явно странность.
Тут сказать не могу ,не специалист.НО чувствую что если можно было ,то сделали бы.В ОЛ как бы идет проверка каждого шага пользователя ,что бы потом не разгребать ситуацию с ошибками.А то на соединяют целочисленные выходы с дробными входами или еще чего.ОЛ гарантирует и исключает ошибки синтаксические .
Так проверкой "синтаксических" ошибок только и должен заниматься ОЛ когда "рисуешь", потом компиляция - проверка алгоритмических ошибок с указанием где и как. и только потом запуск.
Сразу то нафига ?
Вот по поводу тормозов - простое выделение макроса с его переменными (сетевые и внутренние) - 2,22 сек с момента отпускания кнопки мыши после обводки до выделения макроса и захваченных элементов . Я еще не решил что с выделенным делать, перемещать или удалять, только выделил.
И чем больше выделяешь элементов, тем больше уходит времени.
А я на 100% уверен, что программа составлена не оптимально и вся проблема в этом.