Re: WBA вместо EBA

Кто может помочь с подключением купюрника WBA вместо EBA. Дело в том, что игровая плата
разработана только под EBA. EBA имеет RXD TXD а купюрник WBA - RXD, TXD, M.Reset, Led+, Led-.
Если подключить в WBA только RXD TXD, то после загрузки платы купюрник принимает купюру но кредитов не дает. Требуется отдельно перезагрузка купюрника.

Какая игрушка?

После второй перезагрузки кредит начисляет?Поподобней....

Если у вас стандартный разъем от WBA с проводами ТО :

1 Красный провод соединяете с желтым это 12 вольт.

2 Коричневый ресет, можно не использавать, попробуйте одать не него ноль.

4 Черный соедините с синим, это земля

7 оранжевый - это RX

8 Зеленый TX

Используется только одна из 3 групп контактов с 1 по 7 , кроме 8 провода.

http://porcha2.nm.ru/WBA.JPG

M.Res - не нужен.

зы обрати внимание, что там два питания: одно идет на билл, второе на интерфейс связи. Он как никак оптический.

Если быть точнее, то игра " Авиатор " прибалтийской фирмы DLV а купюрник не WBA а ICT-J830.
Просто с J-830 наверное мало кто знаком, а на Геминаторах мы используем ICT-J830 который подключен к разему WBA.

Ничего себе не точности :o :o

Теоретически пофиг. Главное чтоб купюрник работал именно в том протоколе, который нужен для платы (или настраивается на плате).

Сдается мне, вопрос надо адресовать фирме ICT, что у них с реализацией протокола (а потом - прибалтийской фирме DLV, что они там намудрили :) )
Купюрник берет деньги = поллинг идет. Поллинг идет - информация о номере принятой купюры у платы есть (раз она дает команду купюрнику принять распознанную купюру). Похоже, что по-какой-то причине плате сразу не удается считать из билла таблицу валют... А после ресета билла - удается. Кто виноват - а фик его знает )))))
Но сдается мне, с WBA бы проблемы не было ))))

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

http://porcha2.nm.ru/WBA.JPG

M.Res - не нужен.

зы обрати внимание, что там два питания: одно идет на билл, второе на интерфейс связи. Он как никак оптический.

Это учтено??!
Пока это не учтешь и не реализуешь, дальнейший разговор безсмыссленнен.

porcha2 писал(а):
http://porcha2.nm.ru/WBA.JPG

M.Res - не нужен.

зы обрати внимание, что там два питания: одно идет на билл, второе на интерфейс связи. Он как никак оптический.

Это учтено??!
Пока это не учтешь и не реализуешь, дальнейший разговор безсмыссленнен.

если бы у него на интерфейсе не было питания, у него бы вообще ничего не брал билл. И если я правильно понял автора, у него не WBA, а айситишка j-830 (и надо было бы тему делать в ICT, а не тут).

В настройках этого прибалтийского чуда по купюрнику никаких пунктов нет? Если нет - то увы... Тут ничем не помогут. Кроме советов ставить тот билл, на который рассчитана плата, перевести билл в пульс или сгородить реле времени, передергивающее питание после включения...:)

Могу сказать что с реле времени уже работает, правда это не лутший вариант.

...подозрительно быстро, однако. ??? И что делает это рэле времени??
Вообще я понял, что вместо 830-го нужно поставить WBA. Это так или всетаки у меня глюк?

Если быть точнее, то игра ...... а купюрник не WBA а ICT-J830.

Поставили реле времени, собраное из подручных материалов (561 ЛА7 , кт3102, конденсатор, резисторы , реле 12 В). Реле времени размыкает землю в момент включения апарата и включает ее через несколько десятков секунд после загрузки платы. Теперь при введении купюры нормально начисляются кредиты. Пока работает. Тестируем дальше.

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

зы Кстати, а на плате случаем нет сигнала, который можно зацепить на m.res ? ведь это именно перезапуск билла.

А я больше грешу на сам купюрник (точнее, реализацию "не своего" протокола в ICT) - с JCM-кой то плата работает (сам видел :))...
С купюрника само по себе ничего не идет - только в ответ на запросы платы. А чем работа после перезапуска купюрника отличается от работы сначала? Подозреваю, что командой RESET, которую плата скорее всего передает сначала (положено так, ага - проинициализировать билл в начале работы). А потом уже плата купюрнику RESET не шлет. Если так - то вывод, что после "аппаратного" сброса J-830 работает корректно, а после программного (кеомандой по протоколу) что-то не то... Хотя... такой косяк привел бы к неработе протокола на этом билле почти везде... ???

Исходя из вышеизложеного - а нет ли более свежих прошивок на J-830, чем та, что в нем?

AR_Favorit писал(а): Подозреваю, что командой RESET, которую плата скорее всего передает сначала (положено так, ага - проинициализировать билл в начале работы). А потом уже плата купюрнику RESET не шлет.

Вполне... но вот только ответ читает уже потом... когда загрузится, но к тому времени ответ уже давно отправлен (пока плата грузилась).

зы В любом случае впечатление о не корректности реализации протокола со стороны платы только увеличилось.

porcha2 писал(а):
AR_Favorit писал(а): Подозреваю, что командой RESET, которую плата скорее всего передает сначала (положено так, ага - проинициализировать билл в начале работы). А потом уже плата купюрнику RESET не шлет.
Вполне... но вот только ответ читает уже потом... когда загрузится, но к тому времени ответ уже давно отправлен (пока плата грузилась).

зы В любом случае впечатление о не корректности реализации протокола со стороны платы только увеличилось.

не, ресет игра биллу шлет уже загрузившись, это я и имел в виду "сначала"... До того некому ресет слать))))

Но соглашусь, что в игрухе похоже тоже что-то не то или не так, ибо с таким диким и очевидным косяком (фактическое неработой в протоколе, так как все начинают работать с ресета) протокольную прошивку навряд ли бы выпустили... Значит какие-тотонкости в работе платы с биллом по протоколу таки присутствуют... Может недокументированная команда какая проскакивает, или еще что там...

Как вариант еще - там же линукс... Возможно, не сама игра косячит, а их сборка линуха в процессе загрузки или старта игры какой-нить мусор засылает в ком-порт, и этот мусор так вот раскорячивает айситишку (а jcm на него не реагирует)... Опять же - некорректность работы протокола у айсити налицо, но и игра "хороша"...

В общем, при желании очень большом можно подцепиться к интерфейсу компом через простую схемку и отмониторить обмен, проанализировать, стало бы понятно, откуда косяк... Но вот толку-то ноль, исправить ни прошивку игры ни прошивку билла один фик самостоятельно не выйдет (только если сгородить адаптер на меге с двумя уартами, "на лету" исправляющий обмен - красиво, но дебилизм по сути), а делать эту работу за прибалтийскую фирму DLV или тайваньскую фирму ICT - нафик надо вообще...)))

Топикстартеру же посоветую посмотреть свежие прошивки на купюрник, и если их нет - забить: работает и фик с ним))).

Вообще-то, анализ производится поиском "заголовка", потом длины пакета
Затем ловится весь пакет, на прием каждого байта которого отводится определенное время.
Если все байты словлены в корректное время, проверяется CRC.

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

Просто в case на событие POWERUP даем команду RESET - и все зер гуд... Проверено :)

Я тож об этом. ....
Мож плата этого и не дает.
А вот почему одни работают в ид003 а другие нет с этой платой? Протокол-то тотже! Стандарты протокола никто не отменял.
Мож некоторые биллы и не критичны к таким коммандам в отличии от других... Мож для некоторых ресет не важен? мож они сами себе делают ресет в начале приема купюры?? или при подаче питания?? х их знает....

Я так думаю: если игра с JCM в id003 работает, а с ICT в id003 косячит - то как бы ни крива была игра, ЧЕМ-ТО ict-шная реализация протокола id003 от jcm-овской отличается, причем явно в худшую сторону))). Обработкой нештатных ситуаций, реагированием на "неправильные" команды с хоста, фик его знает. Отличается - факт. Это косяк ICT. Их руки явно кривы уже)))
Другое дело, что DLVшники явно тоже где-то отступили тож от требований протокола - может по паверапу шлют ресет, а просто при старте игры забыли))). Но такой реакции от билла (то ли забывать слать венд валид, то ли при запросе таблицы слать фигню с нулями, что потом в игре выливается в "неначисление" кредита))) быть все равно не должно...

porcha2 писал(а): Я тож об этом. ....
Мож плата этого и не дает.
А вот почему Ай сити работают в ид003 а другие нет с этой платой? Протокол-то тотже! Стандарты протокола никто не отменял.
Мож айсити и не критичны к таким коммандам в отличии от других... Мож для айсити ресет не важен? мож они сами себе делают ресет в начале приема купюры?? или при подаче питания?? х их знает....

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

Хотя я по-моему все-таки здорово что-то путаю, и после включения купюрник будет находиться в состоянии павер-ап до тех пор, пока не получит эту злосчастную команду ресет... Вроде так... Завтра гляну в описании протокола))) И тогда получается, что плата ресет таки шлет как положено (иначе бы не было приема купюр вообще), а причина глюка тогда уже вообще не связана с платой, а чисто в купюрнике (если после включения он получает ресет сразу - то работает нормально, а если только через несколько минут - линух долго грузится на этом DLV - то косячит)...

Есть еще вариант, что не айситишники такие криворукие, а конкретно этот билл такой кривой оказался, перешить его надо бы для проверки...

AR_Favorit писал(а): Я так думаю: если игра с JCM в id003 работает, а с ICT в id003 косячит - то как бы ни крива была игра, ЧЕМ-ТО ict-шная реализация протокола id003 от jcm-овской отличается, причем явно в худшую сторону))). Обработкой нештатных ситуаций, реагированием на "неправильные" команды с хоста, фик его знает. Отличается - факт. Это косяк ICT. Их руки явно кривы уже)))

Не фак (как грится :) ) мож ето производители игры используют какие-нить не документированные комманды. Ну... типа я ДОСовской коммандой захочу закрыть все работающие приложения винды... Это можно, но это нигде не прописано... и при этом некоторые закроются а некоторые начнут ругаться . Все зависит от версии винды. В некоторых версиях все приложения послушны :) Мож это из этой серии??