Спецификация на девайс есть? От нее нужно и отталкиваться что, сколько и когда отправлять данных.
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Delphi: WinAPI и системное программирование > Реализация протокола |
| Автор: RinOSpro 25.7.2008, 10:31 |
| В общем, есть устройство, и есть протокол к нему. И нужно его реализовать. Устройство работает по принципу: «Устройство запрашивает у меня данные, я ему отвечаю «Получил твой пакет, сейчас отправлю данные», потом «Отправляю данные». И наоборот. Соединяюсь с устройством по COM порту. В общем, какие будут советы? Кто сталкивался с реализацией протоколов? Как это лучше сделать? Может, какая литература есть? Т.к. мой вопрос не конкретный, а абстрактный, поэтому и жду таких же ответов! |
| Автор: Alkash 25.7.2008, 10:35 |
| http://sourceforge.net/project/showfiles.php?group_id=91848 |
| Автор: Rennigth 25.7.2008, 10:38 |
| RinOSpro, хм... что-то уж очень абстрактно описал задачу... Спецификация на девайс есть? От нее нужно и отталкиваться что, сколько и когда отправлять данных. |
| Автор: RinOSpro 25.7.2008, 10:39 |
| Желательно на русском языке... |
| Автор: Alkash 25.7.2008, 10:43 |
| http://www.opennet.ru/docs/RUS/socket/node13.html |
| Автор: RinOSpro 25.7.2008, 10:50 |
| Alkash не то. Ладно слегка конкретизирую... С COM порта читаю данные. Кадр начитаются и заканчивается определенным байтом. В пакетах содержаться какие то команды, размер пакета заранее тоже не известен. И не известно что придет в этом пакете... Толи это будет опрашивающий пакет, толи пакет с командой. Если с командой то нужно ответить что я ее получил. потом обработать и отправить ответ. |
| Автор: Alkash 25.7.2008, 11:41 |
| А в чём затруднения? |
| Автор: RinOSpro 25.7.2008, 11:47 |
| Alkash - ну раз тебе кажется все просто дай хотя бы пару советов! |
| Автор: Alkash 25.7.2008, 12:06 |
| В какой области тебе нужны советы? Как данные обработать? |
| Автор: RinOSpro 25.7.2008, 12:18 | ||
Угу. |
| Автор: Alkash 25.7.2008, 13:16 |
| По спецификации и смотри, как разобрать то, что пришло на порт. А как инфу с порта получить\отправить - глянь в ДКРБ |
| Автор: Magik 25.7.2008, 15:31 |
| Если применительно к существующим системам, то подобные протоколы применяются для передачи телеметрии. До конца прошлого века каждый производитель писал свой протокол. Где то с 1996 года и далее стали приходить к международным стандартам. Поэтому сейчас для передачи данных используют, наиболее часто, протоколы IEC 60870-5-101/104 (в обиходе МЕС101/104). Про них можешь читать из поисковиков. В общем, структура довольно сложная. Для передачи данных используется ЕХЕ-шник, который по запросу к базе данных формирует пакеты согласно протокола. Передача их в порты вывода зависит от назначения. МЕС101 - для RS232. МEC104 - для ETHERNET. Думаю, конкретный код навряд ли здесь тебе сообщат. |
| Автор: RinOSpro 25.7.2008, 17:47 |
| Magik ссылку не подкинешь, а то искал но про описание протокола, нашел только в википедии на англиском языке (( |
| Автор: Magik 25.7.2008, 20:10 |
| Вот можно почитать здесь: http://telemex.nm.ru/library_05.htm Обобщённый стандарт на русском языке - ГОСТ Р МЭК 870-5-101 , ГОСТ Р МЭК 870-5-104. Они опираются на ранее принятые ГОСТ Р МЭК 870-5-1(2,3,4,5)-95(96). У программистов , владеющих технологией применения МЕС , это считается "высшим пилотажем". |
| Автор: RinOSpro 28.7.2008, 09:51 |
| Magik а средним пилотажем что считается? |
| Автор: Magik 28.7.2008, 18:42 |
| Думаю, что, если знать - что и почему в этих цифрах, за средний - с лихвой! А в общем , это обмен (трасировка) по 101 протоколу, асинхронная, небалансная передача. Пакеты постоянной (10), и переменной длины (68). Да это всё описано в ссылке, что я давал. Ну, а что внутри, тоже можно там же прочитать. Но эти вопросы для обсуждения не на этом форуме. Да и , думаю за эти посты модератор может дать по кумполу. 28-07 19:01:20.928 <10 5B 7E D9 16 28-07 19:01:21.021 >10 09 7E 87 16 28-07 19:01:41.178 <10 7B 7E F9 16 28-07 19:01:41.225 >68 26 26 68 08 7e 0d 86 01 7e e9 03 00 00 00 00 80 00 00 00 00 80 00 00 00 00 80 00 00 00 00 80 00 00 00 00 80 00 00 48 42 00 8e 16 28-07 19:03:21.225 <10 09 7E 87 16 |
| Автор: Virtuals 28.7.2008, 20:59 |
| RinOSpro, отвечай на вопросы по пунктам; .1.есть ли описание протокола? .2.допускает ли канал связи потерю/искажение данных .3. есть ли девайс работающий по данному протоколу? .4.есть ли лог обмена девайса с чем либо по данному протоколу? и подумаем как ковырять данное |
| Автор: Magik 29.7.2008, 06:27 |
| Очень ценная статья есть здесь http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1126 с приложенным файлом. Лично мне очень нравится, и можно применять на прктике для тестирования каналов передачи данных с разными скоростями и паритетами. Протокол простой, но работает чётко. |
| Автор: RinOSpro 29.7.2008, 08:02 | ||
| Virtuals Хорошо щас отвечу, но есть одно но! В общем такая ситуация протокол есть я даже могу посылать команды и принимать их. Но знаешь какая глобальная проблема?! как сделать качественную обработку.... Не то что тупо получил пакет сравнил с чем то и, отправил, нужно в реализация на высоком уровне... просто устройство сцуко умное... Кстати Magik тот лог что ты мне показываешь
Я уже такой реализовывал... это было довольно просто нежели сейчас... У предыдущего устройства протокол был 2 A4 )) и все нормально реализовал работает. а у нового протокол 150 A4 ((( и продвигаюсь как черепаха... Virtuals 1. Да 150 стр. англ. текста. 2. Да есть контроль правbльности пакетов достигается через CRC16 3. Да девайс есть и есть уже небольшие продвижения ) 4. Лог обмена есть причем от родной программы этого девайа. Вот не понимаю как в родной программе так все красиво и без глюков работает ) а у меня не получается (( |
| Автор: Virtuals 29.7.2008, 12:15 |
| RinOSpro, ну так как мне нереально читать доки ваши то могу дать несколько советов, по крайне мере как я поступаю! итак: 1. забудте что данные приходят пакетами кусками и т.д. представте что это непрерывный поток 2. нам нужно гдет хранить данные пока мы их полностью непримем, и не обработаем 3. для начала определимся что есть начало БЛОКА а что конец (именно набор условий) (сдесь и далее буду приводить свой пример) //набор спецификаций: блок начинается на 10 01 кончается на 10 02 если в блоке встречается 10 то она меняется на 10 10 -- отсюда выводим правила начало: 10 01 если перед ними нет нечетного количества десяток конец: если было начало и если есть 10 02 и перед ними нет нечетного количества десяток 4 так научились выделять из потока нужные нам блоки, тепер структура обработки процедура приема данных: принимаем байты неважно как, и побайтово выкидываем в процедуру буфера конец процедура буфера: принимаем по одному байту в раз проверяем размер буфера на предмет возможного переполнения (если переполнение то сбросить флаги начала блока...) пихаем байт в хвост буфера отдаем буфер на дешифровку конец процедура дешифровки: анализируем буфер сначала и ищем начало блока (условия известны) если нашли то сдвигаем буферт так чтобы первым было начало буфера /10 01/ дыбы выкинуть мусор и взводим флак начала если флаг начала анализируем буфер на предмет конца блока если ненашли то свалить иначе из буфера выдераем весь БЛОК, что осталось смещаем на первую поз, сбрасываем флаги а блок передаем в процедуру анализа конец процедура анализа вот сюды и будут падть уже чистые блоки согласно вашим протоколам осталось проверить контрольную сумму и если все пучком то принять ответные действия ЗЫ удачи в этом нелегком деле |
| Автор: RinOSpro 30.7.2008, 10:02 |
| Virtuals помоему это нереально сложно... Я так подумал, почитал и наверно буду делать в потоке через статусы... К примеру когда я отправил пакет ставлю статус скажем st_read_response, и в потоке смотрю если этот статус, то ждать ответа получил ли девайс мой пакет, устройство мне может вернуть или ошибку или данные, к примеру если ошибка, то заного ставлю статус который выполнит повторно эту команду, а если получил данные и CRC верно тогда ставлю статус st_write_response. Примерно так... Как вам такая схема? |
| Автор: Virtuals 31.7.2008, 21:05 |
| а никто не обещал что это просто, я описал алгоритм выделения блоков из потока принимаемых данных, и поверьте без него никак (глючить будет неподетски), а реализация алгоритма обмена (запрос-ответ) это следующий уровень потребуется послать комманду, и ждать ответа,учесть что: данные могут вообще неприйти, прийти поврежденными, прийти не те которые ожидаем, короче нужен таймаут на ответ, и перечень ожидаемых ответов... ваша идея в общем верна, но учтите описанное выше |
