MadHacker писал(а):AlexRuden, вы невнимательны. Держите. Пишите что душе угодно.
http://www.bolid.ru/soft/object/object_34.html
MadHacker писал(а):Забавно читать. AlexRuden, сможете привести хотя бы один пример, в котором вам не хватит скорости существующих интерфейсов, для решения задачи?
И если не секрет, какие возможности вы надеетесь увидеть на низком уровне? :)
MadHacker писал(а):Я не пользователь. Я разработчик.
:) Будут улучшения. Но не скоро.AlexRuden писал(а):Если Вы засланец Болида, то так и скажите - " жрите что дают, не будет улучшений ".
AlexRuden писал(а):
4500 АУ ДИП34, 4 Пульта , 50 КДЛ - полное снятие/постановка на охрану занимает минут 20-30 ..
тем более, сфера применения Вам должна быть известна больше чем рядовым пользователямMadHacker писал(а):Обычные ПК. Я не пользователь. Я разработчик.vasilich писал(а): Расскажите какие платформы Вы используете для работы серверных процессов болида?
Вот тут я с Вами не соглашусь, во первых приборы не умеют заводить пользователей в системе не умеют строить отчеты, не умеют управлять уровнем доступа, а функционирование системы определяют именно по этим операциям, делить функционал системы на приборы и ПО не логично, во-вторых нормальном корпоративном софте должна применять схема клиент-сервер, если раскрыть задачи в этой схеме "сервер" то окажется что "будка охранника" это серверная?)) или нечто больше чем клиент но еще не сервант). Самое простое решения в такой ситуации избавиться от COM интерфейса совсем. Два метода как я и писал раньше, для таких как я например http://www.moxa.ru/good/show/14885/1871592/ или для любителей паяльников любой из http://www.moxa.ru/good/listAll/14885/?&utm_sourc ... lid=COya9MOAyrACFckvmAod03JlYA Я думаю болид самостоятельно может решить такую задачу выпустить C2000 с сетевым интерфейсом и веб-мордой, и все, можно ставить ядро опроса хоть на луну. В моем случае "будка охраника" выглядит так, 2 HDMI монитора на 24" офисный комп на i5 и мощной видео картой, по COM подключен C2000, система видео наблюдения "клинет" грузит 65 ip камер, производительность железа на приделе, а тут еще ядро опроса сбоку... которое и само по себе не стабильно, а в комплексе с местом произрастания рук проживающего в будке, с гигантской сетевой и процессорной активностью клиента видео наблюдения, сводит всю систему до не рабочего положения.Из всех программных модулей Болида серверным можно назвать только центральный сервер Орион. Остальные модули создавались под самые обычные пользовательские рабочие места. Потому что чаще всего сигнализация вся сводилась в какую-нибудь будку охранника, куда никто никакой сервер ставить в жизни не будет. Безопасность, стабильность и надёжность обеспечивают приборы. Софт должен обеспечивать удобство пользователя. И в этом плане недостатки у него пока имеются.vasilich писал(а):Или использовать под сервант "не сервант"? Других вариантов нет, я себя лично отношу к последним, база у меня на нормальной платформе, а ядро на рабочем месте за 30р, что сервером быть не может по определению, значит заявления безопасность\стабильность\надежность это фарс.
Да не правда. Главное не изобрети велосипед. Не знаю как там на Wтварях, знаю как на HyperV вот окно настроек COM порта на виртуальной машине (гостевой ОС)В том, что туда его ещё надо прилепить, через какой либо софт, который как минимум будет вносить задержку. А в более неприятной ситуации сможет добавить глюков, которые будет очень тяжело выловить.vasilich писал(а):Это почему ж нет, в чем разница между COM на виртуальной машине от физической?
ИМХО костыли это прерогатива исключительно пользователя, производитель ПО должен использовать надежные проверенные решения, другой вопрос, если производитель этого не желает. Проблема с терминальным доступом загадка, лицензия вроде как на рабочее место, а то что одно рабочее место может запустить много клиентов болиду не известно, они до сих пор живут в плоскости windows XP. Что значит "более распространёнными" вы имеете ввиду пока у вас на рабочем столе не появится виртуальная среда? ну так поставе себе HyperV core он бесплатный) а вдруг понравится))). ИМХО использование сервера без виртуализации за редким исключением специализированных систем типа iSCSI и т.п. считаю не профессионализмом и бесполезной тратой денег. Рядовой сервант на рынке стоит от 80т р. все что до, это не сервера, ну возникает вопрос который я уже писал, не жирно ли болиду 80т р. только за платформу на которой будет 0,00000001% процессорного времени занимать ядро опроса вместе с MSSQL? +АПСы +уровень сетевого доступа +место в шкафу оно то не резиновое, и целом сумма на 1-2U набежит приличная...Вот вот. Ком всё равно притаскивать. В лучшем случае расстояние позволит завести все провода в серверную и подключить. В худшем - придётся использовать какие-нибудь ухищрения.vasilich писал(а):Виртуальные среды удобнее запускать в кластерной среде на высоко производительных серверах, где миграция от железа больше не зависит, и ситуация когда выход из строя какого либо компонента физического сервера влияет на работу системы, не возможна. Единственный минус это привязка COM к конкретному железу, да и то решается COMtoEth.
Не рассчитана система изначально под облака, терминалы и высокопроизводительные кластеры. Можно добавить какие нибудь костыли, чтоб она заработала в таких условиях, но лучше от этого не станет.
Когда облака станут более распространёнными - появятся соответствующие решения.
http://bolid.ru/production/devices/devices_155.html Но просто запихнуть ком в сеть не лучшая идея. Работа по кому это большое количество мелких пакетов, а сети такое не любят.vasilich писал(а):Я думаю болид самостоятельно может решить такую задачу выпустить C2000 с сетевым интерфейсом и веб-мордой, и все, можно ставить ядро опроса хоть на луну.
Отличный девайс, вопрос удаленности на нем можно реализовать, но для виртуализации этого мало, хотелось бы реализацию как выше мной описанных, когда СОМ вообще исключен. И для реализации такой схемы нужен будет только один C2000. Ну от чего же "большое количество мелких пакетов" должно влиять на сеть? если пакет правильно сформирован проблем не должно быть, на то она и сеть, если речь идет о нормальной корп.сети а не SOHO коммутаторах, ему будет параллельно какого размера пакеты и с какой частотой они будут идти, да и VLAN спасет мир. Изолированная сеть чисто для обмена C2000 и Ядром.MadHacker писал(а):http://bolid.ru/production/devices/devices_155.html Но просто запихнуть ком в сеть не лучшая идея. Работа по кому это большое количество мелких пакетов, а сети такое не любят.vasilich писал(а):Я думаю болид самостоятельно может решить такую задачу выпустить C2000 с сетевым интерфейсом и веб-мордой, и все, можно ставить ядро опроса хоть на луну.
По чему это не загадка, я имел ввиду лицензия продана как на рабочие место, а по сути на клиента. Не могу сказать за всех, но мне в чистом виде терминальная служба не нужна, да и это плохая практика, от не опытности администрирования. А вот когда например доменный пользователи на одном ПК работают посменно, один со смены ушел заблокировал свой логин, второй не может запустить болид на том же ПК под своей учетной записью потому как "пользователь" не может выгнать "пользователя", а болид запущенный в той сессии не позволяет запустить его в новой сессии пользователя. (каша получилось но думаю понятно) Источник проблемы ясен, софтина запущенная в одной сессии использует статичный исходящий портБолее распространённым - это письма от пользователей с просьбами добавить полноценную поддержку.
Терминалы не загадка. Просто там сетевые порты одни на всех. Над этим уже работаем, но говорить про сроки не возьмусь. В 1.12 терминалы точно не попадут.
Это функция операционной системы "смена пользователя") не отнимайте хлеб у макрасофтMadHacker писал(а):Для дежурств по сменам как раз и была сделана смена дежурства в мониторе.
Дык так нравился атоввод пароля в ОЗ "Орион".MadHacker писал(а):Предполагалось, что всё это будет крутиться под одной учёткой. Оно долгие годы так и было. А сейчас всё меняется. Меняется очень быстро, а статистики по реальным условиям использования софта нет.
MadHacker писал(а):Всё ещё хужеСофтины используют входящий статический порт. Отсюда и вся беда с многопользовательскими режимами.
Для дежурств по сменам как раз и была сделана смена дежурства в мониторе. Предполагалось, что всё это будет крутиться под одной учёткой. Оно долгие годы так и было. А сейчас всё меняется. Меняется очень быстро, а статистики по реальным условиям использования софта нет.
Вот и про проблемы с многопользовательским режимом знаем. Но. Жалобы есть? Нет. Следовательно единичный случай. Откладывается.
В простом Орионе тоже доступно кеширование.Sia-Ori писал(а):В Орионе-ПРО это ещё как-то возможно, конфигурация кэшируется, а в просто орионе - никак.
Считается что чтение конфигурации делается один раз и далее всё благополучно работает.Sia-Ori писал(а):И зачем, спрашивается, сначала считать ключи из всех приборов, поработать в АБД и синхронизировать их, если перезапись занимает ровно столько же всемени, как и чтение конфигурации. Хотя нет. Перезапись быстрее! Не ситывается при этом железная конфигурация.
Попробуйте после этого по ней пройти ;) . Волноваться за судьбу этой карточки не стоит. Работать она не будет, а при первом удобном случае на её место запишется новая.Sia-Ori писал(а):Если карту просто удалить - она остаётся в контроллерах.
Именно периодически и ночью. На такую работу эта функция и рассчитана. А для повседневной жизни придумана синхронизация.Sia-Ori писал(а):Вобщем, периодически перезапись нужна....
...Перезапись выполняется только поштучно, потому как полная перезапись займёт часа два три, и это ночью, когда никто не ходит.
Так бы слушал и слушал... Вам бы сказки писать.MadHacker писал(а):Считается что чтение конфигурации делается один раз и далее всё благополучно работает.
С 1.11 точно есть, да и раньше скорее всего был.Sia-Ori писал(а):С какой версии в Орионе-про удалённый ключ затирается в контроллерах? Sp2 - такого ещё нет.
Вернуться в «АРМ Орион Про версии до 1.20»
Сейчас этот раздел просматривают: 1 гость
Боты: Google [Bot]