Навигация по разделу "Инструкции, софт и прошивки": Zipstore.ru > Инструкции, софт и прошивки > Меттлер Толедо
Получение отчетов с весов Mettler Toledo Tiger P
Чтение отчетов реализуется передачей в весы команды
000909000200010100000001999999
( формат CMDHEADER"U02L06L06" , где U02-поле выбора вида отчета,
L06 L06– значения начального и конечного номера PLU )
с помощью функции
Transfer_Ethernet_EX("Transscale.ini",251245664)
Информация с весов размещается в бинарном формате в файле trf”Nr_Scale”.in.
Управляющее поле U02 может принимать 4 значения: 00, 01, 02, 99.
В случае выбора 00 формируется отчет по PLU, причем информация размещается в файле в соответствии с форматом:
FileHeader;//40 bytes
BYTE STX;// '02'
WORD command;//2 bytes '8D' '03'
BYTE control1;// '00'
BYTE control2;// '00'
struct PLUREPORT{
long int plu_nr;//4 bytes
char ArtNr[14];//14 bytes
char Name[28];//28 bytes
long int amount;//4 bytes
long int weight;//4 bytes
long int count;//4 bytes
}PluReport[5];//290 bytes
BYTE crc1;
BYTE crc2;
BYTE ACK;// '06'
Наибольшее число PLU в каждом отчете не превышает 5, поэтому для получения полного отчета требуется многократная посылка команды 909 с последовательно возрастающими значениями стартового номера PLU ( новый стартовый номер PLU должен на единицу превышать последний номер PLU из предыдущего отчета ). Конечный номер PLU команды 909 в рассматриваемом виде отчета особого значения не имеет.
При задании управляющего параметра, равным 01, реализуется итоговый отчет по весам в формате:
FileHeader;//40 bytes
BYTE STX;// '02'
WORD command;//2 bytes '8D' '03'
BYTE control1;// '01'
BYTE control2;// '00'
long int amount;//4 bytes
long int weight;//4 bytes
long int count;//4 bytes
BYTE crc1;
BYTE crc2;
BYTE ACK;// '06'
Полученные значения суммы, суммарного веса и кол-ва продаж в общем случае могут не совпадать с результатами суммирования значений, полученных в предыдущем отчете. Вызвано это тем, что итоговый отчет содержит информацию о транзакциях, реализованных также и без выбора какого-либо значения PLU.
Начальное и конечное значения PLU команды 909 при формировании этого отчета не используются.
Выбор параметра 02 дает возможность получения информации об изменениях цен товаров. Формат представления информации следующий:
FileHeader;//40 bytes
BYTE STX;// '02'
WORD command;//2 bytes '8D' '03'
BYTE control1;// '02'
BYTE control2;// '00'
struct PRICE_CHANGE_REP{
long int plu_nr;//4 bytes
long int date;//4 bytes
int time;//2 bytes
long int oldprice;//4 bytes
long int newprice;//4 bytes
}PRICE_CHANGE_rep[5];//90 bytes
BYTE crc1;
BYTE crc2;
BYTE ACK;// '06'
Также как и в первом отчете при однократном использовании команды 909, максимальное кол-во записей равно 5. Полный отчет требует повторного запуска команды с изменяемыми значениями начального и конечного PLU. Максимально возможное кол-во записей этого отчета равно 800. Необходимо отметить, что в отчет попадают только PLU с непосредственным изменением цены, а не те, в которых цена изменилась из-за скидки или спец.предложения.
Параметр 99 обеспечивает удаление отчетов в памяти весов. При этом управляющее поле в CMDHEADER вместо 0002 ( READ ) должно принимать значение 0000 ( WRITE ).
5. Статус весов Меттлер Толедо Tiger P
Чтение текущего статуса весов
0002040003000000000
( формат команды CMDHEADER"S03" )
может осуществляться с помощью вызова функции
Transfer_Ethernet_EX("Transscale.ini",251245664)
Рассматриваемая команда на самом деле считывает список операторов из весов в файл trf”Nr.Sc.”.in. При отсутствии записей в списке продавцов в файле тем не менее имеется служебная информация. Алгоритм определения статуса ( Вкл/Выкл ) состоит в циклическом запуске команды 204 и анализе содержимого файла отклика trf”Nr.Sc.”.in.
6. Протокол передачи данных
Драйвер от производителя весов в виде набора dll файлов, входящих в состав SPCT ( TransferEth.dll, PLUFmtConvert.dll, ArcnetTxt_Bin.dll, CompressLZ77.dll, CrcModule.dll ), за предшествующие годы эксплуатации подтвердил высокую скорость и стабильность передачи данных в “ многопользовательском “ ( несколько весов в списке рассылки ) и “многозадачном” ( различные файлы команд ) режимах.
Тем не менее, некоторые пользователи предпочитают писать собственный драйвер, как правило, с целью передачи только команд загрузки PLU ( команда 207 ) и ингредиентов ( команда 209 ). “Открытый” вход для передачи любых из рассмотренных выше команд весов Тайгер-П обычно не реализуется из-за отсутствия синтаксического контроля команд.
Задача написания собственного драйвера для весов Тайгер-П не представляется очень сложной в силу того, что при пересылке любой информации с помощью программы SPCT в одном из файлов trf”Nr_scale”.in.log ( передача по Ethernet ) или log.hex ( передача по COM ) сохраняется протокол ( последовательность байт ) последней переданной команды. Эта подсказка оказывает существенную помощь при написании и отладке драйвера. Передаваемая последовательность в файле структурирована путем разбиения информации на 4 строки, при этом во второй и третьей строке содержатся описанные в предыдущих разделах заголовок и тело команды, соответственно, а первая и последняя строка содержат заголовок посылки и контрольную сумму. Для изучения удобнее использовать файл протокола передачи по Ethernet trf”Nr_scale”.in.log ( где ”Nr_scale” – номер весов ), поскольку в начале этого файла записан заголовок и тело команды в привычном символьном виде.
Первая строка ( заголовок посылки ) содержит семь байт и описывается структурой вида:
struct packetheader
{
unsigned char start; //start flag of one packet always 0x2
unsigned short totallength; //totallength = sizeof(cmdheader) + pagenumber * pagelength
unsigned short pagenumber; //the number of pages of itemdatas in this packet
unsigned short pagelength; //the length of each page of itemdatas
}
Передача всегда начинается с посылки стартового байта “02”, далее идут 2 байта общей длины посылки с учетом заголовка команды, потом кол-во страниц ( фактически кол-во пересылаемых последовательно команд ) и два байта длины тела команды.
Во второй строке содержатся 8 байт неоднократно описанного ранее заголовка CMDHEADER команды:
struct cmdheader
{
unsigned char cmdrsp; //command or response
unsigned short command; //command id such as 207,213 and so on
unsigned short control; //command type: RD(read) or WR(write) and so on
unsigned short departno; //department number always 1
unsigned char deviceno; //scale number
}
В третьей строке записано тело команды ( различные типы команд рассмотрены в предыдущих разделах ) с конвертацией символьного формата команды в байтовый на основе учета требуемого кол-ва байт для представления разных типов полей:
С - 1 байт; //char or unsigned char, 1 byte for each char
U - 1 байт; //BYTE //U01…U03
B - 1 байт; //BYTE //B01
F04 - 2 байта; //4 Hex flags, each 0…0Fh
S - 2 байта; //short int, int , unsigned int or WORD // S01…S05
L - 4 байта; //long int or unsigned long int // L06, L08, L11.
Таким образом, при пересылке данных под поле вида B01 или Uxx отводится 1 байт, поля F04 и Sxx кодируются двумя байтами, а каждое поле типа Lxx передается с помощью четырех байт. При этом в случае многобайтового представления первым передается младший байт, а последним – старший. Описанное преобразование используется не только в теле команды, но и в заголовках команды и пакета. Что касается текстовых полей вида Cnn, то каждый символ представлен в DOS – кодировке ( page 866 ) и передача текстовой строки занимает nn байт.
Четвертая ( последняя ) строка содержит два байта контрольной суммы, вычисляемой путем вызова функции:
unsigned short int Crc = CalcCRC16 ( char buf+1, unsigned int len-1 ),
из динамической библиотеки, находящейся в файле CrcModule.dll.
В буфер “buf” записывается вся сформированная посылка длиной len, но в формировании контрольной суммы не участвует первый “02” стартовый байт ( buf + 1, len – 1 ). Полученное двухбайтовое целое Crc добавляется к посылке в следующем порядке: сначала старший байт, затем – младший.