Отправка сигнала из веб-приложения на LPT-порт
Мне нужно, чтобы веб-приложение отправляло сигнал на LPT-порт. Аппаратное обеспечение предназначено для прослушивания сигнала 0 В или 5 В TTL.
Знаете ли вы какой-нибудь activeX, класс PHP, JS или даже какое-нибудь промежуточное программное обеспечение или что-нибудь, что могло бы позволить мне "подключить" эту функцию LPT к приложению PHP/JS, используемому локально в среде Windows?
2 ответа
Я никогда не работал с этой функцией, но у php есть 1, который вы можете использовать http://nl1.php.net/Exec
изменить это пример, который я нашел в интернете
<?php
$cmd = "start /D C:\OpenSA\Apache /B Apache.exe -D SSL";
exec($cmd,$output,$rv);
?>
У нас есть система продажи билетов на основе браузера (как в билетах boxoffice для кинотеатров), которая использует последовательный порт для отправки команд непосредственно на принтер билетов. Вот как это работает:
- крошечное приложение, по историческим причинам вызывается "агент" и читает файл конфигурации
- этот файл конфигурации содержит только идентификатор рабочей станции и путь к предпочитаемому исполняемому файлу браузера
- Агент запрашивает имя пользователя и пароль и аутентифицируется на сервере по обычному HTTP (соленые хэши, ничего секретного не происходит по сети), отправляя также идентификатор рабочей станции из файла конфигурации
- Если аутентификация предоставлена, сервер отправляет конфигурацию (например, "port=com1", "baud=19200", ...), идентификатор сеанса и одноразовый URL
- Агент запускает браузер, указывая его на этот одноразовый URL
- Затем агент переходит в длинный цикл опроса по HTTP, передавая таким образом команды с сервера на последовательный порт, используя настройки, которые он получил ранее (и ретранслируя любые входные данные с принтера, такие как "нет бумаги")
По сути, это означает, что один и тот же сеанс используется двумя клиентами одновременно: браузер и агент - очень простой способ обмена информацией. Фактически это означает, что ретранслируемый последовательный порт и браузер совместно используют сеанс.
Я уверен, что это может быть легко адаптировано для вашего использования.
По историческим причинам агент написан на TCL/TK, поскольку в то время это был самый простой способ получить кроссплатформенную обработку HTTP и последовательного порта в Windows (семейства 9x, NT и CE), OSX и Linux. Его также легче всего упаковать в самодостаточный.exe (или соответствующий.app, исполняемый файл ELF,...)
Сегодня я бы использовал C# для агента, так как Mono сейчас более чем хорош, чтобы предоставить вам Mac, Linux, Android и iOS