Подружить турникет с 1С. #716524

Добрый день! Стоит такая задача. И чтоб считыватель перед открытием турникета ходил в базу и 1С принимал решение и давал команду в турникет. Готовые решения не интересуют. Нужно в рабочей конфе дописать такую штуку. Кто нибудь похожее делал? Какое железо посоветуете, как лучше реализовать? Думаю считывание однозначно внешнее событие.

а какое решение в 1С принять может? пропускать или нет?

Ну да, пропускать или нет. Именно 1С должен решать, а не контроллер(обычно контроллер имеет память и там хранятся идентификаторы пропусков).

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

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

1) Попробовать обратиться к изготовителям турникета, чтоб дали документацию на свою поделку (чтоб узнать, какие команды что делают). 2) по кому подключиться к ПО турникета и выполнять требуемые действия.

А если считывание производить мимо турникета?

Ставьте СКУД, прикручивайте 1С. У нас так сделано. 1С, правда только данные входа-выхода для табели рабочего времени используется, управлением входа-выхода, перехода по кабинетам, правам доступа - занимается СКУД. А ты, судя по задаче, хочешь скуд на 1С сделать :) См. первую ссылку

:) Тогда ставишь там охранника, который, получив ответ от 1С, нажимает или не нажимает кнопку пропуска:)

я придумал: считыватель турникета установить таким образом, чтоб он был под лотком сидирома компа, на котором все это крутится. Из 1С открываешь лоток сидюка, к которому примотана проксимити-кард, отпирающая турникет. Сидюк открывается, карточка подъезжает к считывателю... Профит!

эта пять, поржал:)

Это неправильный способ. Нужно из 1С при изменениях выгружать списки в СКУД, у производителя должен быть API. Но принимать решение турникет должен автономно.

Да, хочу, но это будет громко сказано СКУД

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

+ обычно на входах ставят считыватели (пальцесканы, сканы карточек, мордосканы) с автономным режимом (на случай потери связи с контроллером). Где-то в сети стоит контроллер с ПО, в который занесены сотрудники, разрешённое время входа-выхода, регистрация событий в базе. Это же ПО может выгружать данные для 1Ски, для последующей обработки.

500+ человек у нас в автономной памяти считывателей: лица, пальцы, ключи. Как-то хватает :)

Ну и если пропадает связь с контроллером - люди всё равно проходят, регистрируются считывателем, после восстановления связи - считыватель просто сбрасывает контроллеру накопленную инфу, и всё

Ему надо интерактивно открывать. Вообще, в АСКУЭ важна скорость принятия решения. У нас поставили отпечатки пальцев - на проходной начался коллапс. Потом быстренько убрали - и поставили обыкновенные проксимити считыватели. Автор, если у тебя будет по кому соединяться, то, имхо, твой турникет будет нормально работать разве что в Эстооооонии. Чем меньше инфы передается - тем быстрее реакция. Тебе ж сказали - свяжись с разработчиками турникета, пусть дадут мануалы. Загрузишь себе в базу в какой-нить РС комбинацию - Сотр-проксимити_код и будешь потом давать указание турникету. Но опять же, ооочень медленно...

У нас каждый день по 1000 новых записей, причем, вчерашние уже не действуют. Это значит что нужно все перезаписать, не выдержит контроллер то.

по 485 аж 12 цифр, но все летает; обратно замыкание контакта - со скоростью света, время устраивает

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

Для этого существуют сервера и ПО, которые управляют СКУД. Делать аналог на 1с - это бред имхо.

1С конфигурируется и конфигурируется в несколько раз дешевле.

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

Не совсем понял, какую информацию загружать в контроллеры?

там файрберд используется - подключаешься и читай-заноси данные,если что Delphi, C# в руки и вперед.

> У нас каждый день по 1000 новых записей, причем, вчерашние уже не действуют. Это у вас бардак какой-то с организацией.

считыватель подрубить к 1С не проблема (если он к приему USB HID) вот с командой на открытие повозитесь подбирая по цене/качеству/удобству можно поискать тут например

+ еще вот это забыл к розетке

с Парсековскими пробуй. Я у них юзаю обычный карт считыватели. Год эксплуатации полет нормаьный. драйвера для 1С были но они оказались платными на каждое рабочее место пришлось свои дрова написать.

У нас на предприятии стоит "Система контроля и управления  доступом GATE".

+ У поставщика решения есть наработки и для 1С.

Что за мания "Подружи **** с 1С"? "чтоб считыватель перед открытием турникета ходил в базу и 1С принимал решение и давал команду в турникет"... Ха-ха-ха три раза !!! Представляешь, что такое считыватель? Это тупая железяка, задача которой считать и дать доступ согласно определенному алгоритму. Как??? КАК ЭТО БЕСТОЛКОВАЯ ЖЕЛЕЗЯКА (!!!) БУДЕТ "ХОДИТЬ В БАЗУ 1с"???

Мы сделали свое программно-аппаратное решение, аппаратная часть - плата с контроллером, управляющая силовыми электромагнитами (двигателями) + raspberry pi с базой данных для доступа и записи событий. Решение о допуске принимает софт на raspberry. В базу данных на raspberry пишется информация по доступу из 1с по сети, а также 1с считывает из нее события для отчетов и т.д.  Таких устройств стоит более 10 на объекте. База 1с одна централизованная.

как ощущения? Полностью покрывает Ваши потребности?

Что мешает железке стать еще более тупой, и работать исключительно как исполнительное устройство под контролем 1с? Пришло с порта событие "предъявлен ID такой-то", 1с проверила в базе права, и дала команду на другой порт "открыть замок".

Действительно. А потом завис сервер 1С/нет сети/отвалился ключ и т.д и никому не войти и не выйти :))

Для этого есть дяденька вахтер с журналом и кнопкой)

Тогда 1С и карты вообще не нужны, раз на каждую дверь есть свой вахтёр с кнопкой. Обычно этим занимается система СКУД, а у контроллеров есть своя память на случай обрывов сети. Зачем изобретать бредовые глючные механизмы?

Да и контроллеры глючат бывает.. У нас стоят два турникета Perco, так виснут регулярно. Реже, чем 1с.)

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

Да. Покрывает полностью. Отвечает настолько хорошо, что приходится писать различные отчеты и доп. формы по "слежке" за сотрудниками.

+ По этим же пропускам (картам) сотрудники ходят в столовую (используются для идентификации: кто и насколько поел).

"наличие тупой системы "считыватель-замок" с открытым интерфейсом" - так вроде это зависит от тебя, как ты будешь использовать систему. Не вижу никакой проблемы в том, чтобы считать код карты, и программно замкнуть/разомкнуть нужный контакт в замке. Просто обычно этим занимается именно специализированное ПО. 1С можно использовать только там, где не критично время отклика: например, как в . А когда у тебя идет поток (в случае ТС - это вообще какой-то бардак см. ) - то время отклика системы критично.

+ Еще добавлю. Да, все правильно написано в . Непосредственно 1С с контроллерами СКД не связана. Есть специальные платы контроллеров и комп на котором размещена база сотрудников и их допуски ко входам/выходам. Данные в 1С (ЗУП) считываются по запросу (можно сделать и по регламенту).

Ну не знаю.. мне как-то не нравится, когда в мозгах турникета хранится полная база ключей (включая аннулированные). Невольно возникает вопрос - что будет, когда она переполнится?

В том-то и дело, что там хранятся только актуальные ключи для данного турникета. При изменении прав с сервера СКУД в нужные контроллеры летят записи по нужным ключам, а старые соответственно удаляются. А контроллер работает автономно.

+100

у нас болидовские, 32000 ключей, чему там переполняться?

И в чём проблема ? Покупаешь один или два считывателя с USB или RS-232, чтобы подключить к компьютеру, на котором стоит 1С. Отдельно покупается самый дешёвый турникет с двумя кнопками - проход туда и обратно. Далее, на COM-порт (или USB) покупается контроллер с реле (нужно два контроллера или один с двумя независимыми парами контактов). Далее, пишем обработку в 1С, которая читает события от двух "сканеров", так как проксимити считыватель очень на них похож. А после проверки кода по базе (справочнику или регистру) выдаёт команду на реле или проигрывает звук в динамике. По-мойму, задача для школьника - программирование+пайка.

в и я уже писал вообще то, но нет реакции ))

У Турникета Ростов-Дон и контроллера к нему, например, есть режим, когда он управляется по команде с компьютера, а считанные коды передаются на компьютер прозрачно, не влияя на открытие. Причём, клиент (турникет) цепляется по Ethernet 10-мегабит. Вполне себе терпимо.