Обратите внимание

С 01.06.2020 продукт KDS больше не дорабатывается, поддержка прекратилась 31.12.2020. Используйте KDS Pro.

Введение

Общеизвестно, что комплексы автоматизации RK6 и RK7 широко используют дополнительные возможности по "контролю приготовления блюд", в частности - KDS (Kitchen Display System) и VDU (Video Display Unit). О них и пойдет речь в данной статье, но не о софтовой части, а о том, что KDS-клиент и VDU могут быть реализованы не только на базе обычного ПК, но так же и на базе специальных ARM-контролеров производства компании UCS.

Лицензирование


Если, планируется использовать ARM-устройство в качестве клиента KDS - в этом случае необходимо получить лицензионный образ, который будет привязан непосредственно к этому устройству. Для получения, создается отдельный запрос в а Сервис-деске, в котором указывается ID того устройства для которого нужен образ. Никаких дополнительных параметров лицензирования не применяется.
 
Если, планируется использовать ARM-устройство в качестве VDU - в этом случае, образы берут с ftp://.../r-keeper/VDU/IMAGES_v3.2/    - (для версии №2 - с белой клавиатурой). После установки образа в память устройства, сам софт необходимо пролицензировать. Т.е. зайти в настройки VDU, где ввести в поля лицензии, код активации полученный из отдела лицензирования компании UCS.

Состав оборудования

  • Контролер KDS-VDU (Версия №1 или №2)
  • Блок питания (12В - 0,3А)
  • Клавиатура KDS-VDU (специализированная, Версия №1 - черная, Версия №2 - белая)

  • Монитор - подойдет любой (VGA-разъем). Приобретается отдельно. Выбирается исходя из размера и разрешения.

Сам контролер представляет из себя специально разработанный системный блок, на базе чипсета ARM, с ОЗУ, накопителем (Compact Flash) и необходимыми разъемами под LAN, VGA, RJ-12 (под спец.клавиатуру), USB. Питание - 12В, - 0,3А. На момент написания статьи (18.12.2013) было реализовано две версии данного оборудования:

Версия arm-контролера №2

Актуальная на данный момент версия. Состоит из контролера KDS.UCS.15.02.00 (VDU-Win 5.0) + клавиатура KDS.UCS.15.02.03 (белая). Контролер универсальный, может быть использован как для запуска VDU, так и для запуска KDS-клиента. Содержит постоянную память (накопитель - Compact Flash, 2Гб или выше), куда может быть записан образ с ПО, чтобы в дальнейшем использовать его на постоянной основе. Имеет функцию внутреннего сброса.

Важно!  Все современные ARM-контролеры идут с встроенной флеш-памятью!

Версия arm-контролера №1

Не выпускается на данный момент т.к. является устаревшей. Выпускалась и продавалась до Июля 2012 года. Контролер не имел функции внутреннего сброса. Работал с другой версией клавиатуры (черная). Содержал постоянную память (CF) - если использовался для VDU. И не содержал накопителя, в случае использования в качестве KDS-клиента. 

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

В плане установки и настройки, первая и вторая версии устройств практически ничем не отличаются между собой.

ARM-контролер без встроенной (CF) памяти 

Важно! Используется только для реализации KDS-клиента. Для VDU - наличие памяти обязательно!
  • Дистрибутивы находятся на ftp://.../r-keeper/KDS/ARM/.
  • Для запуска устройства требуется наличие DHCP-сервера в локальной сети. Если такового нет, можно использовать небольшой автономный сервер - см. архив tftpd32.zip. Распаковывается, устанавливается, настраивается диапазон пула IP-адресов и запускается.

Для базовой загрузки на устройство образа используется утилита BootImpLoader.exe. Сборки на FTP периодически меняются, на момент написания статьи например, отдельно лежат BootImpLoader_KDS.rar, BootImpLoader_VDU.rar - фактически они идентичны. Так что использовать можно любой из них.
В файле boots.cfg необходимо прописать строку вида:

KDS005A80000006->KDS.bin
CODE

- где KDS005A80000006 - идентификатор устройства (можно считать с экрана монитора при включении контролера - первая строка), KDS.bin - файл образа для загрузки в устройство.

Важно! Файл образа для работы с KDS-клиентом генерируется ответственными специалистами UCS под каждое конкретное устройство и предоставляется компанией UCS по отдельному запросу! 

Если, устройств несколько, в файле boots.cfg необходимо прописать строку для каждого из них, с указанием устройств и назначенным для загрузки в них образам.

KDS005A80000006->KDS1.bin
KDS005A80000007->KDS2.bin
KDS005A80000008->KDS3.bin
CODE

Далее, необходимо запустить BootImpLoader.bat и устройство должно автоматически найти сервис и загрузить свой образ. Приложение BootImpLoader.exe можно запускать в качестве сервиса - для этого нужно его запустить с ключем -install:

BootImpLoader.exe -install
CODE

Важно! Ошибка "package lost" - чаще всего говорит о проблемах настройки сети, т.е. загрузчик отправляя пакеты образа на устройство теряет с ним связь и делает повтор передачи того или иного пакета. Если пакеты совсем не проходят, то желательно настроить ПК на один единственный сегмент сети, тот в котором работают ARM-устройства. Все дополнительные сети либо убрать, либо грамотно проверить и настроить маршрутизацию между ними.

После того, как устройство загрузит образ KDS, оно готово для принятия данных и отображения информации:

Следующим этапом будет установка стандартной системы KDS (если этот шаг уже был сделан, пропускаете его). Установка системы KDS описана в отдельной статье - необходимо выполнить все по инструкции и добиться успешного запуска сервера и для проверки, клиента KDS на том же ПК, где и сервер. Т.е. система должна быть полностью в рабочем состоянии!

Для отображения экрана KDS на ARM-устройстве используется спец. терминальный сервер RK7tmsrv.exe. На ftp выложено несколько сборок этого сервиса. Необходимо брать последнюю по дате обновления, например - ftp://.../r-keeper/KDS/ARM/RK7tmsrv_7_3_7_11.7z.

Сразу рекомендуется обновить в используемой сборке файлы rkloader.dll и rkloader.ini. Самая актуальная версия этих файлов, как правило содержится в каталоге дистрибутива используемой версии KDS. Например - ftp://...r-keeper/KDS/1.2.x/KDS_1.2.8.4.7z  (каталог - \rkloader).

Далее, нужно настроить путь к клиенту KDS и идентификатор устройства в файле rkLoader.ini:

[CESETTINGS]
.......................
Application=С:\UCS\KDS\Client\kdsclient.exe
CEStations=KDS005A80000006;
CODE

- где:

- С:\UCS\KDS\Client\kdsclient.exe   - полный путь к исполняемому файлу клиента KDS, который вы настроили ранее
- CEStations=KDS005A80000006        - идентификатор вашего ARM-устройства
CODE

Необходимо учесть, что содержимое инифайла может быть разным в зависимости от используемой версии файла rkloader.dll
Если, устройство не одно, в параметре CEStations нужно указать все идентификаторы через "точку с запятой":

CEStations=KDS005A80000006;KDS005A80000007;KDS005A80000008;
CODE

После запуска BootImpLoader.exe устройство должно подключится к серверу и отобразить экран клиента KDS.
Чтобы сделать настройки клиента KDS, который отображается на экране ARM-устройства, нужно в окне терминального сервера RK7tmsrv.exe нажать правой кнопкой мыши и выбрать Show Дополнение.

В последних версиях изменена технология сетевого взаимодействия - вместо протокола UDP используется протокол TCP/IP, чтобы исключить "зависание" контроллеров после их выключения/включения.
Использование протокола TCP/IP имеет некоторые особенности - компьютер, на котором будет запущено приложение RK7tmsrv.exe должен иметь дополнительный IP-адрес 172.31.32.100 - именно по этому адресу будут пытаться подключиться все контролеры KDS.
И еще один нюанс - если на объекте контролеры KDS получают IP-адреса с общего DHCP-сервера, то может возникнуть ситуация, когда они не смогут подключиться к адресу 172.31.32.100 из-за проблем с маршрутизацией. Решений может быть несколько - либо настроить в сети маршрутизацию между местной локальной сетью и сетью 172.31.32.ххх (задача администратора сети) либо использовать автономный DHCP-сервер (есть в архиве) и с помощью него выдавать контролерам адреса из пула 172.31.32.ххх.

Состав дистрибутива

  • kds_167.zip - образы дл вашего устройства (под разные разрешения)
  • BootImpLoader.zip - загрузчик
  • tfpd32.zip - автономный DHCP-сервер
  • KDS.zip - обновленный клиент KDS, записать в рабочую директорию вместо текущего (полный дистрибутив KDS можно взять на FTP ftp://ftp.ucs.ru/rk7/other/KDS_PRO/
  • Loader.zip - версия RK7 Tiny Server с поддержкой TCP/IP

ARM-контролер с встроенной памятью (CF)

В архиве дистрибутива две утилиты для работы с контролерами:

  • svc.exe - для поиска и отображения информации по запущенным контролерам
  • fserver.exe - утилита для записи образа в NAND-память контролера


Для подключения к контролеру надо знать его IP-адрес - если не знаем, запускаем утилиту svc.exe (ftp://.../r-keeper/VDU/TOOLS/), она автоматически  обнаружит все  запущенные  устройства  и  отобразит их адреса (чтобы утилита svc.exe увидела  контролер,  на нем должен быть загружен любой стандартный образ - если образа нет, надо его загрузить с помощью BootLoader-f)
 
Когда IP-адрес определен, запустить с командной строки:

telnet <IP-адрес> 1234
CODE
Важно: Подключения к контролеру через telnet возможно только после загрузки образа - если попытаться подключиться в режиме загрузчика, на экране контролера будут возникать ошибки "!CheckUDP:not UDP (proto = 0x00000006)"

После успешного подключения на экране отобразится следующее меню:

KDS005A80000XXX
HELP:
H - this page
I - get flash ID
R - read flash 0 page
U - read uniq
W - write flash 0 page with trash
E - erase all flash pages
L - load flash from server
S - save flash to server
D - dump flash to server
B - load bootloader(not realized)
Y - load NK to NAND (as hdd)
X - reboot target
Q - quit
LOCK - toggle write enable
Write Disabled
CODE

- где KDS005A80000XXX - идентификатор контролера.
 
Для проверки контролера вводим команду "I", на экране должна отобразиться след. строка:

I
0000EC75
OK:00000000
CODE

Если вместо 0000EC75 что-то другое, проблема с памятью контролера.
 
Для стирания всех данных в контролере используется команда "E", при этом стирается ВСЯ память (в том числе область, где хранятся настройки программ (например, VDU или BERG).
 
Важно: Возможно повредить контроллер, если сделать что-то неправильно!
 
Для прошивки нового образа не обязательно выполнять полное стирание. Последовательность действий для загрузки в память контролера (NAND) нового образа:

  • Переименовать новый образ в NK.BIN
  • Запустить fserver.exe
  • Запустить telnet <IP-адрес> 1234 (если не запущено)
  • Напечатать  LOCK  и  нажать <Enter> - устройство перейдет в режим записи (последняя строка должна быть "Write Enabled")
  • Напечатать  "L"  и нажать <Enter> - начнется процесс передачи и записи образа (fserver.exe должен быть запущен!)
  • После  окончания  процесса  напечатать  "X"  и нажать <Enter> - устройство перезагрузится с новым образом

Чтение/запись конфигурационного файла

Возможно прочитать настройки (ini-файл) с устройства и сохранить их на контроллер ARM используя утилиту FSERVER.EXE. Версия вашего контроллера должна быть не ниже 2.2.

2.1. Запустите FSERVER.EXE

2.2. Откройте командную строку и пропишите следующее. Выполнение каждой команды как обычно происходит при нажатии клавиши "Enter".

telnet IP_address 1234

открыть соединение с хостом

LOCK

можно модифицировать память на устройстве VDU

G

сохранит файл VDUSAVE.BINI на диск

2.3. Следует сохранить VDUSAVE.BINI файл в текстовом виде (он в двоичном виде, преобразовывается с помощью bini2ini.exe)

2.4. После запуска bini2ini.exe будет создан файл vdusave.bini

2.5. Измените файл vdusave.bini (используя "блокнот") и сохраните его как VDU.INI. 

2.6. Конвертация обратно в бинарный файл происходит при использовании ini2bini.exe. С ее помощью следует создать файл vdu.bini

2.7. Для передачи новых настроек на ВДУ, вернемся к CMD:
напечатать "C" - будут скопированы настройки на устройство ВДУ
 
напечатать "X" - будет перезапущено устройство ВДУ