Новая версия VOGBIT 20.5 - Новая платформа: быстрее, надёжнее, удобнее. Новая подсистема управления приоритетами в производстве. Новые возможности для участков ЧПУ. Улучшенные «цеховые терминалы». Новые возможности для совместной работы менеджеров, инженеров и производства при изготовлении уникальной продукции под заказ. И многое другое…

Последние темы на форумах VOGBIT

Отображения количества деталей в терминале - Интерфейс программы
1113: Доброго дня.  Предлагаю в терминале Тип 1 после авторизации, выбора участка и после выбора Заказа в окне выбора детали, выводить не только название детали (или , по сути, технологического процесса) но и количество этих деталей.  Обоснование: если ...
Отсутствие РЦ в дашборде - Терминалы
Freza3mm: Прошу прощения, разобрался. некоректно было настроенно расписание. Текущая смена начиналась в 2020 году а заканчивалась в 2016.
Приходный ордер - Прочее
Константин Чилингаров: Можно настроить шаблон отчёта, в котором по формуле посчитать значение соответствующих столбцов. Более сложные варианты я бы не стал рассматривать. Пояснение: В VOGBIT в тех задачах для чего, в основном, используется в этой программе подсистема ...
Работа с заданиями - Производство
Константин Чилингаров: "Сохранить в Excel" и "Отчёты" (reporter, который использует "шаблоны") - это разные инструменты, они работают по-разному. С настройкой шаблонов отчётов, если интереса/желания/времени глубоко в эту тему погружаться не ...
Производственные заказы - Производство
Константин Чилингаров: Здравствуйте, Начало - дата, когда было создано первое задание, связанное с этим заказом (картой заказа). Окончание - когда для данного заказа (карты заказа)  была нажата кнопка "Отметить, как законченные" в окне, которое у вас на карти ...
Исправление количества сданных изделий - Производство
Константин Чилингаров: Здравствуйте, Да, нормальная инструкция. Для "среднего" уровня актуальна. Это для случая, мех обработки или сборки несложной, когда сдаётся по количеству и нормо-часы закрываются по нормативам при этом (терминал "тип 2"). ...
Транспортные расходы - Прочее
Константин Чилингаров: Здравствуйте, Данная программа не предназначена для учёта расходов в понимании, например, финансового отдела. Таких как затраты на электроэнергию, транспорт, содержание помещений, вспомогательных служб и т.д. и т.п. Она просто не для этого.  Ч ...
Выполнение нескольких заданий одновременно. - Терминалы
Константин Чилингаров: Здравствуйте, Маловато исходной информации пока, чтобы что-то сказать. Какая цель (применения программы в данном месте)? Нужно просто отмечать и видеть, что кран такой-то закомплектован, кран такой-то закомплектован и т.д.? Или это какая-то сл ...
Удаление папки - Прочее
Наталья Захарова: Все получилось, спасибо.
Штрих код на деталях - Производство
Константин Чилингаров: 18336 Fomina написал: Я правильно понимаю, что в текущей версии штрих-код назначается автоматически? Если речь про тот штрих-код, который в "графике производства", то достаточно давно уже он назначается автоматически при создании задан ...
Колонка "Наладка" в Статистике производства - Прочее
Константин Чилингаров: Здравствуйте, Это для учёта работы наладчиков станков с ЧПУ. https://youtu.be/KnCDki8k-9Y?t=819 Вот из этой серии (13:39) Потом фильтр по этой колонке ставишь в "Статистике производства" и нужную группировку (например, по людям->д ...
Активация/деактивация - Активация, Деактивация, Лицензии
Константин Чилингаров: Здравствуйте, 3520 Alex-220781 написал: В новой версии 20.5 по прежнему есть ограничение на количество деактиваций? Да. 10 шт. В следующей версии, вполне вероятно, появится новый тип лицензий, которые можно будет запускать на разных компьюте ...
Пустой бланк - Демо версия
Константин Чилингаров: Можно, конечно. Если сами умеете - корректируйте. Если сами не умеете, то можем мы по вашим пожеланиям за скромную плату. В последнем случае - пишите на почту свои пожелания. Желательно, максимально подробно. Обсудим.
Календарный план - Производство
Константин Чилингаров: Здравствуйте, Посмотрел. Действительно. В "Графике производства" цветами раскрашивается по приоритету (по нажатию кнопки соответствующей), пока не "готово". Позиции, которые имеют состояние "готово" перестают раскра ...
Аналоги в материалах - Материалы, Комплектующие, Складской учёт
Константин Чилингаров: Это погрешность округления. Коэффициент пересчёта округлили до 3 знаков, когда вводили (стоит в базе кг->м = 0,004). В итоге при пересчёте 698 кг в метры получается 2,792. Что уже не совсем точно. Если потом пересчитать обратно в метры (по тому ...
Статистика производства - Прочее
Константин Чилингаров: Дело в том, что «Техпроцесс» (то, что открывается по кнопке «Технология подробно» на изделии) и «Задания» (то, что открывается по двойному щелчку или по «выполнение» в «графике» производства») – это не одно и то же. Это разные вещи. Связанные между с ...
Пропадают спецификации и техпроцессы - Прочее
Наталья Захарова: Здравствуйте. Спасибо!
Ошибка при попытке сформировать отчет - Ошибки в работе
Константин Чилингаров: Отчёт из "Статистики производства", я так понимаю? При последнем обновлении меняли все бланки отчётов из этого режима на новые. Причина ошибки - не заменён бланк - старый, от старой версии сейчас в базе у вас лежит сейчас. Обновление пост ...
Ошибка - Ошибки в работе
Константин Чилингаров: Место кончилось. Если стоит бесплатный SQL (Express edition), то у него  ограничение по максимальному размеру базы данных = 10GB. Скорее всего достигнуто это ограничение. Как временно спастись: 1. Сделать резервную копию базы данных. 2. Через ...
Первый запуск терминала - Терминалы
Константин Чилингаров: Каждый тип терминала заточен под определённый "уровень" и определённые особенности. Из доступных на сегодня для «высокого» уровня предназначены типы 3,4,5 и 6.  3,4 и 5 – это разные вариации на тему изготовления деталей (или несложных ...

Производительность ПК

Вопросы, связанные с установкой и запуском программы - Установка - Вопросы новичков
Страницы: 1
Производительность ПК
 
Здравствуйте.
Возникла такая проблема. Мы имеем производственные заказы на одни сутки в количестве от 400 до 500 шт., количество изготовляемых деталей на все эти заказы может составить примерно от 500 до 1500 шт., и изготавливаем все это на 140 постах.
Вопрос: Мы не можем понять почему так медленно работает программа и так долгоооооооо думает.
Мы имеем следующий ПК:
Intel Core I 3 – 4 ядра — 3.4 Ghz и 4 Гб ОЗУ. (Windows 7)
Вот пример как работает на 120 заказах..
1. Перевожу из производственных заказов в режим график производства все 120 заказов и это занимает у меня от 20 до 30 минут или вообще программа не отвечает.
2. В графика производства, создать задание, у меня занимает про времени от 4 до 7 часов.
3. На одном рабочем месте закрываю все заказы как выполненные за одну смену, программа закрывает их часа два... и т.д.
Когда программа работает смотрю загрузку ресурсов ПК, показывает что из 4 ядер не работает не одино и загрузка ЦП составляет 1-4%, ОЗУ загружено только файлами windows.
В чем проблема и как решить ее пока ума не приложим....может у вас была такая проблема?
 
Здравствуйте,

Да уж. Цифры (длительность) заоблачные какие-то.

1.
1500 наименований деталей в день на 140 постах...
Неплохо так...

При реальной работе с такими объёмами надо SQL сервер, мне кажется, ставить уже не на бытовой компьютер с 4G ОЗУ. Тут надо какой-нибудь настоящий сервер уже. С быстрыми винтами, много памяти, много процессоров...

2.
Вот это:
Цитата
Евгений Спиридонов пишет:
Когда программа работает смотрю загрузку ресурсов ПК, показывает что из 4 ядер не работает не одино и загрузка ЦП составляет 1-4%, ОЗУ загружено только файлами windows.
странно.

Вы загрузку чего смотрите? Сервера? Или клиента? Или у вас это всё на одном компьютере?
По идее, при таких объёмах сервер должен быть загружен прилично при выполнении каких-нибудь операций типа создания заданий. И процессоры все должны быть загружены и пямять. Тем более, что её мало.
Если этого нет, то такое впечатление, что просто ничего не происходит.

3.
Как часто вы обслуживаете свою базу и как это делаете?
Вы вообще в этом направлении что-то делаете?

Наводящие вопросы:
Какого размера у вас сейчас база данных (сколько занимает на диске)?
Как часто вы чистите журнал событий? сколько у вас сейчас там записей (сеансов/событий)?
Как часто вы выполняете "пересчёт статистики" для этой базы?

Резюме:
1. Лучший вариант, чтобы сказать что-то поконкретнее - дайте копию базы, посмотрим. Можно сделать резервную копию, выложить её на файлообменник какой-нибудь и прислать нам на e-mail ссылку, где можно скачать.

2. При реальных объёмах, как вы озвучили, нужно использовать в качестве сервера не бытовой компьютер, а настоящий сервер со всеми вытекающими. Также большое значение приобретает регулярное регламентное обслуживание базы данных.
 
Отправил ответ почтой.
 
Результаты испытаний:

В качестве подопытного экземпляра использовался компьютер постарее и послабее вашего:

intel core 2 quad cpu q9550 @ 2.83GHz, 4ГБ

Причём прилично загруженный всяким другим софтом, крутящимся параллельно.

Итоги, выводы:

Пересчёт статистики в этой базе, похоже, никто не делал никогда.

Для начала запустили как есть. График производства для всего, что есть (2114 позиций), открылся примерно за 9 минут.

Пересчитали статистику в базе. График производства на тех же самых данных стал запускаться где-то 7 секунд.

С созданием заданий чистый эксперимент не вышел. Выделил все позиции, какие были без заданий в Графике производства (где-то 900+ по моим подсчётам), и попробовал создать для них всех задания (уровень выбрал «высокий»). Чистота эксперимента была сорвана тем, что постоянно пришлось жать «Ок» на окошки с сообщением типа «Для того-то того-то не создано ни одного задания». То ли техпроцессов там нет на половину позиций в Графике, то ли трудоёмкости. Разбираться не стал, т.к. не в этом был вопрос.

Создавалось, конечно, долго… Но не 7 часов, безусловно.
Где-то минут 40, примерно, с учётом постоянных нажатий на «Ок» в очередном окошке с сообщением.
Потом проверил для сравнения на минимальном уровне на том же объёме – где-то 15 мин. В принципе, не так плохо, учитывая количество и то на каком компьютере это делалось.

Но тут вопрос другой. Тут, всё таки, действительно реально много заданий создаётся за один заход. «Высокий» уровень, и счёт идёт на тысячи (создалось за один раз 1800 заданий где-то). Тут вопрос, нужно ли их создавать за один раз в таком виде и в таком количестве? Предположим, можно взять сервер помощнее, поставить вечером, и минут за 20 всё создастся. И 3, и 4 тысячи заданий. Но надо же ещё дальше что-то делать завтра со всеми этими заданиями. С таким количеством.

Не запаритесь дальше с таким количество созданных за раз заданий работать? Тут надо подумать, мне кажется, как лучше сам процесс организовать, если реально такой поток всего идёт. Может агрегировать как-то, укрупнять. Люди, например, метод «по комплектам» придумали в производстве металлоконструкций. Как раз для решения такого типа проблем (выдача заданий и учёт работ при огромной номенклатуре и большой скорости её изготовления). Может, что-то подобное применить, может, ещё что… Рекомендую обратить внимание на этот аспект. Мало ведь создавать задания тысячами, надо как-то процедуру дальнейшей работы с ними же организовывать.

Резюме:

1. Обязательно регулярно выполняйте пересчёт статистики. Его нужно делать периодически, чтобы база не «тупила». Чем более высокая интенсивность работы с базой, тем чаще надо делать. Хоть каждый день. Времени это занимает несколько секунд (пересчёт). Прирост производительности, как вы видите колоссальный в итоге (по вашей базе, на примере времени открытия Графика производства – с 9 мин до 7 сек) .

2. Пока, как я понял по базе, вы не использовали «высокий» уровень учёта. Только для пробы пример, может, какой-то. Если всерьёз намереваетесь использовать именно «высокий» уровень при таком количестве заказов/позиций/постов, то задумайтесь о кардинальном upgradе'е железа, на котором крутится SQL сервер. Тут уже не простой настольный компьютер нужен, а что-то заметно посерьёзнее.

И от себя рекомендую, в этом случае больше внимания уделить вопросу методологии. Как, кому, и какие задания выдавать, как закрывать их. С практической точки зрения. Если задания создавать каждый день по несколько тысяч, то компьютер то справится, можно в конце концов помощнее поставить. Но дальше то люди должны будут что-то делать с этим огромным количеством заданий. Им то как будет?
 
Чтобы выпустить Пересчёт статистики, нужно подключиться к базе с помощью Managenent Studio и выполнить процедуру:

[Health].[UpdateStatistics]
 
Спасибо большое за анализ!
Пересчет статистики никто не делал - я вот только узнал о том, как его сделать.

По поводу заданий.
Картина следующая. На завод поступает заявка на изготовление, например, 100 изделий. Изделия разные. Конструкции практически одинаковые за исключением размеров. Для повышения производительности, при вводе заявки в vogbit, я завожу описания изделий с разбивкой по группам размеров + все возможные изменения конструкции оформляю отдельными узлами. В итоге оператор выбирает нужные блоки для формирования заявки. Сейчас вручную, потом оформлю все в конфигураторе.
Для каждого рабочего места формируется задание. Оно и сейчас формируется, но вручную, наобум, по такому же вручную сформированному заводскому графику. Поэтому точности в планировании нет никакой.
В конечном итоге сейчас я пытаюсь запустить реальный, подтвержденный трудоемкостью, документооборот в производстве при помощи Vogbit, заменив им ручной, создаваемый методом тыка.
Не думаю, что трудоемкость работы с программой будет выше ручных перестановок в графике в попытках угадать реальные сроки изготовления. Но посмотрим.
Думаю, что можно будет разбить обработку заказов на группы по определенным параметрам изделий. В крайнем случае выработаем алгоритм постановки изделий в производстве (очередность).

По поводу «Для того-то того-то не создано ни одного задания» - не все производства описаны. Полуфабрикаты изготавливаются на другом заводе, поэтому описания на часть деталей условны (только материалы, без операций) - чуть позже доделаю.

По поводу методологии - спасибо, будем думать над вопросами оптимизации работы. Работники в любом случае все эти операции выполняют. С другой стороны часть операций можно объединить, если они производятся на одном и том же месте теми же людьми, либо если операции имеют схожую технологию и являются соседними.
Большая группа деталей будет или уже изготавливается по отдельным графикам. Это детали постоянного и группового применения. В составе изделия они фигурируют уже в качестве комплектующих.

По поводу учета. У нас пока все шаги были пробными. Задания формировали на большое количество изделий на высоком уровне учета. Проблемы с производительностью "вылезли" буквально пару дней назад. До этого особых проблем не было.
Видимо, все же, вопрос в том, что не производился пересчет статистики - это поправим.
Изменено: Валерий - 06.12.2014 06:38:31
 
Сделали пересчет статистики - забегало в разы шустрее.
 
А не думали логи хранить не в базе, а отдельном текстовом файле, чтобы не чистить его постоянно для повышения отзывчивости системы или, хотя бы, задание глубины сохранения?
 
Цитата
Валерий пишет:
не в базе, а отдельном текстовом файле
это плохое решение.

Цитата
Валерий пишет:
задание глубины сохранения?
Думали.
В предыдущей программе у нас так и было. Тогда был типичный вопрос: "А нельзя всё писать? Пусть будет, мы разберёмся..."

P.S.
Постоянно не нужно чистить. Достаточно иногда.
А вот пересчёт статистики можно делать почаще. Лучше всего поставить его, как задачу в scheduler.
 
Пересчет статистики стоит автоматом каждую ночь, но хорошо помогает, когда и логи вычищены.
 
После массового удаления чего-либо (в частности, сеансов) неплохо также запускать процедуру [Health].[RefreshDependencies]. Можно сделать сжатие базы данных (shrink). Но это точно не нужно делать слишком часто.

https://vogbit.ru/forum/messages/forum16/topic1127/message6997/1127#messages6997
 
А если ли вообще способ очистки событий в сеансах, в нашей базе на данный момент находится порядка 2 миллионов событий, как их очистить?
 
Зайти в Администрирование - Сеансы.
Выделить все закрытые сеансы (у которых дата закрытия не пустая).
Нажать удалить.
И ждать, пока удалится...

После этого сделать Shrink базы данных, пересчёт статистики и зависимостей.

И резервную копию базы данных перед всем этим не забудьте сделать, конечно.
 
У нас тоже стала "подвисать" программа, особенно когда работаем в окне подразделения, привязываем участки к постам, людям и прочее.
Также при формировании графика производства - очень сильно стал подвисать. Вопрос с покупкой сервера уже решен (я в это чайник) - и знаю только как чистить сеансы. А все что у вас выше описано знать не знаю как  (и сис. админ как раз уволился :cry: ) А раз ответственный за вогбит я, то хотелось бы быть в курсе, как увеличить производительность программки, потому как если хоть один человек сидит в режиме подразделения и корректирует там что то, у всех пользователей все подвисает, людей это бессит, в прямом смысле этого слова;)
Какую нибудь бы инструкцию для чайников надо бы :)
Изменено: Анастасия Алексеева - 27.10.2015 19:45:37
 
Чтобы не "подвисало" нужно обслуживать базу данных:

- делать пересчёт статистики (хоть каждый день);
- иногда хотя бы удалять из базы ненужную информацию (сделав предварительно резервную копию). Т.е. , как минимум, чистить протокол действий пользователей. На высоком/максимальном уровне периодически полезно задания по старым заказам удалять (если у вас не такой мощности сервер, конечно, которому просто всё равно).
- после массового удаления чего-либо (чистки) делать пересчёт зависимостей, сжимать базу штатными средствами SQL, делать пересчёт статистики.

Это всё на форуме уже много раз писалось.

Если информации на форуме не достаточно, то оплачивайте поддержку, мы вам лично напишем персональную инструкцию "для чайников".
 
Формирование заданий из 100 деталей на минимальном уровне в течении 3-5 минут это норм для программы? Установили новые современные сервера (думали проблема в них), делаем периодически перессчет статистики, удаляем переодически события, но производительность совсем не улучшилась. Чуть только стоит залезть в подразделени - настройка постов, участов, что либо поменять, удалить,добавить- зависание всего. Работа с графиком производства, формированием заданий - зависание - что же будет если перейдем на более высокие уровни? Сотрудники очень не довольны - особенно когда аврал в работе
 
Ну пришлите базу посмотреть что ли... Глянем, что там у вас...

Да, процедура создания заданий достаточно ресурсоёмкая. Несколько минут - это нормально.
Сколько по времени вы изготавливаете эти 100 партий деталей?

Цитата
Анастасия Алексеева пишет:
только стоит залезть в подразделени - настройка постов, участов
А зачем туда лазить то?

а) это ж настраивается 1 раз в жизни. Ну, может, потом как-нибудь ещё пару раз в жизни зайти, что-нибудь поправить или ввести одну-две строчки ещё. Зачем туда лазить то всё время в это место?

б) На минимальном и среднем уровне "посты" вообще не нужны.

Цитата
Анастасия Алексеева пишет:
же будет если перейдем на более высокие уровни?
Думаю, принципиально от этого ничего не изменится. задания будут создаваться несколько дольше, чем на "минимальном", но примерно так же, как на "среднем" уровне учёта. В остальном - то же самое примерно.
 
Цитата
Константин Чилингаров пишет:
А зачем туда лазить то?
есть текучка кадров - вот и приходится лазить, хоть пока и не нужны на минимальном уровне - но поддерживать порядок все ж необходимо, хотя думаю с нашим то авралом нам очень долго не перейти на средний- максимальный уровень, т.к. обработка требует времени, которого у нас нет(

Понятно, что в принципе это не дольше, чем сидеть прописывать задания для рабочих в ручную - тут скорее всего менталитет - хочется все быстро и сразу)
 
Я бы не рекомендовал возиться с заведением работников до тех пор, пока это реально не понадобится.
На "среднем" уровне они не нужны.
Когда вы реально дойдёте до "высокого" или "максимально" - не ясно. За это время тысячу раз всё поменяется, а вы будете всё это время делать лишнюю, бесполезную работу. Человек придёт - вы его заведёте, уйдёт - вы его удалите. Поскольку реального персонального учёта в программе в это время не ведётся - в этих действиях нет никакого смысла. Что выполняли их, что нет - результат одинаковый.

ИМХО, проще сесть, потратить некоторое время и ввести, когда реально будет нужно.
Суммарно это в итоге будет, по-моему, меньше по времени, чем потратится за месяцы на постоянное поддержание актуальности базы, которой всё равно не пользуешься.

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

P.S. Операции с привязкой работников к подразделениям выполняются действительно довольно долго. Но и делать их массово приходится редко.
Страницы: 1
Сейчас на форуме (гостей: 9)
Всего зарегистрированных пользователей: 3166
Приняло участие в обсуждении: 364
Всего тем: 804
Всего сообщений: 6067

Полезные ссылки:
Видео-презентация подготовка производства Себестоимость Расчёт комплектации загрузка оборудования Складской учёт расчет себестоимости ТПП Демонстрационный режим VOGBIT Обновление VOGBIT График производства технологическая подготовка производственный учет складской учет Полная версия VOGBIT Создание новой базы данных VOGBIT управление данными Планирование мелкосерийного производства Техническая Подготовка Производства электронный архив деактивации VOGBIT управление качеством активация VOGBIT управление производством Производственный заказ Установка VOGBIT управление ремонтами Трудоёмкость Деактивация VOGBIT планирование производства базы данных VOGBIT инструкция Начало работы склад Сменное задание Задания для производства Тип нормирования Заказ на производство производство металлоконструкций Нормирование пост руководство администраторов VOGBIT Планирование производства разработчика отчетов vogbit состав изделия демоверсия технология Состав изделия Обзор обновления Генератор отчетов Отпуск со склада металлоконструкции Затраты на производство Указания по заполнению техпроцесса VOGBIT Подробная информация о задании Демо-версия VOGBIT
×
Вход на сайт