Системные требования для SMArt

[gaa]

Всем доброго времени суток. Столкнулся вот с такой проблемой: при работе в SMArt-е создал 5 экранов. В каждом экране по ПВ-системе с предполагаемый последующей анимацией.(вент. крутятся, горелка горит и т.д. по 3 картинки на объект) При увеличении картинок на экранах, SMArt начинает думать все дольше и дольше. Дошло до того что открытие проводника для загрузки картинки доходит до 3-4 минут. При этом все остальные программы открытые на соседнем мониторе не зависают и адекватно работают. Я поковырялся в хелпе, на сайте и не нашел рекомендуемых системных требований для SMArt только для SMLogix, но они там очень старые. Сейчас у меня процессор Core(TM) i7-3630QM CPU 2.40GHz Оперативная память 8.00 ГБ видео карта Radeon HD 7600M Series Можете подсказать рекомендуемые системные требования.

[Arsie]

Цитата

Сообщение от gaa

Всем доброго времени суток. Столкнулся вот с такой проблемой: при работе в SMArt-е создал 5 экранов. В каждом экране по ПВ-системе с предполагаемый последующей анимацией.(вент. крутятся, горелка горит и т.д. по 3 картинки на объект) При увеличении картинок на экранах, SMArt начинает думать все дольше и дольше. Дошло до того что открытие проводника для загрузки картинки доходит до 3-4 минут. При этом все остальные программы открытые на соседнем мониторе не зависают и адекватно работают. Я поковырялся в хелпе, на сайте и не нашел рекомендуемых системных требований для SMArt только для SMLogix, но они там очень старые. Сейчас у меня процессор Core(TM) i7-3630QM CPU 2.40GHz Оперативная память 8.00 ГБ видео карта Radeon HD 7600M Series Можете подсказать рекомендуемые системные требования.

У меня на гораздо более слабом ноутбуке (Pentium-Dual первого поколения, 1.86ГГц, 4Гб памяти) работает явно очень быстрее. Думаю, не в системных требованиях дело.

Приложите хоть ваш проект, чтобы посмотреть, что у вас там и как. Может у вас по 100500 картинок на один экран и каждая картинка смасштабирована с разрешения 10000х10000.

Опять же, откройте системный монитор, посмотрите, в чём там затык. В памяти или процессоре. Вы же нигде не найдёте системных требований именно под ваш проект. 8-процессорный сервер обычным блокнотом можно нагрузить так, что он подавится и документ открывать полчаса будет. Вопрос не в требованиях к блокноту, а в документах, которые вы открываете.

[gaa]

Прикладываю программу. Сейчас закрыл-открыл проект стал пошустрее работать. Около 30 картинок на одном экране. Отсюда еще один вопрос: а сколько таких экранов можно в Trim залить? Точнее на сколько большая память у него?

[Arsie]

Цитата

Сообщение от gaa

Прикладываю программу. Сейчас закрыл-открыл проект стал пошустрее работать. Около 30 картинок на одном экране. Отсюда еще один вопрос: а сколько таких экранов можно в Trim залить? Точнее на сколько большая память у него?

Да нет, вроде быстро шевелится. Задержек более 5 сек не было нигде, картинка добавляется и открывается мгновенно.

Таких экранов не знаю, как обычно всё упирается в ОЗУ и картинки. Пока они влезают в ОЗУ, всё нормально. Откопипастите свой экран несколько раз и сами увидите, сколько влезет.

[gaa]

Значит буду разбираться с ноутом. Спасибо за помощь.

[gaa]

Проблема найдена, в вин8.1 загрузка жесткого диска на 100% почти все время работы. Из-за этого все что требует обработки картинок очень медленно работает. С системными администраторами пытаемся решить проблему.

[ViS]

Обычно такая загрузка диска бывает, если не хватает ОЗУ и система начинает активно пользовать свап. Выгрузите/закройте лишние программы при работе в Лоджике.

[gaa]

Еще один вопрос по данной программе. Пока к Trim подключено slave-ов 1шт все работает адекватно, стоило подключить 8 таких же slave-ов как задержка передачи сигнала от мастера к слейву примерно 10 сек. Сигнал доходит правильно не теряется. Можно ли каким-то образом ускорить передачу данных? Может можно как то оптимизировать переменные ModBBus?
Проект прилогаю

[gaa]

Хорошая мысль пришла ночью! проанализировал переменные modbus и понял что у меня на каждый слейв по 25 запросов! Думаю дело в этом! В слейве отсортировал переменные по назначению и по типу, удалил явно лишнее переменные, переместил все в одну кучу, залил новую карту памяти в мастер. Результат, количество запросов уменьшилось до 7 постоянных и 3 по требованию. Сегодня причешу остальные слейвы, надеюсь это поможет!

[Arsie]

Цитата

Сообщение от gaa

Хорошая мысль пришла ночью! проанализировал переменные modbus и понял что у меня на каждый слейв по 25 запросов! Думаю дело в этом! В слейве отсортировал переменные по назначению и по типу, удалил явно лишнее переменные, переместил все в одну кучу, залил новую карту памяти в мастер. Результат, количество запросов уменьшилось до 7 постоянных и 3 по требованию. Сегодня причешу остальные слейвы, надеюсь это поможет!

Конечно поможет. Это называется оптимизацией трафика)

[LordN]

Цитата

Сообщение от gaa

Хорошая мысль пришла ночью! проанализировал переменные modbus и понял что у меня на каждый слейв по 25 запросов! Думаю дело в этом! В слейве отсортировал переменные по назначению и по типу, удалил явно лишнее переменные, переместил все в одну кучу, залил новую карту памяти в мастер. Результат, количество запросов уменьшилось до 7 постоянных и 3 по требованию. Сегодня причешу остальные слейвы, надеюсь это поможет!

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

[Arsie]

Цитата

Сообщение от LordN

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

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

[LordN]

Цитата:

Сообщение от Arsie

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

разве? хм, точно. а раньше тоже так было?

[Gromov]

флоты, лонги и инты - это представление лоджика или кого-либо другого. Для модбаса есть только койлы (битовые) и регистры (16-ти разрядные). Так что лонг - это 2 регистра по 16 разрядов. Рил - то же самое. Это уже потом, на уровне OPC или контроллера вы эти биты перепаковываете в то, что вам надо. А модбасу наплевать.

[LordN]

Цитата

Сообщение от Gromov

флоты, лонги и инты - это представление лоджика или кого-либо другого. Для модбаса есть только койлы (битовые) и регистры (16-ти разрядные). Так что лонг - это 2 регистра по 16 разрядов. Рил - то же самое. Это уже потом, на уровне OPC или контроллера вы эти биты перепаковываете в то, что вам надо. А модбасу наплевать.

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

[Arsie]

Цитата

Сообщение от LordN

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

100%

[gaa]

Спасибо всем за подсказки. Причесал карту памяти. Результат такой, время ожидания прихода команды ~3 сек. Это меня пока устраивает, Но скорее всего я еще и битовые сигналы запакую в int и сокращу число запросов еще на 2 на каждом слейве,а на весь проект это 16 запросов. Удачи мне.

[LordN]

Цитата

Сообщение от gaa

Спасибо всем за подсказки. Причесал карту памяти. Результат такой, время ожидания прихода команды ~3 сек. Это меня пока устраивает, Но скорее всего я еще и битовые сигналы запакую в int и сокращу число запросов еще на 2 на каждом слейве,а на весь проект это 16 запросов. Удачи мне.

иногда удается упаковать биты в уже имеющиеся инты или лонги. например инт передает значения от 0 до 100, значит старший бит уже можно использовать для упаковки. и т.д.

[Gromov]

Цитата

Сообщение от LordN

иногда удается упаковать биты в уже имеющиеся инты или лонги. например инт передает значения от 0 до 100, значит старший бит уже можно использовать для упаковки. и т.д.

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

[LordN]

Цитата

Сообщение от Gromov

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

ситуации бывают разные и универсальных рецептов не бывает. как и лишнего знания.