Надо переконфигурировать программу или Opc. Что у вас там установлено никто не угадает.
Вид для печати
Надо переконфигурировать программу или Opc. Что у вас там установлено никто не угадает.
Добрый день!
Столкнулся со следующей ситуацией. Последовательно отправляю в модем команды и проверяю ответ. Команды простые - AT, чтение/удаление/отправка сообщений. Очень часто, от модема ответа не получаю. Причем на команды, AT, AT+CMGL, AT+CMGD, на которую приходит ответ "OK", получаю в 90-95% случаев, то на AT+CMGS и собственно, результат самой отправки, в буфер ответ приходит в 20-30% случаев, хотя команды успешно проходят, что проверяю переподключением модема к терминалу, ну либо получением самого сообщения на телефон. Буфер же при этом остается девственно чист, хотя время задержки на чтение буфера поднимал до одной минуты. Скорость модема стоит на 115200, но сомневаюсь, что это может давать какое-либо влияние. Пробовал кучу вариантов и очисткой буфера после каждой команды и чтение буфера побайтно и десятки байт (хотя глупо, но уже варианты исчерпались). Ставил задержки между отправкой команды и чтением от нуля до десятков секунд. С чем это может быть связано? Может у кого то была похожая проблема?
Да и подключение использую RS-232 в связке с СПК107. На 485-м не тестировал, так как он будет занят другим соединением.
Появилась мысль: может быть так, что так как у меня запись команды и чтение происходит в разных циклах, то модем отвечает до того момента как плк начинает чтение буфера и , соответственно, теряет ответ? или это бред?
это Вы пишите про исползование библиотеки или самостоятельное творение?тут что имелось ввиду? надеюсь задержка это таймаут от отправки команды, после которого бесполезно ждать ответ, а не пауза после которой начинаете слушать ответЦитата:
Ставил задержки между отправкой команды и чтением
Самостоятельное творение (библиотеки то закрытые, внутрянку не увидишь), не нравилось как бибка работала, решил написать часть функциональности сам. Имелось ввиду таймаут, после которого бесполезно ждать ответ, так как чтение ответа в принципе начинаю сразу же после отправки команды (в следующем цикле). Доберусь до компа - скину код
Сначала я использовал пример с диска для обмена с модемом, когда понял, что есть проблемы, переработал программу
Но так как ответ на эти две команды обычно продолжительный, то при цикле в 10 мс, что-то потерять мне кажется нереально. Единственно, что думаю может буфер маловат (STRING(8)), но опять же на AT+CSMS ответ максимум 6 символов. В общем не знаю...Код:SMS_CMD_PDU:
otvet1:=''; len_otv:=0; //buf_otvet:='';
buf_cmd:=ADR(cmd_pdu); len_cmd:=LEN(cmd_pdu);
byte_wryte:=SysComWrite(modem_handle, buf_cmd, INT_TO_UDINT (len_cmd), 0, SysComRes);
IF byte_wryte=INT_TO_UDINT (len_cmd) THEN send_stat:=SMS_PDU; END_IF
SMS_PDU: //отправка команды на передачу сообщения (количество байт, передаваемых в формате pdu)
byte_read:=SysComRead(modem_handle, ADR(buf_otvet), 6, 0, SysComRes);
IF byte_read>0 THEN
otvet1:=CONCAT(otvet1, LEFT(buf_otvet, UDINT_TO_INT (byte_read)));
//otvet1:=buf_otvet;
len_otv:=LEN (otvet1);
IF (FIND(otvet1, otv_ready)>0) AND timer.ET > delay THEN //если ошибок нет, то можно обрабатывать принятую информацию и делать новый запрос
send_stat:=SMS_CMD_TXT; //то можно делать новый запрос
repead_count:=0; //сбрасываем количество повторов и обнуляем ответ
END_IF
END_IF
IF timer.ET > ojid1 THEN
repead_count:=repead_count+1; //считаем количество попыток
IF repead_count>repeads THEN //если все попытки исчерпаны
code_err:=3; //ошибка чтения сообщений
send_stat:=SMS_ERR; //в блок ошибки
ELSE
send_stat:=SMS_CMD_PDU; //повторяем попытку
END_IF
otvet1:='';
END_IF
SMS_CMD_TXT:
otvet2:=''; len_otv:=0;// buf_otvet:='';
buf_cmd:=ADR(cmd_txt); len_cmd:=LEN(cmd_txt);
byte_wryte:=SysComWrite(modem_handle, buf_cmd, INT_TO_UDINT (len_cmd), 0, SysComRes);
IF byte_wryte=INT_TO_UDINT (len_cmd) THEN send_stat:=SMS_TXT; END_IF
SMS_TXT: //отправка смс-сообщения
byte_read:=SysComRead(modem_handle, ADR(buf_otvet), 8, 0, SysComRes);
IF byte_read>0 THEN
otvet2:=CONCAT(otvet2, LEFT(buf_otvet, UDINT_TO_INT (byte_read)));
//otvet2:=buf_otvet;
//len_otv:=LEN (otvet2);
IF (FIND(otvet2, otv_sended)>0) AND timer.ET > delay THEN //если ошибок нет, то можно обрабатывать принятую информацию и делать новый запрос
send_stat:=SMS_DONE; //то можно делать новый запрос
repead_count:=0; //сбрасываем количество повторов и обнуляем ответ
ELSIF FIND(otvet2, otv_err)>0 AND timer.ET > delay THEN //если ошибка отправки, пытаемся выполнить повторно
send_stat:=SMS_CMD_RST;
END_IF
END_IF
IF timer.ET > ojid2 THEN
code_err:=4; //ошибка отправки сообщения
send_stat:=SMS_ERR; //в блок ошибки
otvet2:=''; //обнуляем ответ
END_IF
В итоге сделал тупо отправку без считывания подтверждения, работает отлично и с групповой отправкой (т.е. 3-4 сообщения подряд спокойно отправляется), но как то неправильно это
не проверял код на плк, но помоему Вы зря считаете что на ответы хватает 6-8 символов, там в некоторых командах идет куча скрытых символов типа перевода строки, поэтому ОК просто можете не захватывать. Ну и еще бы посоветовал полностью вычитывать приемный аппаратный буффер, а не фиксированное количество байт, возможно при повторной команде сперва выталкиваются остатки от предыдущих оттветов
Бибка для КДС 2.3 через UMD работать начинает как раз с минВЦ от 10мс, хотя для трешки может быть и на самом деле не принципиально
То же так кажется, увеличил, проверюЦитата:
но помоему Вы зря считаете что на ответы хватает 6-8 символов, там в некоторых командах идет куча скрытых символов типа перевода строки
Ммм... Что вы имеете ввиду? Да и команды все нормально проходят, с ними вроде как нет проблем. Про минВЦ в 2.3 знаю, в трешке вроде не писали ничего, да я и варьировал и 10 и 20 и 50, разницы не заметил.Цитата:
еще бы посоветовал полностью вычитывать приемный аппаратный буффер
Увеличение размера буфера и ответа решило проблему.