Тут тоже - полность согласен. Может проблема "вызреет" и ОЛ все же оптимизируют со временемЦитата:
Сообщение от Владимир Ситников
Вид для печати
Тут тоже - полность согласен. Может проблема "вызреет" и ОЛ все же оптимизируют со временемЦитата:
Сообщение от Владимир Ситников
Значит ОЛ - это анахронизм. ;)Цитата:
Сообщение от rovki
ОЛ уже много лет оптимизируют, но толку мало. Нужна новая концепция, нужны новые не зашоренные разработчики.Цитата:
Сообщение от Irgy
Перемен, мы ждем перемен. ;)
Время цикла тут вообще ни при чем, оно здорово растет от плавающей точки. При работе только с битами и целочисленными даже на крутой сложности выходит не больше 10мс. Но ОЛ тормозит безбожно. Я просил чтобы в ОЛ был не один холст, а больше, типа добавления большого макроса с связями через переменные. Ведь при рисовании макроса не тормозит и при малых количествах внешних связей это хороший способ и сейчас.Цитата:
Сообщение от Irgy
Я всегда ПР рассматривал в совокупности с ОЛ ,со всеми его ограничениями .Раньше была актуальна пословица -из пушки по воробьям ,когда приходилось уговаривать решать простые задачи на ПР ,теперь нужна другая пословица -по Сеньке шапка. Надеяться можно и нужно на лучшее ,но работать нужно сейчас с учетом реалий.Это то же одно из обязанностей разработчика - правильно выбрать средства по конкретную задачу.
ПР200 - замечательный прибор, ОЛ - посредственная вещь. Но в одну телегу впрячь не можно коня и трепетную лань. ;)
Для ПР110 и ПР114 ОЛ пойдет, но для ПР200 нужна новая среда. Чем раньше поймут это в фирме ОВЕН тем лучше будет для всех.
Другими словами- общая скорость движения будет меньше наименьшей ,вот ее и надо брать в расчет ..Цитата:
Сообщение от Вольд
Мне процесс работы на ОЛ нравиться ,но я не буду требовать что бы он обеспечивал работу с ШД и энкодерами.Сам МК контроллер может и позволил бы ,но ОЛ заточена под другой круг задач.
Теперь уж получив ПР200 всё равно будем как ёжики, которые едят кактус.Цитата:
Сообщение от Вольд
.Цитата:
Сообщение от Вольд
Даже если поймут ,то времени и средств не хватает на более мелкие задачи (нужные) .Я в начале был то же сторонник разных ОЛ .Много сил ушло на поддержание всех ПР и проектов в одном ОЛ ,сковали себя по рукам и ногам .Универсальность вещь хорошая ,но все имеет цену....Завтра появиться ПР300 ,например и опять несколько лет на отладку...
rovki так речь не о том, какие задачи можно решать а какие нет на ОЛ, а о том, чтобы по своим задачам сам ОЛ не тормозил....
Вы сами то поняли что сказали- со своими задачами сам ОЛ не тормозил .??? А задачи он в магазине покупает ?
А почему CoDeSys одна, а ПЛК, которые из под нее работают великое множество ? А потому, что чем прежде большое дело начинать надо мозгами хорошо пошевелить. Вот разработчики CoDeSys мозгами хорошо шевелят.Цитата:
Сообщение от rovki
rovki прекрасно понял о чем сказал. Если есть ПР200, ПР114 и т.д., которые поддерживает ОЛ, то забив все поле макросами и FBD, которые в состоянии вместить память этих приборов, то тормозов быть не должно, от слова СОВСЕМ... и плювать, сколько в итоге мс будет выполняться программа в ПР, процессор выполняет действия по шагам и его мощность Х, если он будет выполнять эту программу 50 мс, значит 50. Но это не значит, что ОЛ должен выполнять действия по 10 минут.
На лицо недоработка программистов продукта.
Кстати для разработчиков ОЛ, вроде когда-то они говорили, что ОЛ на С# написан, так вот (Int32)double оказывается не одно и то же, что Convert.ToInt32(double) по выходному значению от входного.
Куда писать, в Microsoft ?:)
Так что код в зубы и оптимизировать.
Фантастика .Значит время цикла ПР зависит от количества компонентов ,а время компилятора не должно зависеть от количества .Если меня не устраивает время цикла ПР (15мс ,а надо 1мс) ,я беру другой инструмент .А если транслятор тормозит 5сек для задач что требует футбольного поля даже при наличии макросов , то он не работает или плохой .А я думаю это родимое пятно ....от которого просто не избавится (чревато раком).
А не проще компилировать перед загрузкой или по кнопке? Как это сделано в КДС и всех других нормальных системах.
Или сила есть - ума не надо?
Вы еще скажите что ОЛ должна поддерживать все виды ПР всех производителей (как кодесис) .На сколько я видел ,с ОЛ работает плотно 1 человек .Цитата:
Сообщение от Вольд
Да уж, нам ваших не понять :).....
При редактировании линий на поле, не надо заниматься перекомпилированием на лету, если я не оторвал линию от входа или выхода, кстати насколько помню в ОЛ этого сделать нельзя.
А так поддерживаю, лучше компилирование сделать по кнопке, раз уж ума нет сделать иначе.
я не говорил что 5 мс это много или мало для ПР, я говорил о том, что при разницах в процессорах ПК и ПР эти 5 мс в ПР почему то превращаются в минуты на ПК а это уже явно странность.
Тут сказать не могу ,не специалист.НО чувствую что если можно было ,то сделали бы.В ОЛ как бы идет проверка каждого шага пользователя ,что бы потом не разгребать ситуацию с ошибками.А то на соединяют целочисленные выходы с дробными входами или еще чего.ОЛ гарантирует и исключает ошибки синтаксические .Цитата:
Сообщение от ASo
Так проверкой "синтаксических" ошибок только и должен заниматься ОЛ когда "рисуешь", потом компиляция - проверка алгоритмических ошибок с указанием где и как. и только потом запуск.
Сразу то нафига ?
Вот по поводу тормозов - простое выделение макроса с его переменными (сетевые и внутренние) - 2,22 сек с момента отпускания кнопки мыши после обводки до выделения макроса и захваченных элементов . Я еще не решил что с выделенным делать, перемещать или удалять, только выделил.
И чем больше выделяешь элементов, тем больше уходит времени.
А я на 100% уверен, что программа составлена не оптимально и вся проблема в этом.
У меня на работе на ноутбуке даже простые проекты лагают. Разрабатывать на нем что бы то ни было практически невозможно. Использую рабочий ноут только чтобы проекты заливать в контроллер на месте его установки. По 5 минут жду, пока проект откроется.
На стационарном компе 10-летней давности чуть лучше. Можно разрабатывать, но сделать связь например требует 3-5 секунд, причем торопиться нельзя, иначе связь "залипает" и приходится начинать всё заново - удалять компонент и добавлять его снова, соединяя всеми связями. По первому времени по 5 раз переустанавливал компоненты на поле.
Дома на ноуте Lenovo G770 летает всё что я когда либо делал.
Типичный мой проект выглядит примерно так:Вложение 30793
Макросы внутри тоже совсем не простенькие.
Думается, на нормальном современном компутере можно будет работать на забитом поле 1000х1000 без особых проблем.
Мне то же так кажется ,что там воплощен программистский подход ,а лоджик этого не любит ;).Цитата:
Сообщение от Василий Кашуба
афигеть, лоджик написан не программистами выходит ? :)
Я говорю о пользователях ,а не разработчиках инструмента .
Смешно. В соседней теме столько было разговоров про "ОЛ наше все" и "нам квадратиками удобнее", а тут выясняется что ОЛ = торможеное г... Повторюсь - в связке ПР200-ОЛ = проблема в ОЛ, он сильно ущемляет возможности ПР200, а теперь еще и возможности разработки оказывается. Вангую, что все разговоры об "оптимизации ОЛ" разговорами же и останутся, т.к. скорее всего в него изначально был заложен неверный подход к разработке пользовательских программ, который оправдывал себя на малых сложностях и сам проще реализовывался, а сейчас вылезли проблемы и они принципиально не решаемы. Тут точно тоже что и для С на ПР200 - сделать нельзя из-за самого подхода к построению ПО, как на ПР200 - подхода удобного и правильного, для своего времени, но морально устаревшего. Однако сделать уже ничего нельзя. И в том, и в другом случае, помог бы выпуск вариантов ПР200, без привязки к ОЛ - это дало бы свободу тем пользователям, кто в ней нуждается. А остальные привычно "ели бы кактус". В своем теперешнем состоянии, связка ПР200-ОЛ = данность, которая не может быть улучшена, без кардинальной переработки. Но это явно будет нескоро, т.к. у ОВЕН свой большой запас "кактусов". Поэтому, если ОЛ тормозит, значит вам нужен другой контроллер.
Есть масштабируемые решения (Codesys) в которых введение нового компонента не требует титанических усилий.Цитата:
Сообщение от Вольд
А есть решения изначально задуманные как немасштабируемые, и прекрасно работающие на маленькой платформе. Но стоит попробовать на них сделать что-то более обьёмное, как начинаются проблемы.
Как-то уже предлагал переделать весь ОЛ с 0, а все старые программы - через компилятор прогонять.
Сейчас стараюсь не писать под ОЛ больших проектов - из-за тормозов нервы страдают.
Чисто из любопытства, можно ссылку на проект (часть проекта, если секретная разработка), который тормозит.
Просто у меня нет вышеописанного торможения, может я что-то не так делаю ?
А вообще правильнее проверять на железе , а не в эмуляторе - и результат достоверный и тормозить не будет.
Так в том и фокус, что на железе с гораздо меньшей производительностью чем ПК программа не страдает тормозами и адекватна по быстродействию :)
Так у меня и на ПК Лоджик не страдает тормозами. Хотя ноут десятилетней давности и винда XP.Цитата:
Сообщение от melky
У тебя проекты с гулькин нос, вот и не страдаешь. ;)Цитата:
Сообщение от SA104
Я думаю можно подвести черту и сделать такой вывод.
Для разработки больших проектов в ОЛ нужен суперкомпьютер. ;)
А ты я вижу провидец. Портянки на экране, действительно не мой стиль.Цитата:
Сообщение от Вольд
А "большие" проекты не всегда сложные, а просто большие.
Да тут вообще провидцев набралось в теме. Реакции от ОВЕН не слышно.Цитата:
Сообщение от SA104
Если проблема действительно в компиляции на каждый чих, то эта задержка будет зависеть только от общего количества элементов в схеме, а не от того, как они распределены (или не распределены) по макросам.
Советы в духе "надо макросы использовать и будет всё хорошо" это всё вилами по воде.
Нужно брать проблемный проект, открывать его в ОЛ, и профилировать это самое ОЛ.
Но, разумеется, ОЛ впереди планеты всей, ОЛ не тормозит, поэтому и нечего тратить время на анализ скорости работы ОЛ.
Я и просил скинуть "проблемный проект", дабы убедиться, что тормозит - ОЛ, проект или нечто третье.
Что касается ОЛ - для своих целей вполне рабочая лошадка, непритязательная и простая в обращении. )
Где же его взять "проблемный" проект? У меня таких нет, все ведут себя адекватно.
Всё верно. Но есть разница, когда это просит ОВЕН и когда это делает неизвестнокто.Цитата:
Сообщение от SA104
Тоже верно. Вас устраивает -- шикарно.Цитата:
Сообщение от SA104
Но вот такими своими сообщениями вы не даёте раскачивать:
Вас всё устраивает -- и ладно. Но говорить "ОЛ не страдает тормозами" без приписки "на моих микропроектах" нехорошо.Цитата:
Сообщение от SA104
Чтобы сдвинуться с места нужно хорошенько раскачать.
А на просьбу выложить проект на форум, владельцы "проблемных" проектов боятся, что их проблемную интеллектуальную собственность украдут.
Вряд ли дело в интеллектуальной собственности. Скорее дело в высокомерии, ведь стоит только что нибудь выложить, как сразу посыпется критика что там не так и здесь не эдак) И критика эта будет не всегда по теме оптимизации ресурсов)
Многие воспринимают это крайне болезненно.
Не слышно, но зато видно. ;) Неугодные посты очень шустро удаляют.Цитата:
Сообщение от Владимир Ситников
Я не писал, что у меня микропроекты, не надо за меня это делать.Цитата:
Сообщение от Владимир Ситников
Поставим вопрос по другому: при каком проценте задействованных ресурсов (внизу рабочего экрана) ОЛ начинает "тормозить"