7188E отправить команду через tcp в com порт

[SamuelS]

Подскажите пожалуйста как настроить передачу команды по Modbus через сеть в com port.
Есть устройство ICP 7188E прошил его на Modbus.
К нему подключаюсь но послать команду на com порт не могу!
Подскажите пожалуйста как быть с чего начать!?
Очень нужна помощь!!!!!

[alex_ugrumov]

Подскажите пожалуйста как настроить передачу команды по Modbus через сеть в com port.
Есть устройство ICP 7188E прошил его на Modbus.

Почему не взять для этого стандартную коробку? У того же ICP-DAS http://www.icpdas.com/products/PAC/i-71 ... us_PAC.htm или у MOXA или ещё пары десятков вендеров?

К нему подключаюсь но послать команду на com порт не могу!

Почему не можешь? Будь мужиком! возьми и пошли!

Подскажите пожалуйста как быть с чего начать!?

С того, что чётко описать что делается, как делается, что не получается, какие мероприятия проведены для локализации проблемы, что эти мероприятия дали.

Очень нужна помощь!!!!!

Как и нам всем

[SamuelS]

К сожелению есть только ICP 7188E.
Я правильно понимаю контроллер если говорить про Modbus это slave на компе в совте должен быть мастер!
Я подключась по ip адресу через modbus.
Но надо еще менять прошивку самого контроллера!? Или стандартная прошивка для Modbus подойдет?
Что бы он понимал что у него есть ком порт 2 и передовал в него команду.
Блин у меня есть софтина для работы с ком портом напрямую я открываю порт и передаю команду из масива байтов и все.
А как тут, подключаюсь, надо ли открывать порт tcp, как получить список com портов на устройстве и в дальнейшем к нему обратится?

[alex_ugrumov]

К сожелению есть только ICP 7188E.

Бывает

Я правильно понимаю контроллер если говорить про Modbus это slave на компе в совте должен быть мастер!

Я правильно понимаю, что это был вопрос?
А про какой Modbus идёт речь (тут упоминалась и сеть, и СОМ)?
Если я правильно понял Ваше восклицание, то да, на верхнем уровне обычно мастер (клиент), на нижнем - слейв (сервер). Это справедливо и для инициатора TCP коннекции, если речь идёт о ModbusTCP, и о инициаторе обмена данными для любого вида Modbus. Верхний имеется ввиду по иерархии, не по высоте над уровнем моря. Если компьютер у Вас является конечным потребителем данных, то его удобно сделать мастером: пусть сам решает когда и какие данные ему нужны. Всё сказанное относиться к распространённой практике. Стандарт Modbus не накладывает ограничений на то, какие устройства могут/должны выступать мастером/слейвом. Он лишь требует, чтобы кто-то один был мастером и инициировал обмен данными.
И, кстати, по СОМ Вы какой Modbus используете RTU или ASCII? А по сети (имеется наверно ввиду сеть Ethernet и стек TСР/IP) Вы используете ModbusTCP или RTU over TCP?

Я подключась по ip адресу через modbus.

Получается?

Но надо еще менять прошивку самого контроллера!? Или стандартная прошивка для Modbus подойдет?

А что такое стандартная прошивка? Прошивку у этих контроллеров не меняют, даже не уверен, есть ли такая возможность. Если речь идёт об управляющей программе, то тут зависит от того, какая у Вас конкретная модель, новый это контроллер или кто-то его уже программировал и т.д.

Что бы он понимал что у него есть ком порт 2 и передовал в него команду.

Он понимает, что у него есть СОМ порт. Пересылать ничего не будет пока Вы ему "не объясните" что пересылать и как.

Блин у меня есть софтина для работы с ком портом напрямую я открываю порт и передаю команду из масива байтов и все.

Становиться понятней. То есть есть программа на ПК, которая, умеет работать по Modbus RTU или ASCII через указанный СОМ порт. Хорошо, и почему её нельзя тут использовать, зачем 7188?
Вопрос чуть в сторону. Вы студент? или школьник? техникум? Эта такая традиция посетителей образовательных учреждений, чтобы из них ответы "клещами вытягивали"?
Назад по теме. Вам нужно сделать, так опишите нормально, что Вам нужно сделать. Зачем Вы взялись за 7188? Какие у Вас устройства есть, кроме 7188? Как они соединены между собой? Какое ПО исполняется на этих устройствах? Чего хотите добиться?

А как тут, подключаюсь, надо ли открывать порт tcp, как получить список com портов на устройстве и в дальнейшем к нему обратится?

Порт открывать нужно. Список СОМ портов для каждой модели устройств серии 7188 жёстко определён, обращаются к ним по номерам. Номера СОМ портов обычно указаны рядом с клемником/разъёмом.

[SamuelS]

В общем, задача такая есть поворотная платформа на платформе антенна она подключена к компу на прямую через ком порт, есть задача управлять ей через LAN, 7188E был взят не только потому что он это могет но и потому, что при помаши платы расширения, по-моему 107 контролировать наличие питания 24v и контролировать вскрытие двери механизма "геркон" (но это второстепенная задача). Мне бы хотя бы с управлением разобраться (есть 5 команд в HEX).
RTU или ANSСII как я понимаю сугубо мой выбор или я не прав?
По поводу прошивки там есть Firmware, в том числе и modbus или это пример (exe файл и батник). Прога написана мною но только для работы с ком портом, ее надо модернизировать.
И к слову я студент и есть вот такая задача, своих мозгов, к сожалению не хватает!!!

[alex_ugrumov]

В общем, задача такая есть поворотная платформа на платформе антенна она подключена к компу на прямую через ком порт, есть задача управлять ей через LAN, 7188E был взят не только потому что он это могет но и потому, что при помаши платы расширения,

Махать платой расширения не стоит...

по-моему 107 контролировать наличие питания 24v и контролировать вскрытие двери механизма "геркон" (но это второстепенная задача). Мне бы хотя бы с управлением разобраться (есть 5 команд в HEX).
RTU или ANSСII как я понимаю сугубо мой выбор или я не прав?

Смотрите, есть такая распространённая задача, конвертер интерфейсов. Когда с одной стороны один интерфейс, с другой, соответственно, другой. И этот преобразователь настраивается. Таким образом можно без программирования (путём настройки) преобразовать один протокол в другой, или даже сменить интерфейс (например, из с одной стороны СОМ, с другой Ethernet). В этом случае конвертер подбирается под конкретный протокол и там важно, какой это протокол. В таких задачах внутренняя программа конвертера обычно полностью разбирает пакет, полученный по одному интерфейсу, и собирает пакет для другого; и ей нужно знать по какому правилу они собираются/разбираются. Редко, когда можно взять пакет, вычленить из него часть (или приписать дополнительный заголовок) и получить пакет другого протокола. Обычно всё таки приходится разбирать всё до последнего поля. В Вашем случае всё проще, и действительно какой протокол по COM порту пока не важно.

По поводу прошивки там есть Firmware, в том числе и modbus или это пример (exe файл и батник). Прога написана мною но только для работы с ком портом, ее надо модернизировать.

Ок, теперь понятно. Вы наверно говорите о Mbt7_170? Смотрите в примерах Napdos\Modbus\7188E\Demo\BC\Mbt7_172 есть исходник.
Пару слов о 7188. Это свободно программируемый контроллер (или РС-совместимый, но он не совсем 86-архитектуры, но не важно). На самом деле это просто почти компьютер IBM186. только без видяхи и без клавиатуры и много ещё без чего, но под управлением DOS-подобной операционной системы. Для простоты можно его рассматривать как компактный 186 компьютер с DOS. Чтобы компьютер делал что-то полезное, нужно написать программу. Причём как вы знаете, наверно, DOS - однозадачная ОС, то есть программа одновременно может работать только одна. То что вы заливали под названием firmware и есть какая-то такая программа. Есть готовые программы для типовых задач, например, для конвертера интерфейса. А можно написать самому. И второй путь (самостоятельное писание) основной (Есть ещё soft-logic... но это вообще не Ваш случай). И Вам придётся идти по нему, потому что обмен с платой расширения стандартной функцией не поддерживается.
Вы можете изменить ПО на верхнем уровне, это хорошо.
Часто это не возможно или такие изменения ограничены. Например, наверху SCADA и она работает по стандартных протоколам. ModbusTCP один из них. Всё тут деваться не куда - нужно взять конвертер (или это firmware) и настраивать. А как же плата расширения? (На самом деле всё действительно решается ещё проще - нужно поставить MoXA nport и виртуальный СОМ порт драйвер. И ПО верхего уровня менять не нужно. Но в этом случае до геркона достучаться, по крайне мере не подключить непосредственно к конвертеру. ) У вас проще. Ваше ПО верхнего уровня не обязано следовать стандарту ModbusTCP. Не нужно реализовывать точно протокол ModbusTCP. Ведь Ваше ПО умеет формировать пакет управления и разбивать ответ. Ну что ж, теперь просто нужно её переписать так, чтобы она писала этот пакет (или читала ответ) не в (из) COM порт, а в коннекцию TCP. А 7188 будет принимать пакет по ТСР коннекции, и не разбирая его передавать на СОМ порт (ответ в обратную сторону). Таким образом функция 7188 сводиться только к передаче пакета и какой там протокол вообще не важно. Такой режим называется Modbus RTU over TCP. Это не стандартный режим, хотя и встречается. И для 7188 нужно написать такую простенькую программку. А что же с платой и герконом? А вот тут придётся всё таки усложнять программу для 7188 и заниматься разбором разбором пакета от ПК. Можно например, если пришёл пакет доя устройства с адресом 1 пересылать его на антенну, а если с адресом 2 - то самостоятельно формировать ответ. В этом решении останется только одно слабое звено - Modbus RTU over TCP, которое не является стандартным решением и при замере верхнего уровня в будущем будет накладывать серьёзные ограничения на выбор нового ПО. Так что напоследок придётся реализовать полноценную поддержку Modbus TCP в Вашей программе, в программе 7188. Придётся сделать полноценную поддержку Modbus TRU в 7188 и ещё модуль опроса платы расширения.

Вот так экономия копеечная на HW приводит к дикому раздуванию задания на SW. Конечно в условии дармовой студенческой силы это неважно, но в условиях реального интегратора стоило бы существенно бОльших по сравнению с железом денег. Правильное решение: nport с RealCOMDriver, + модуль ввода вывода серии M-7000 для подключения геркона. Вся задача решается за 0,5 дня без единой строки кода (Ах да в ПО верхнего уровня лампочку нарисовать - "дверь открыта").

Но это хорошая учебная задача, будете работать по специальности, пригодится.

И к слову я студент и есть вот такая задача, своих мозгов, к сожалению не хватает!!!

Не переживайте со временем это исправится, наверно...

[SamuelS]

Alex, спасибо вам большое за помощь, буду трудится!!!!

[MuadDib]

А что же с платой и герконом? А вот тут придётся всё таки усложнять программу для 7188 и заниматься разбором разбором пакета от ПК. Можно например, если пришёл пакет доя устройства с адресом 1 пересылать его на антенну, а если с адресом 2 - то самостоятельно формировать ответ. В этом решении останется только одно слабое звено - Modbus RTU over TCP, которое не является стандартным решением и при замере верхнего уровня в будущем будет накладывать серьёзные ограничения на выбор нового ПО. Так что напоследок придётся реализовать полноценную поддержку Modbus TCP в Вашей программе, в программе 7188. Придётся сделать полноценную поддержку Modbus TRU в 7188 и ещё модуль опроса платы расширения.

Вот так экономия копеечная на HW приводит к дикому раздуванию задания на SW.

Коллеги, решение на на i7188E + плата X107 + modbus-прошивка в данном случае получается очень простым. Смотрите каталог napdos\modbus\7188e\demo\bc\mt_x107\ на фирменном диске или на ftp.icpdas.com.

Код: Выделить всё

//user.c
/*
...
Memory mapping                                              

	    iMemory_DI[00]~[05]  <====>  X107 DI Ch0~Ch5 

	    iMemory_DO[00]~[06]  <====>  X107 DO Ch0~Ch6


...
*/

То есть, существует готовое приложение для контроллера (вариант упомянутого Mbt7_170), которое само опрашивает плату X107 и помещает результаты опроса в регистры Модбас. Достаточно залить в контроллер готовые mt_x107.exe и autoexec.bat. Далее можно опрашивать регистры Modbus устройства (команда Модбас 0x02 - Read Discrete Inputs) для получения состояния входов платы.

Вообще, библиотека Modbus, предлагаемая ICP DAS, несколько кривовата, но позволяет очень легко разрабатывать приложения на основе Modbus TCP (RTU). Суть в следующем (см. файлы в napdos\modbus\7188e\demo\bc\lib\):

Код: Выделить всё

//mbrtu.h

int InitModbus(unsigned char far *iPointer_DI, 

               unsigned char far *iPointer_DO,

                         int far *iPointer_AI,

                         int far *iPointer_AO);

    /*                                

    step 1. declare 4 global arrays

    step 2. give the 4 array pointers to InitModbus.

        For example:

            unsinged char far Array_DI[100];

            unsinged char far Array_DO[100];

                      int far Array_AI[100];

                      int far Array_AO[100];

            

            main()

            {

                InitModbus(Array_DI,Array_DO,Array_AI,Array_AO);

                

                //Giving initial values.

                Array_DI[0]=1;

                Array_DO[10]=0;

                Array_AI[5]=100;

                Array_AO[20]=-500;

                

                ....

                ....

            }

*/ 

То есть, вы просто объявляете несколько массивов и скармливаете их при инициализации функции InitModbus(). Далее Modbus TCP Master может читать элементы этих массивов как регистры Модбас. Все подробности - в комментариях указанного файла.

Именно так и реализовано приложение mt_x107 - функция ScanXboard() (вызываемая из циклической функции каркаса приложения UserLoopFun() ) опрашивает плату x107 и помещает состояния дискретных входов в массив iMemory_DI. Посмотрите код в napdos\modbus\7188e\demo\bc\mt_x107\user.c и вам все станет понятно. Поэтому, если даже вас по каким-то причинам не устроит функционал mt_x107.exe, вы легко сможете его модифицировать.