Хост печать что это
Настройка с нуля принтсервера CUPS с доменной авторизацией и без нее в сети с разными ОС
Настройка с нуля принтсервера CUPS с доменной авторизацией и без нее в сети с разными ОС
Вступление
Итак. Предположительно, сервис печати CUPS — это мощное решение, позволяющее организовать централизованное управление принтерами в компании. Так оно и есть, но в процессе настройки потребуется провести некоторое время в поисках решения в Google множества мелких неочевидных проблем, особенно, если ваша необходимость выходит за рамки стандартных мануалов по настройке.
В статье будет описана установка принтсервера CUPS на Ubuntu Server в сети с работающим доменом Active Directory, хотя его наличие совершенно не обязательно и инструкции по настройке взаимодействию с ним можно будет смело пропустить, его настройка, а также настройка клиентских машин Linux и Windows для взаимодействия с данным принт-сервером.
В инструкции домен будет именоваться example.com, сам принтсервер — cupsserver (cupsserver.example.com) с IP адресом 10.10.100.50, а клиентские машины linux1, linux2, linux3 и т.д для клиентских машин Linux и windows1, windows2, windows3 и т.д. для клиентских машин Windows соответственно.
Настройка принтсервера
В первую очередь мы настроим принтсервер, а точнее, настроим административный доступ на него, затем настроим печать на него, а затем опишем настройку клиентских машин.
Заходим на принтсервер любым удобным способом и обновим на нем пакеты:
Далее проверим, установлен ли CUPS на сервере:
Если вывод выглядит как то так:
то CUPS установлен, если вывода нет — устанавливаем CUPS:
Теперь настроим административный доступ к веб-интерфейсу CUPS. Все файлы конфигурации находятся по пути /etc/cups/. Для начала, на всякий случай сделаем резервные копии основных файлов конфигурации CUPS:
Впрочем, если вы этого не сделали — не беда, образцы данных файлов по умолчанию лежат по пути /usr/share/cups. Также нужно упомянуть, что вы можете проверить любые добавленные опции в файлы конфигурации CUPS с помощью команды:
Если вы что-то напутали, опечатались или использовали опцию, которая уже не поддерживается CUPS’ом, то вывод команды отразит данные ошибки.
Но приступим наконец к настройке. После любых изменений файлов в папке /etc/cups/ для получения эффекта необходимо перезапускать сервис CUPS:
А если вы отредактировали файл /etc/cups/cups-browsed.conf, то за него отвечает отдельный сервис cups-browsed, который тоже нужно перезапустить:
Первой незакомментированной опцией является
Она определяет минимальную информативность логов CUPS. Лог-файлы CUPS находятся по пути /var/log/cups/. На время установки, настройки и отладки принтсервера будет разумным перевести логгирование в debug-режим. Для этого изменим warn на debug2:
По умолчанию CUPS слушает входящие подключения только от localhost, то бишь на loopback интерфейсе. Чтобы убедится в этом, можете выполнить команду
Одна из строк будет выглядеть приблизительно так:
Дальнейшие действия зависят от степени вашей паранойи. Вы можете добавить в блоке, который условно начинается с комментария #Only listen for connections from the local machine несколько строк с указанием IP адресов или подсетей, откуда CUPS’у будет позволено слушать подключения.
Либо же вы можете разрешить CUPS’у слушать подключения со всех адресов
Следующий момент настройки — это обнаружение сетевых и расшаренных принтеров.
На мой взгляд эта опция так и должна остаться выключенной, так как она определяет, будет ли рассылаться широковещательная информация по сети о подключенных к принтсерверу принтерах. А они ведь будут подключены к ней все. И соответственно у всех клиентских машин будут отображаться сразу все принтера. Наш принтсервер должен искать и обнаруживать все принтера в сети, но не рассылать их бездумно по всей сети.
Далее идут настройки аутентификации:
Определяет права доступа к веб-интерфейсу CUPS, а также к его административной части. Чтобы пользователь user имел право на администрирование CUPS, его нужно добавить в системную группу lpadmin:
Вообще, группы, которым позволен административный доступ к CUPS, определяются в файле конфигурации cups-files.conf в блоке
Если вы хотите добавить некой группе пользователей Linux права на администрирование принтсервера, например printadmins, то просто добавьте их через пробел к lpadmin. Если группа доменная, то это немного сложнее и будет описано позже.
Теперь перейдем к блоку :
Order allow,deny означает, что запрещены подключения отовсюду, если специально не указано разрешение. То есть нужно добавлять IP-адреса, подсети, хосты или хосты по маске (.example.com) в виде «Allow from [разрешенный адрес]*»:
Для полной уверености и отладки, можно оставить, пока не настроите все остальное, такую констукцию, которая позволит печать отовсюду:
Приступим к настройке административного доступа к CUPS на принтсервере. Определитесь, с какого/каких IP и/или подсетей вы собираетесь подключаться к CUPS, и добавить их по аналогии с блоком :
Еще, по желанию, можно добавить язык интерфейса по умолчанию. Список доступных языков можно посмотреть с помощью команды:
Если нужная вам локализация, например ru, есть, то добавьте строчку в /etc/cups/cupsd.conf:
Чтобы к вашему принтсерверу cupsserver.example.com можно было обращатся по его хосту (hostname), необходимо создать в папке /etc/cups/ файл client.conf с таким содержимым:
Самым простым способом это можно сделать так:
Поскольку мы предполагаем, что в сети есть DNS сервер, то будет предпочтительным, чтобы можно было обращатся к принтсерверу по его доменному имени (cupsserver.example.com). Также серверу может быть присвоен CNAME псевдоним на DNS сервере, например print или cups. Чтобы принтсервер принимал подключения по таким обращениям, необходимо добавить такую строчку в файл /etc/cups/cupsd.conf:
Если вы хотите, чтобы принтсервер примимал любые обращения, или не хотите заморачиваться, то можно добавить это:
Еще нужно взглянуть внутрь файла /etc/cups/cups-browsed.conf. Этот файл управляет тем, как принтсервер будет искать принтеры в сети и проводить широковещательную рассылку своих принтеров. Я предлагаю совершенно отключить опцию рассылки. Принтсервер будет искать принтера в сети, но с него принтеры на клиентские машины будут подключатся вручную. Ниже будет описано, почему. Пока же мы находим строку BrowseRemoteProtocols dnssd cups:
Благодаря этой опции принтсервер ищет расшаренные принтера в сети. Ее мы оставляем включенной, так как в наших интересах, чтобы принтсервер искал принтера в сети. Но нам совершенно не нужно, чтобы принтсервер рассылал вообще все подключенные к нему принтеры, иначе возникнет большая путаница. Для предотвращения такого сценария находим следующую опцию #BrowseLocalProtocols none и раскомментируем ее:
На этом настройку принтсервера приостанавливаем и переходим к настройке клиентких машин Windows и Linux. Требования к ним такие — позволять посылать на себя задания печати принтсерверу, и посылать задания на печать именно (и только) на принтсервер в случае необходимости печати на сетевой принтер.
Теперь выполним аналогичную операцию на клиентской машине Linux c именем хоста linux1. Вообще, данная часть будет куда объемнее, так как у клиентской машины есть свой сервис CUPS и его тоже нужно настроить во многом так же, как и принтсервер, за исключением его подчиненной роли в организации печати.
Исправление ошибки обращения к CUPS через loopback по имени хоста
Есть неприятный момент. Если вы введете linux1 в домен, настроите на нем CUPS по этим инструкциям, то можете заметить абсурдную ситуацию, когда на WEB-интерфейс linux1 можно зайти снаружи, но на самом хосте этого сделать нельзя! И графические приложения для локальной настройки принтеров, вроде приложения system-config-printer в Linux Mint, отказываются работать. При попытке подключения на свой же CUPS по по адресу http://linux1:631/ будет сообщение «Запрещено» или «Bad Request». Это известная и толком не решенная на множестве форумов интернета проблема.
В большинстве инструкций по введению Linux в домен одним из пунктов является приведение файла /etc/hosts приблизительно к такому виду:
Почему то CUPS не в силах ассоциировать обращение через 127.0.1.1, то есть через Loopback интерфейс, с именем хоста.
Исправляется эта ошибка двумя способами. Если в вашей сети IP адреса статичные, то в файле /etc/hosts исправьте 127.0.1.1 на IP адрес внешнего сетевого интерфейса клиентской машины, например:
Либо же, раз уж вы вводите Linux в домен, то это предполагает, что в вашей сети работает DHCP и DNS сервер Active Directory. В таком случае просто закомментируйте данную строчку:
Разницы в работоспособности или проблем от данного действия пока обнаружено не было.
Настройка адресов прослушивания подключений к CUPS у клиентских машин Linux
Заходим на linux1 любым удобным способом. Редактируем файл /etc/cups/cupsd.conf:
Находим, добавляем или изменяем в нем строки:
Настройка адресов прослушивания подключений к CUPS
Настройка раздачи и получения широковещательной рассылки сетевых принтеров
Еще у клиетской машины Linux, в данном случае linux1, необходимо отредактировать файл /etc/cups/cups-browsed.conf:
Настройка административного доступа
Еще пару слов по поводу административного доступа, как на WEB-интерфейс CUPS на принтсервере, так и на любой клиентской машине Linux. Даже при условии наличия 30-50 компьютеров нужно унифицировать авторизацию на CUPS, а не держать в голове или еще где пароли каждой машины. И это важно на всех Linux машинах, ведь чтобы добавить принтер на сервер, его сперва нужно установить локально. Я вижу несколько путей.
Первый — на каждой системе Linux создать пользователя printeradmin (например) и добавить в группу lpadmin:
и авторизовываться на http://имя_хоста:631/admin c помощью его учетных данных.
Второй вариант практически идентичен и предлагает создать группу в системе, например, printersadmins, добавить туда требуемого администратора CUPS (printeradmin, user):
Затем нужно найти в файле /etc/cups/cups-files.conf строку
и добавить через пробел одну или несколько групп пользователей с правом администрировать CUPS.
И наконец, третий вариант. Сделать администраторами принтсервера и CUPS’ов клиентских машин доменную группу пользователей. Для этого принтсервер и клиентские машины Linux должны быть присоединены к домену AD. Есть несколько методов подключения Linux к домену Windows, но, насколько я знаю, основные это подключение с помощью winbind и с помощью SSSD(realmd). Описание данных методов не входит в статью, поэтому остановлюсь только на моментах которые касаются конкретно CUPS’а.
Настройка использования доменных групп пользователей для администрирования CUPS
Каждый метод присоединения к системе централизованной авторизации в Linux создает специальный файл-«трубу» (pipe), сквозь который приложения могут посмотреть список пользователей домена. Чтобы так мог сделать CUPS, нужно разрешить ему использовать pipe в AppArmor’е для аутентификации пользователей. AppArmor — модуль безопасности Linux по управлению доступом. Ограничивает определенные программы набором перечисленных в его политиках файлов. Чтобы добавить CUPS’у право использовать пользователей и группы домена через winbindd, нужно добавить в файл /etc/apparmod.d/local/usr.sbin.cupsd такую строку:
Если Linux введен в домен через SSSD, то необходимо указать расположение его pipe в /etc/apparmod.d/local/usr.sbin.cupsd, добавив туда строку:
К тому же, в случае с SSSD это позволяет пройти аутентификацию (узнать кто заходит), но чтобы пройти авторизацию (узнать есть ли право у пользователя управлять CUPS) необходимо также добавить в файл конфигурации SSSD /etc/sssd/sssd.conf строку:
Это, условно выражаюсь, дает CUPS’у право «заглядывать» в SSSD.
К тому же, в силу того, что CUPS теперь зависит от сервиса SSSD, нужно указать CUPS’у что он должен запускаться после SSSD, иначе он будет отваливаться при включении и его будет необходимо каждый раз включать вручную.
Добавим CUPS’у указание грузиться после SSSD. Отредактируем файл сервиса cups.service по пути /lib/systemd/system/, добавив инструкцию After в секцию [Unit]:
Таким образом CUPS настроен на Basic авторизацию через домен, то есть авторизацию с помощью ввода логина и пароля доменного пользователя с правом администрирования CUPS.
Авторизация может быть настроена и иначе, но принцип (pipe-файл) в целом универсален и есть шанс настроить и для LDAP, FreeIPA и прочих служб каталогов по аналогии.
Установка принтера в Linux
Теперь, когда сервер и клиенские машины Linux настроены, к некоторым из них присоединены принтеры, а также есть машины на Windows, которым и с которых нужно печатать, и вся эта система должна быть стабильной и в случае, если на одном из ПК необходимо заменить принтер, то это не должно повлечь за собой перенастройку доброй половины всех ПК, если не всех. К тому же нужно как можно меньше проблем с драйверами. И это вполне возможно.
Группы принтеров (Classes)
Главная прелесть данного метода в том, что если на любом из ПК заменяется принтер, заменяется сам компьютер, или то и другое сразу, то это никак не влияет на тех, кто был к ним подключен через группу на принтсервере. Единственная настройка производится на принтсервере — к принтсерверу подключается новый принтер, затем из группы, в которой состоял старый принтер, он удаляется, и добавляется новый принтер на замену старому. И никаких дополнительных настроек на любом количестве ПК, только на принтсервере и собственно ПК на котором меняли принтер. Драйвера «IPP Everywhere» и «MS Publisher Imagesetter» содержат большое количество настроек бумаги, печати и т.д., так что нет проблем настроить нужный вид печати через них.
Заключение
Тема слишком обширна, чтобы изложить сколько-нибудь подробно, и даже так статья вышла крайне объемной. Любые уточнения, указания на ошибки, нераскрытые вопросы и советы, данные в комментариях к данной статье, будут приняты во внимание и в случае необходимости включены в статью.
Зачем нужен принт-сервер и как он работает
Принт-сервер – это устройство или программное обеспечение для совместного доступа к принтеру в проводных и беспроводных сетях. Сервером печати может выступать и компьютер, к которому подключены принтеры с общим доступом. Разберемся, зачем нужен принт-сервер и как он работает.
Принт-сервер, реализованный в виде отдельного устройства, представляет собой небольшую коробочку с интерфейсами подключения принтера и сети (Ethernet, Wi-Fi). Современные модели обычно оснащаются портом USB. Морально устаревшие параллельные и последовательные порты (COM, LPT) уже практически не используются.
Такой аппарат позволяет избежать использования ПК при настройке сетевой печати: коробочка подсоединяется к принтеру, например, через USB-порт, затем подключается к локальной сети. Всё, у вас есть удаленный доступ к принтеру с любого компьютера этой сети.
Серверы печати могут поддерживать подключение не только принтеров и МФУ, но и других USB-устройств (картридеров, внешних жестких дисков, сканеров, флеш-накопителей, колонок и так далее). Причем эти устройства будут доступны с любого компьютера домашней или офисной сети.
Принт-серверы крупных производителей печатающих устройств обычно лучше всего работают с принтерами и МФУ того же бренда. Есть и более универсальные модели, поддерживающие сотни разных моделей печатающих устройств
Преимущества аппаратных принт-серверов:
В некоторых роутерах уже прошита функция принт-сервера — это удобно. Параметры сетевого принтера выставляются в разделе «Сервер печати», «Настройки принт-сервера» или «USB-устройства» веб-интерфейса маршрутизатора (в разных моделях названия разделов могут отличаться).
Аппаратные принт-серверы чаще всего ставят в офисах, в которых используют несколько принтеров и распечатывают большое количество документов. Оборудование подключается к сети напрямую и не зависит от локальных компьютеров, которые могут находиться на разных этажах и даже в разных зданиях. В домашних условиях можно использовать и специализированное ПО.
Приручаем динозавров, или как я писал свой собственный host controller для лаборатории 3D-печати
В этой статье я хочу рассказать о своем опыте разработки свободного ПО для управления 3D принтерами на Qt5, проблемах и особенностях общения с RepRap’ами и прочим радостям.
Результатом этого опыта стал RepRaptor — минималистичный свободный host-controller для 3D принтеров.
Всех интересующихся приглашаю под кат.
Немного предыстории
За последний год я сильно заинтересовался 3D печатью, и не просто 3D печатью, а ее свободной составляющей — проектом RepRap. Руководство ВУЗа поддержало начинания, и в течении этого года моими и единомышленников усилиями в МГТУ МИРЭА открылась лаборатория 3D печати.
Очень скоро возникла проблема — существующее в экосистеме ПО имело недостатки, которые сильно мешали работе. Поэтому было решено эти проблемы ликвидировать, создав свое ПО.
Почему Qt?
Как это все исправить? Довольно просто — написать хост на языке, который будет работать быстрее, и сделать его максимально простым. Сказано — сделано. Для разработки был выбран Qt, и не случайно. Этот замечательный фреймворк не только распространяется свободно, но и позволяет писать кроссплатформеные приложения без сопровождающей мультиплатформу в C++ боли, а так же не так давно периодически используемый мной QSerialPort стал официальной частью фреймворка.
Кроме того, я не знаю ни одной IDE, такой же быстрой и удобной для меня, как QtCreator.
С чего начать, или как разговаривают принтеры
Общаться необходимо работать с целым зоопарком разнообразных плат (Melzi, RAMPS 1.4, Teensylu, Gen7 1.5.1 и т.д.), благо сообщество проекта RepRap уже давно определилось с протоколом и списком команд. Для общения с любой платой используется серийный порт и протокол G-code.
В своей лаборатории 3D печати мы с товарищами используем прошивку Repetier, которая, на ряду с прошивками Marlin и Teacup поддерживает большинство стандартных кодов.
Первое разочарование — протокол
Спецификация серийных портов RS-232 обширна и интересна, но, к сожалению редко где используется на полную. При эмуляции серийного порта по USB, очень часто к микроконтроллеру подключаются только линии TX и RX, отвечающие за передачу данных. Линии, такие как DTR (сброс при подключении), обычно не используются, и это печально.
Выглядит это примерно так:
wait
G1 X10 Y10 Z10
ok 0
G1 X20 Y5 Z3
ok 0
N1 G1 X10 Y10 Z10 *cs
ok 1
N2 G1 X20 Y5 Z3 *cs
ok 2
Где cs — вычисленная контрольная для строки.
Как правило кодогенераторы, преобразующие 3D модели в G-Code для печати контрольных сумм не генерируют, а оставляют это на усмотрение хоста.
У принтера есть буффер, размер которого в большинстве случаев составляет 16 команд.
Реализация протокола
Qt имеет отличную функцию для облегчения жизни разработчику — сигналы и слоты.
Сигнал — это новое для C++ понятие. Сигнал объявляется в классе подобно слоту:
Сигнал не может ничего вернуть, поэтому всегда имеет тип void, а вместо аргумента указывается тип передаваемой сигналом переменной. Инициализировать его не требуется.
Вызывается сигнал из любого метода родительского класса, и очень просто:
После такого вызова все слоты, присоединённые к этому сигналу будут вызваны при первой возможности в порядке присоединения, и им передастся значение 100.
Что такое слот? Коротко — это самый обычный метод, объявленный слотом
Соединяются сигнал со слотом тоже очень просто:
Есть и ограничение — у сигнала и слота обязательно должен совпадать передаваемый тип.
Учитывая сигналы и слоты можно очень легко написать асинхронный приемник\передатчик для связи по серийному порту.
Самая простая часть — чтение.
Для реализации связи по серийному порту используется упомянутый выше QSerialPort (экземпляр которого назовем «printer»), имеющий сигнал readyRead(), вызывающийся каждый раз, когда на порт приходит информация. Все что от нас требуется — это создать в своем классе слот, который мы и будем вызывать при появлении этого сигнала, соединить их, и ждать. Что же мы будем читать? Как уже описано выше, в первую очередь нас интересуют ответы ok и wait. Так как наш код исполняется асинхронно, а у принтера есть буфер — нам надо где-то сохранить колличество строчек ок, которые мы приняли, чтобы при отправлении знать, сколько мы можем отправить. Хранить их будет в переменной «readyRecieve».
Отлично, с приемом разобрались. А что у нас с отправкой? Вот тут и видим дефект протокола. Никакой аппаратной команды для обозначения готовности к приему данных у нас нет, а значит нету и соответствующего сигнала у нашего QSerialPort. Значит отправлять будем по таймеру. Таймер в Qt работает до безобразия просто и удобно — мы создаем экземпляр класса QTimer, соединяем его сигнал timeout() с нашим слотом, который будет выполнятся по этому таймеру, а после этого запускаем его — timer.start(ms). В последствии было выяснено, что в зависимости от производительности ПК оптимальный промежуток находится от 1 до 5 мс. Кстати, если указать таймеру промежуток 0, то выполнятся он будет как только у Qt появится свободная минутка.
Еще стоит упомянуть, что отправляем мы либо команду от пользователя, либо файл. Так как разбор файла сводится к заурядной загрузки файла в массив, а так же фильтровании линий целиком из комментариев (чтобы не отправлять лишнее на принтер и не захламлять память), я решил опустить эту часть. Массив строк из файла называется gcode.
Ну вот, с серийным портом разобрались? Еще нет. Еще нам надо отловить ошибки. Для этого вновь прибегнем к сигналам и слотам, на этот раз будем слушать сигнал error(SerialPort::SerialPortError error) от нашего экземпляра QSerialPort:
Неаккуратное обращение с принтером расстраивает динозаврика, %username%.
Делаем наш хост умнее
Выносим кнопки команд
Мы научились отправлять файл в серийный порт и правильно держать протокол, но для полноценного хоста этого мало. Помимо возможности отправлять файл построчно, необходимо еще дать пользователю возможность отправлять команды самому. Как вбитые руками, так и выведенные на кнопки в интерфейсе.
Какие команды стоит вывести? Мнения авторов разных, уже имеющихся программ расходятся, но я постарался вывести максимум:
Иконок пока нет, но они обязательно появятся в последующих релизах. Реализация большинства этих кнопок весьма простая:
Метод injectCommand, способ работы которого мы уже узнали ранее, в реализации отправщика кода тоже весьма прост:
Получаем дополнительные данные
RepRap — это суровый DIY. Настолько суровый, что случается всякое:
Далеко не всегда во время настройки можно быть уверенным, что принтер поведет себя так, как надо. Одним из очень важных значений является температура, и следить за ней жизненно необходимо. У некоторых людей на принтере есть дисплеи, отображающие оперативную информацию, но далеко не у всех. К тому же, можно физически находится от принтера далеко, или под неверным углом, и читать дисплей уже не выйдет. Именно поэтому требуется отображать температуру, и чем оперативнее — тем лучше.
Под температуру определим отдельную группу элементов
Как же ее узнать? Во время нагрева, принтер перестает принимать команды, и вместо ok или wait начинает присылать температуру. Строка температуры выглядит так:
Читаемо для человека, но не очень удобно для разбора. В первых версиях я разбирал эту строку прямо в слоте, отвечающем за прием информации, но тесты показали, что разбор строки прямо в этом слоте слишком сильно замедляет работу программы. До последнего я пытался избежать работы с потоками, так как одна из главных причин, по которой RepRaptor был написан — быстродействие. Многопоточность отлично ускоряет работу софта на многоядерных системах, но у нас с железом было все не так радужно. Однако выбора не осталось — надо было перенести в отдельный поток либо разбор, либо само соединение. Было решено пойти на компромисс — перенести разбор в отдельный поток, и позволить пользователю отключить проверку температуры.
Как реализована многопоточность в Qt? Очень удобно. Есть несколько способов создать отдельный поток. Полноценный способ — создать поток с помощью QThread, но нам не нужен полноценный поток для простого разбора строки, так что будем использовать другой способ — передадим нашу функцию разбора вместе с аргументам объекту QFuture, и будем за ним следить. Делается это так — для начала нам необходимо создать экземпляр QFutureWatcher, класса, который следит за QFuture, и сообщает нам о его состоянии. Затем надо написать нашу функцию разбора. Так как функция может вернуть только одну переменную, я решил создать специальный тип для передачи температуры:
Теперь осталось только отдать эту функцию потоку при удобном случае (вставляем дополнительную проверку в автомат функции приема):
Осталось только создать слот, чтобы подключить к нему сигнал, передающий из QFutureWatcher результаты выполнения функции:
Вот и все, теперь каждый раз, когда принтер сообщает нам о температуре — мы разбираем эту строку и красиво отображаем ее в интерфейсе.
Проблема в том, что сам принтер ее присылает только во время нагрева, но мы можем его попросить прислать нам ее в любое другое время, отправив команду для проверки температуры M105. Отправлять ее будем по таймеру, при выполнении нескольких условий. Так же, как и ранее для функции отправки создаем новый таймер, и новый слот для подключения к его сигналу. На этот раз таймеру ставим значение побольше, например 1500мс:
Кто-то возможно скажет, что эти проверки излишние, но когда ты управляешь принтером с Asus EEEPC 900AX, и хочешь одновременно читать хабр — это необходимость.
Печать с SD карты
Очень многие типовые платы для 3D принтеров имеют встроенный слот для SD карты, или способ такой слот подключить. Такой метод печати является предпочтительным, так как в любой момент можно отключится от принтера и уйти, однако каждый раз вытаскивать SD карту зачастую лень, особенно если печатаешь много мелких деталей. Конечно, можно передать файл через серийный порт, но передача файла таким способом занимает едва ли меньше времени, чем сама печать.
Каждый раз когда на хост будет приходить строка, с которой начинается список файлов на SD — будем открывать диалог со списком файлов. Для этого еще раз изменим наш приемник:
Флаг нужен, так как наш метод чтения вызывается для каждой строки.
За одно для открытия диалога будем посылать сигнал. Самому же себе. Да, соединять можно даже сигналы со слотами одного и того же объекта.
Слот, который мы подключаем к этому сигналу:
После этого надо перевести интерфейс в режим печати. Я сделал это путем введения дополнительного флага sdprinting. Статус печати с SD карты проверяется в схожей манере с температурой.
Софт — в массы
Как бы сильно я не любил GitHub — далеко не все любят собирать софт сами. Не смотря на кроссплатформенность Qt — это фреймворк, а не среда для кросс-компиляции. А это значит, помимо бинариков под платформу Linux-amd64 нужны еще бинарики под Linux-i386, Windows 32 и OSX 64. Что ж, с первыми двумя все просто — достаточно добавить нужные наборы в QtCreator. А как быть с Windows 32 и OSX 64? С последней — никак. Я пытался, но я умываю руки. Единственный способ собрать что-то под OSX — делать это на OSX. К сожалению, легально это сделать не возможно.
Debian и его пакеты
Очень хотелось собрать пакет под любимый Linux Mint, на котором и ведется разработка. По началу я хотел собрать пакеты для PPA, но в итоге пришел к тому, что собирать надо со статическими библиотеками Qt, а потому пакеты на первое время собирать пришлось руками. Почему статическая линковка? Все очень просто — даже в Ubuntu 14.04, на которой основан Mint в источниках имеется только Qt 5.2.1. В ходе тестов первых двух релизов на разных системах выявились баги QSerialPort, исправленные в новых версиях, а потому было принято решение поставлять все с последними версиями. К тому же, вики Qt говорит, что статически линкованые библиотеки несколько быстрее работают.
Windows и MXE
Одно дело — собирать пакеты под свою ОС, другое дело — под чужую. Тут необходим тулчеин — набор инструментов для сборки. Благо под Windows есть отличный MinGW, а для Linux есть не менее отличный MXE — менеджер окружения для кросс-компиляции с использованием свободных библиотек.
Установка до смешного простая — клонируем MXE и говорим ему, какие нам библиотеки нужны:
После этого можно смело идти пить кофе — сборка всего этого добра занимает приличное время.
После того, как сборка окончена — можно написать скрипт сборки проекта под Windows автоматически:
Просто и сердито. Работоспособность легко проверяется в Wine:
Выводы
Когда я это начинал — я надеялся написать простую отправлялку G-code файлов, которая ничего больше бы не делала, а справится планировал за вечер. Но, как это часто бывает — проект вышел за рамки изначального плана, и теперь представляет из себя нечто большее. Впереди еще много чего предстоит сделать — хотя бы тот же графический редактор EEPROM, которого так не хватает, а так же поддержка контрольных сумм.
Однако уже сейчас RepRaptor позволяет мне спокойно использовать свой ASUS EEEPC как стабильный хост для принтера, чего не мог достичь ни один другой хост из тех, что я пробовал. Ну и знания Qt у меня определенно улучшились, и все равно еще есть место для оптимизаций.
Эта статья так же приурочена к выходу первой стабильной версии, которую я сам теперь использую каждый день — 0.2.
Всем спасибо за внимание! Надеюсь мой опыт был вам полезен.
Напоследок — вот армия объектов, напечатанных во время тестов: