Боды - это совсем не биты в секунду.
А быстродействие контроллера очень важно.
Во многих приложениях имеет значение время цикла.
Да и простой энкодер подключить - проблема.
Вот совсем недавно надо было шаговиком управлять. В ПЛК110 такие извраты
неочевидные приходится делать. А были бы нормальные входы-выходы с быстродействием
порядка времени цикла, совсем другое дело.
Сравнивать надо не быстродейсвие, а стоимость и качество решений. У Овена при имеющихся проблемах с качеством (в пору хоть по 100% зип-у закладывать в проект), еще добавляется трудность техподдержаки- надпись про 24-часову тех поддержку по номеру 8-800.... - это только надпись ни разу после 18-ти не ответили, местные диллеры тоже в нерабочее время становяться недоступны оставляя вас наедине с вашим выбором отечественного производителя. У сименса я спокойно с немцами связвался и в суботу вечером. Иногда вопрос техподдержки бывает очень острый, особенно в нерабочее московское время.(только сегодня позвонив в 17-50 так и не услышал ничего кроме гудков).
Ну уж, эта неправда, про техподдержку Сименса не лезет ни в какие ворота. Получить серьезную техподдержку без денег не получится! Проверено на своем опыте. А продавцы (дилеры), как правило, технику Сименса знают хуже меня. Так же проверено. Это, во-первых.Сообщение от darkwolf
Во-вторых, пост был конкретно технический. И я проводил конкретно техническое сравнение, результаты, которого и опублиоквал. Ваш комментарий совсем из другой оперы. Нравится Сименс и есть деньги? - пользуйтесь.
Правда ваша. Меня убило когда местный дилер посоветовал в интернете поискать каталог, а то он сам не очень. Ну и общение с головной конторой тоже порадовало. Обещали обещали.... В итоге, в общем попытка перейти с сименса на овен столкнулась с стойким нежеланием последнего. В итоге опять сименс.
Ну насмешил
Я хотел пересесть с ауди Q на рено дастер , но вот местный дилер посоветовал почитать отзывы в интернете....
Не знаю как ОВЕН, пока первый проект с ним, но начинал я на контроллерах Schneider Electric. И после них сименс показался очень убогим в плане разработки ПО. Для меня пока однозначно Шнайдер, посмотрим что ОВЕН могёт. О поддержке никогда не задумывался, если есть документация хорошо, нет - сам ковыряюсь.
Имею на руках ПЛК110-24.30.Р-М [M02] и потому продолжил тестирование производительности.
Как известно ПЛК110 М02 имеет процессор 400 МГц, в то время как предыдущая модель ПЛК110 имела 180 МГц.
Из сего я ожидал увидеть увеличение производительности примерно в 2 раза, но увидел, увеличение производительности примерно в 15 раз (см. "Тест производительности.jpg").
Из чего вопрос к разработчикам: почему при увеличении тактовой частоты процессора в 2 раза производительность возросла примерно в 15 раз?
Тестовый проек прикрепляю (+ собственная библиотека статистики).
И, конечно, важный вывод тестирования ПЛК110 [M02] заключается в том, что он производительней линейки Siemens S7-300. Вот так получается!
Потому что кто-то где-то упустил возможность увеличить производительность в семь с половиной раз на той же частоте.почему при увеличении тактовой частоты процессора в 2 раза производительность возросла примерно в 15 раз?
У меня проект правильно открылся?
Вообще говоря, подобным образом сравнивать производительность это странно.Код:VAR j : INT; JMax : INT := 30000; tmpI : INT; tmpR : REAL; Statistic : TimeStatistic; END_VAR ... FOR j := 1 TO JMax DO tmpI := tmpI + 1; tmpR := tmpR + 1; END_FOR;
Нормальный компилятор должен поменять этот самый FOR цикл в такое (вообще выкинуть FOR):
А потом компилятор должен понять, что значения tmpI и tmpR вообще не используются, значит их из программы можно выкинуть, и, всё, в программе не осталось кода кроме "обращений к таймерам".Код:tmpI := tmpI + JMax; tmpR := tmpR + JMax;
Честно говоря, не знаю насколько умный компилятор в CDS2.3, но не исключаю, что не самый глупый.
Что предлагаю сделать:
1) Сделать так, чтобы "длина цикла" читалась из какого-нибудь регистра, IO и т.п. Ну, чтобы компилятор не мог заложиться на то, что JMax всегда равно 30000
2) Выводить результирующие значения tmpI и tmpR в какие-нибудь output'ы. Тогда компилятор не сможет вообще выкинуть работу с переменными, а будет обязан как минимум записать финальный результат.
3) Если проверять именно счётные возможности (например, скорость сложения), то нужно оформлять цикл так, чтобы компилятор не мог превратить цикл в одно простое tmpI := tmpI + JMax;
Как вариант, делать WHILE цикл с чуть более сложным условием.
Как вариант, вместо кучки tmp1, tmp2, ... можно использовать массив, но у массива из 5-и элементов и у 5-и переменных может получиться совсем разная производительность (в зависимости от того, как сработает register allocation):
Код:JMax := in_max; (* это чтение длины цикла, фактически всегда одно и то же, но компилятор об этом не будет знать *) tmp1 := 0; tmp2 := 0; tmp3 := 0; tmp4 := 0; tmp5 := 0; WHILE tmp1 < JMax (* возможно, стоит что-то поковарнее придумать, но тут нужно замерять и смотреть догадывается ли компилятор выкинут цикл *) tmp1 := tmp1 + 1; tmp2 := tmp2 + 1; tmp3 := tmp3 + 1; tmp4 := tmp4 + 1; tmp5 := tmp5 + 1; END_WHILE out1 := tmp1; out2 := tmp2; out3 := tmp3; out4 := tmp4; out5 := tmp5;
Ваши права
Ответить с цитированием
