потеря байтов в ответной посылке с периодом 4-5 с.

[Смирнов Роман]

Уважаемые. Кто нибудь сталкивался с таким эффектом:
При чтении данных из 485 порта 4-5 секунд все нормально, затем начинают теряться первых один-два байта в течение 3-4 секунд. Причем этот период не зависит от установленной скорости обмена и времени цикла задач. пробовал цикл от 20 мс до 1 с. :mad: Похоже на биение частот приемника-передатчика
на линии все нормально. Пакеты идут все без ошибок.
Только есть один нюанс. Порт открыт постоянно так как слейв отвечает настолько быстро что при закрытии-открытии порта всегда теряется начало ответа. Можно ли очистить буфер порта по другому?

[Филоненко Владислав]

Потерь в буфере не может быть (его размер 512 байт).
А что вы имеете в виду под циклом? раз в 20 мс читаете из буфера? А почему так редко?
1. Какой протокол у Вас? Через сколько отвечает slave? Если за 100мкс и быстрее - возможны проблемы, т.к. прерывание RS в ПЛК не единственное.
2. Какой таймаут вы ставили при настройках порта?

[Смирнов Роман]

Здравствуйте, Владислав.
Протокол Тензо-М. Они как и почти все Российские производители изобрели свой протокол... Вот и приходиться писать.

Читаю раз в 20 мс постольку чаще нет смысла. Скорость АЦП макс 50 Гц. Данные выдает по запросу.

Формат запроса FF ADR COP CRC FF FF
Ответ FF ADR COP W0 W1 W2 CRC FF FF
W0,W1,W2- упакованный BCD
CRC тоже считают по своему алгоритму. полином 69H

Таймаут по умолчанию, но пробовал менять,- видимых результатов нет.
Пробовал делать разную структуру программы. Как в виде одной задачи, так и в виде нескольких независимых. Количество ошибок несколько меньше если имеется единственная задача.

А как собственно получить данные из буфера напрямую
напр sz:=SysComRead(com_handle,ADR(RD_BUFFER),16,0) Так?

Попробую посмотреть осциллографом интервал между запросом и ответом

[Смирнов Роман]

Уважаемые производители! Сделайте что-нибудь с Вашим 485 портом!:mad:
Подключив внешний конвертер 485/232 ошибки пропали напрочь.:)

[Филоненко Владислав]

уважаемый роман. зачем так кричать?
резистор терминальный в 485 есть? поставьте.

[Смирнов Роман]

так я ж не кричу. просто выделил.
ставил и 100 ом и 120 ом и 330 ом ...
бестолку.
да и работает все на столе длины кабеля 0,1-0,3м.
на расстоянии 10 см подключен I7563, которым смотрю линию.

[Смирнов Роман]

были бы помехи и отражения то ошибки были бы распределены более менее равномерно, а так имею чистый период повторения. как будто переключение прием передача программно организованы и все это накладывается в виде биений частот опрос задачи и пр. в итоге - то попали в окно то не попали...
на 232 работает вне зависимости от времени и количества задач, вот.

[Филоненко Владислав]

у меня на столе подключен мдвв, 100 опросов в секунду, сбоев нет вообще. и с др. приборами тоже. переключение происходит аппаратно,возможно проблема в другом? поэтому прошу, пришлите ваш проект, чтобы мы его опытным глазом просмотрели.

[richie]

Подниму тему, т.к. она наиболее близка к ситуации.
Клиент приобрел наш прибор, подключает его к ПЛК Овен по RS485.

В наших приборах мы используем свой протокол обмена, пакеты
начинаются 0xFF, заканчиваются 0x03. Причем 0xFF посылается с
гарантированной минимальной задержкой.

Наш (и Ваш) клиент написал какую-то программу на ПЛК-100, называет
ее "драйвер". Обратился с такой жалобой.
--------- Выдержка из письма клиента -----------------------------
"В ПЛК-100 медленный драйвер и быстро выданные байты через раз пропадают и очень трудно расшифрововать полезную информацию."
--------------------------------------------------------------------

При разговоре по телефону выяснилось, что при чтении ответа от прибора
функцией SysComRead() теряется либо первый символ пакета 0xFF, либо
большее колличество первых байтов пакета.

Разработчики ПЛК-100, пожалуйста, прокомметируйте ситуацию!
Заранее спасибо!
Андрей.

[Филоненко Владислав]

Трудно что-либо сказать, не видя кода "драйвера".

[richie]

Трудно что-либо сказать, не видя кода "драйвера".

;) Ну, что знал, то сказал. Кода драйвера сам не имею.
Отправил письмо клиенту со ссылкой на Ваш форум. Надеюсь, он появится в форуме.

[Разаренов Федор]

Да, действительно мы обнаружили в ПЛК100 и ПЛК150 проблему с портом RS485. Проблема состоит в том, что при посылке запроса на Slave-устройство из-за паразитных связей его часть может попасть в приемный буфер порта (причем ситуация нестабильна и проявляется не при каждой посылке). Из-за этого могут портиться или теряться первые 1-2 байта ответа Slave-устройства или наоборот к ответу добавляться в начале несколько бит или один байт.
Проблему можно решить аппаратной доработкой контроллера (необходимо допаять один резистор). Это можно сделать самостоятельно (материалы по доработке готовяться и будут скоро выложены на форуме) или обратившись в наш сервис-центр. Также мы в данный момент работаем над программным исправлением проблемы. Но здесь однозначного решения пока не найдено. О результатах также будет размещена информация на нашем сайте.
Приносим свои извинения.

[richie]

Да, действительно мы обнаружили в ПЛК100 и ПЛК150 проблему с портом RS485. Проблема состоит в том, что при посылке запроса на Slave-устройство из-за паразитных связей его часть может попасть в приемный буфер порта (причем ситуация нестабильна и проявляется не при каждой посылке). Из-за этого могут портиться или теряться первые 1-2 байта ответа Slave-устройства или наоборот к ответу добавляться в начале несколько бит или один байт.
Проблему можно решить аппаратной доработкой контроллера (необходимо допаять один резистор). Это можно сделать самостоятельно (материалы по доработке готовяться и будут скоро выложены на форуме) или обратившись в наш сервис-центр. Также мы в данный момент работаем над программным исправлением проблемы. Но здесь однозначного решения пока не найдено. О результатах также будет размещена информация на нашем сайте.
Приносим свои извинения.

Спасибо, за столь скорый и качественный ответ!
Моё уважение к качеству Вашей поддержки продуктов!

[Филоненко Владислав]

У клиента байты теряются. А тут "находятся". Дело явно не в этом. Ждем код.

[pms160]

Добрый день Владислав.

Беспокоит Вас Александр из Краснодара по совету
Андрея из МЕТРА г. Обниск.
В написанном мною драйвере для ПЛК-100 на языке CodeSys, который общается тензопреобразователем М0803 по RS485 пропадают первые
байты. Прчем количество пропущенных байт нестабильно от 2-х до 5-ти.
Пример драйвера приведен ниже.
Подскажите пожалуйста в чем тут может быть причина.
С уважением Александр.

PROGRAM PLC_PRG
VAR
(*УСТАВКИ ВО FLASH ПАМЯТИ*)
RETAIN

TAB_KS: ARRAY [0..255] OF BYTE := 16#00, 16#5E, 16#BC, 16#E2, 16#61, 16#3F, 16#DD, 16#83, 16#C2, 16#9C, 16#7E, 16#20, 16#A3, 16#FD, 16#1F, 16#41,
16#9D, 16#C3, 16#21, 16#7F, 16#FC, 16#A2, 16#40, 16#1E, 16#5F, 16#01, 16#E3, 16#BD,16#3E, 16#60, 16#82, 16#DC,
16#23, 16#7D, 16#9F, 16#C1, 16#42, 16#1C, 16#FE, 16#A0, 16#E1, 16#BF, 16#5D, 16#03, 16#80, 16#DE, 16#3C, 16#62,
16#BE, 16#E0, 16#02, 16#5C, 16#DF, 16#81, 16#63, 16#3D, 16#7C, 16#22, 16#C0, 16#9E, 16#1D, 16#43, 16#A1, 16#FF,
16#46, 16#18, 16#FA, 16#A4, 16#27, 16#79, 16#9B, 16#C5, 16#84, 16#DA, 16#38, 16#66, 16#E5, 16#BB, 16#59, 16#07,
16#DB, 16#85, 16#67, 16#39, 16#BA, 16#E4, 16#06, 16#58, 16#19, 16#47, 16#A5, 16#FB, 16#78, 16#26, 16#C4, 16#9A,
16#65, 16#3B, 16#D9, 16#87, 16#04, 16#5A, 16#B8, 16#E6, 16#A7, 16#F9, 16#1B, 16#45, 16#C6, 16#98, 16#7A, 16#24,
16#F8, 16#A6, 16#44, 16#1A, 16#99, 16#C7, 16#25, 16#7B, 16#3A, 16#64, 16#86, 16#D8, 16#5B, 16#05, 16#E7, 16#B9,
16#8C, 16#D2, 16#30, 16#6E, 16#ED, 16#B3, 16#51, 16#0F, 16#4E, 16#10, 16#F2, 16#AC, 16#2F, 16#71, 16#93, 16#CD,
16#11, 16#4F, 16#AD, 16#F3, 16#70, 16#2E, 16#CC, 16#92, 16#D3, 16#8D, 16#6F, 16#31, 16#B2, 16#EC, 16#0E, 16#50,
16#AF, 16#F1, 16#13, 16#4D, 16#CE, 16#90, 16#72, 16#2C, 16#6D, 16#33, 16#D1, 16#8F, 16#0C, 16#52, 16#B0, 16#EE,
16#32, 16#6C, 16#8E, 16#D0, 16#53, 16#0D, 16#EF, 16#B1, 16#F0, 16#AE, 16#4C, 16#12, 16#91, 16#CF, 16#2D, 16#73,
16#CA, 16#94, 16#76, 16#28, 16#AB, 16#F5, 16#17, 16#49, 16#08, 16#56, 16#B4, 16#EA, 16#69, 16#37, 16#D5, 16#8B,
16#57, 16#09, 16#EB, 16#B5, 16#36, 16#68, 16#8A, 16#D4, 16#95, 16#CB, 16#29, 16#77, 16#F4, 16#AA, 16#48, 16#16,
16#E9, 16#B7, 16#55, 16#0B, 16#88, 16#D6, 16#34, 16#6A, 16#2B, 16#75, 16#97, 16#C9, 16#4A, 16#14, 16#F6, 16#A8,
16#74, 16#2A, 16#C8, 16#96, 16#15, 16#4B, 16#A9, 16#F7, 16#B6, 16#E8, 16#0A, 16#54, 16#D7, 16#89, 16#6B, 16#35 ;
END_VAR

VAR
tOn1:TON;
start_tmr:BOOL:=FALSE;
tr1:R_TRIG;
scet3: TIME;

rcvbuf: ARRAY [0..128] OF BYTE; (* ПРИЕМНЫЙ БУФЕР *)
KS: BYTE;
SEND: ARRAY [0..128] OF BYTE;
INDEX: BYTE; (* ПЕРЕМЕННАЯ ДЛЯ ВЫЧИСЛЕНИЯ КОНТРОЛЬНОЙ СУММЫ *)
I: INT;
J: INT;
K: INT;
L: INT;
M: INT;
N: INT;
O: INT;
KOMAND: STRING:='TT';
NOMER_PRIB: BYTE; (* НОМЕР ПРИБОРА М0801-1 В СЕТИ *)

END_VAR


ton1(In:=start_tmr,pt:=t#450ms); (*ЗАПУСКАЕМ ИЗМЕРИТЕЛЬНЫЙ ТАЙМЕР *)
start_tmr:=TRUE;
tr1(clk:=ton1.Q);
SCET3:=ton1.ET;

IF tr1.Q THEN

NOMER_PRIB:=16#1B; (* ЗАДАЕМ НОМЕР ПРИБОРА М0801-4 - 0F *)
SEND[0]:=16#FF;
SEND[1]:=16#20+NOMER_PRIB;
SEND[2]:=16#20;
SEND[3]:=16#48; (*команда ВЫДАТЬ ВЕС *)
SEND[4]:=16#13; (*ПОДкоманда *)

(*РАСЧИТЫВАЕМ КОНТРОЛЬНУЮ СУММУ *)
KS:=0;
FOR I:=0 TO 4 BY 1 DO
INDEX:=TAB_KS[KS XOR SEND[I]];
KS:=INDEX;
END_FOR
SEND[5]:=KS;
SEND[6]:=16#03;

(*ОБНУЛЯЕМ БУФЕР ПРИЕМА ЧТОБЫ ЗНАТЬ ЧТО НЕ БЫЛО ДАННЫХ *)
FOR I:=0 TO 32 BY 1 DO
RCVBUF[I]:=0;
END_FOR

(* СОЕДИНЯЕМСЯ С ТЕНЗОПРЕОБРАЗОВАТЕЛЕМ М0801 ПО ПРОТОКОЛУ METRABUS* ВСЕ ИДЕТ НОРМАЛЬНО*)
SysComWrite(0,ADR(SEND),7,0);

sz:=SysComRead(0,ADR(rcvBUF),18,0); (* ЗДЕСЬ ТЕРЯЮТСЯ ПРИНЯТЫЕ БАЙТЫ ОТ 2-Х ДО 5-ТИ *)

start_tmr:=FALSE;
END_IF

[Филоненко Владислав]

Итак.
1.Идёт команда на запись и сразу команда на чтение. Странно, что он вообще что - то принимает - скорее это след. от предидущей посылки.
Все функции порта неблокирующие.
Раньше чем (время на посылку+время подготовки ответа прибором+время посылки ответа) ответа в приёмном буфере не будет.
2. Перед отправкой считывайте весь несчитанный мусор из приёмного буфера порта командой Read до результата==0.
3. Вы пытаетесь прочитать сразу 18 байт. Оптимизм - штука хорошая, но не в программировании. Читайте по 1. Анализируйте на начало пачки, складывайте сколько нужно байт в ответе, считайте CRC и только при выполнении всех условий - пачка ликвидна и идёт в анализ.

Кстати, использование п.3. с РЕЛИГИОЗНЫМ смирением и ФАНАТИЧНОЙ точностью гарантирует отсутствие проблем, описанных в п.1. и п.2.
Другого пути для RS-а лучшие умы планеты не придумали.

P.S. А зачем таблицу для CRC в retain засунули. Сделайте её CONST и всё.

[richie]

Дополню описанием протокола обмена Metrabus прибора М0803.
Протокольный уровень одинаков для М0801.
Александр использует приборы М0801 и подключает сейчас М0803 к ПЛК-100.

[Филоненко Владислав]

Вот наворотили. Дали студенту задание, наверное. Съэкономили. А людям мучайся.
А важных вещей нет. CRC для 256 байт слабая, числа байт в посылке нет (доп. проверка).

А к моему посту тут добавить нечего. Описанные выше проблемы к протоколу никакого отношения не имеют.

[pms160]

Трудно что-либо сказать, не видя кода "драйвера".
Кодд драйвера приведен ниже.
Поскажите в чем тут может быть ошибка.

PROGRAM PLC_PRG
VAR
(*УСТАВКИ ВО FLASH ПАМЯТИ*)
RETAIN

TAB_KS: ARRAY [0..255] OF BYTE := 16#00, 16#5E, 16#BC, 16#E2, 16#61, 16#3F, 16#DD, 16#83, 16#C2, 16#9C, 16#7E, 16#20, 16#A3, 16#FD, 16#1F, 16#41,
16#9D, 16#C3, 16#21, 16#7F, 16#FC, 16#A2, 16#40, 16#1E, 16#5F, 16#01, 16#E3, 16#BD,16#3E, 16#60, 16#82, 16#DC,
16#23, 16#7D, 16#9F, 16#C1, 16#42, 16#1C, 16#FE, 16#A0, 16#E1, 16#BF, 16#5D, 16#03, 16#80, 16#DE, 16#3C, 16#62,
16#BE, 16#E0, 16#02, 16#5C, 16#DF, 16#81, 16#63, 16#3D, 16#7C, 16#22, 16#C0, 16#9E, 16#1D, 16#43, 16#A1, 16#FF,
16#46, 16#18, 16#FA, 16#A4, 16#27, 16#79, 16#9B, 16#C5, 16#84, 16#DA, 16#38, 16#66, 16#E5, 16#BB, 16#59, 16#07,
16#DB, 16#85, 16#67, 16#39, 16#BA, 16#E4, 16#06, 16#58, 16#19, 16#47, 16#A5, 16#FB, 16#78, 16#26, 16#C4, 16#9A,
16#65, 16#3B, 16#D9, 16#87, 16#04, 16#5A, 16#B8, 16#E6, 16#A7, 16#F9, 16#1B, 16#45, 16#C6, 16#98, 16#7A, 16#24,
16#F8, 16#A6, 16#44, 16#1A, 16#99, 16#C7, 16#25, 16#7B, 16#3A, 16#64, 16#86, 16#D8, 16#5B, 16#05, 16#E7, 16#B9,
16#8C, 16#D2, 16#30, 16#6E, 16#ED, 16#B3, 16#51, 16#0F, 16#4E, 16#10, 16#F2, 16#AC, 16#2F, 16#71, 16#93, 16#CD,
16#11, 16#4F, 16#AD, 16#F3, 16#70, 16#2E, 16#CC, 16#92, 16#D3, 16#8D, 16#6F, 16#31, 16#B2, 16#EC, 16#0E, 16#50,
16#AF, 16#F1, 16#13, 16#4D, 16#CE, 16#90, 16#72, 16#2C, 16#6D, 16#33, 16#D1, 16#8F, 16#0C, 16#52, 16#B0, 16#EE,
16#32, 16#6C, 16#8E, 16#D0, 16#53, 16#0D, 16#EF, 16#B1, 16#F0, 16#AE, 16#4C, 16#12, 16#91, 16#CF, 16#2D, 16#73,
16#CA, 16#94, 16#76, 16#28, 16#AB, 16#F5, 16#17, 16#49, 16#08, 16#56, 16#B4, 16#EA, 16#69, 16#37, 16#D5, 16#8B,
16#57, 16#09, 16#EB, 16#B5, 16#36, 16#68, 16#8A, 16#D4, 16#95, 16#CB, 16#29, 16#77, 16#F4, 16#AA, 16#48, 16#16,
16#E9, 16#B7, 16#55, 16#0B, 16#88, 16#D6, 16#34, 16#6A, 16#2B, 16#75, 16#97, 16#C9, 16#4A, 16#14, 16#F6, 16#A8,
16#74, 16#2A, 16#C8, 16#96, 16#15, 16#4B, 16#A9, 16#F7, 16#B6, 16#E8, 16#0A, 16#54, 16#D7, 16#89, 16#6B, 16#35 ;
END_VAR

VAR
tOn1:TON;
start_tmr:BOOL:=FALSE;
tr1:R_TRIG;
scet3: TIME;

rcvbuf: ARRAY [0..128] OF BYTE; (* ПРИЕМНЫЙ БУФЕР *)
KS: BYTE;
SEND: ARRAY [0..128] OF BYTE;
INDEX: BYTE; (* ПЕРЕМЕННАЯ ДЛЯ ВЫЧИСЛЕНИЯ КОНТРОЛЬНОЙ СУММЫ *)
I: INT;
J: INT;
K: INT;
L: INT;
M: INT;
N: INT;
O: INT;
KOMAND: STRING:='TT';
NOMER_PRIB: BYTE; (* НОМЕР ПРИБОРА М0801-1 В СЕТИ *)

END_VAR


ton1(In:=start_tmr,pt:=t#450ms); (*ЗАПУСКАЕМ ИЗМЕРИТЕЛЬНЫЙ ТАЙМЕР *)
start_tmr:=TRUE;
tr1(clk:=ton1.Q);
SCET3:=ton1.ET;

IF tr1.Q THEN

NOMER_PRIB:=16#1B; (* ЗАДАЕМ НОМЕР ПРИБОРА М0801-4 - 0F *)
SEND[0]:=16#FF;
SEND[1]:=16#20+NOMER_PRIB;
SEND[2]:=16#20;
SEND[3]:=16#48; (*команда ВЫДАТЬ ВЕС *)
SEND[4]:=16#13; (*ПОДкоманда *)

(*РАСЧИТЫВАЕМ КОНТРОЛЬНУЮ СУММУ *)
KS:=0;
FOR I:=0 TO 4 BY 1 DO
INDEX:=TAB_KS[KS XOR SEND[I]];
KS:=INDEX;
END_FOR
SEND[5]:=KS;
SEND[6]:=16#03;

(*ОБНУЛЯЕМ БУФЕР ПРИЕМА ЧТОБЫ ЗНАТЬ ЧТО НЕ БЫЛО ДАННЫХ *)
FOR I:=0 TO 32 BY 1 DO
RCVBUF[I]:=0;
END_FOR

(* СОЕДИНЯЕМСЯ С ТЕНЗОПРЕОБРАЗОВАТЕЛЕМ М0801 ПО ПРОТОКОЛУ METRABUS* ВСЕ ИДЕТ НОРМАЛЬНО*)
SysComWrite(0,ADR(SEND),7,0);

sz:=SysComRead(0,ADR(rcvBUF),18,0); (* ЗДЕСЬ ТЕРЯЮТСЯ ПРИНЯТЫЕ БАЙТЫ ОТ 2-Х ДО 5-ТИ *)

start_tmr:=FALSE;
END_IF

[Филоненко Владислав]

Уважаемый pms160!
Вы посты не читаете? См. 4-ия постами выше.

[richie]

Вот наворотили. Дали студенту задание, наверное. Съэкономили. А людям мучайся.
А важных вещей нет. CRC для 256 байт слабая, числа байт в посылке нет (доп. проверка).

А к моему посту тут добавить нечего. Описанные выше проблемы к протоколу никакого отношения не имеют.

Как и многое другое, контрольная сумма CRC-8 "исторически сложилось".
Приходится тащить всё это дальше.

Вопрос: на чем съэкономили, из-за чего люди мучаются?
И каких вещей не хватает?
Сторонний взгляд, сами понимаете, лучше, а то иногда и "бревна в своем глазу не видно". :)

P.S. Потихоньку на modbus-rtu переходим...

[Филоненко Владислав]

Не хватает:
1. Числа байт (слов, регистров, чего-нибудь) в посылке - дополнительный контроль.
2. Признака запрос/ответ - доп. контроль + возможность прослушивать линию.
Лишнее:
1. Зачем сложные методы опроса. Кто их использует?
2. Зачем адрес источника
3. Очень сложная система команд. Как это поддерживать и реализовывать?
4. 7! вариантов адреса с разным поведением.
5. Смешались в кучу бинарный и символьный тип данных. Команды символьные, адреса бинарные, данные вообще смешение символов, бинарных данных и битовых полей.
6. Создаётся впечатление, что начали с простого протокола и потом добавляли и добавляли, пока он не умер под гнётом функционала. Это вообще можно протестировать и отладить?

[sc200457]

Да, действительно мы обнаружили в ПЛК100 и ПЛК150 проблему с портом RS485. Проблема состоит в том, что при посылке запроса на Slave-устройство из-за паразитных связей его часть может попасть в приемный буфер порта (причем ситуация нестабильна и проявляется не при каждой посылке). Из-за этого могут портиться или теряться первые 1-2 байта ответа Slave-устройства или наоборот к ответу добавляться в начале несколько бит или один байт.
Проблему можно решить аппаратной доработкой контроллера (необходимо допаять один резистор). Это можно сделать самостоятельно (материалы по доработке готовяться и будут скоро выложены на форуме) или обратившись в наш сервис-центр. Также мы в данный момент работаем над программным исправлением проблемы. Но здесь однозначного решения пока не найдено. О результатах также будет размещена информация на нашем сайте.
Приносим свои извинения.

Забыли поставить подтягивающий резистор на выход приемника с линии RS485. При передаче в линию RS485 неопределенное состояние с этого выхода может давать ложные принятые байты. Надо резистор 2,4 ком между 1 и 8 ножками микросхемы ADM485

[Малышев Олег]

В данном случае проблема потери байт не от неправильной схемотехники а от ошибки
(* СОЕДИНЯЕМСЯ С ТЕНЗОПРЕОБРАЗОВАТЕЛЕМ М0801 ПО ПРОТОКОЛУ METRABUS* ВСЕ ИДЕТ НОРМАЛЬНО*)
SysComWrite(0,ADR(SEND),7,0);

sz:=SysComRead(0,ADR(rcvBUF),18,0); (* ЗДЕСЬ ТЕРЯЮТСЯ ПРИНЯТЫЕ БАЙТЫ ОТ 2-Х ДО 5-ТИ *)

Нельзя в туже микросекунду ждать ответа от прибора -SysCom функции НЕБЛОКИРУЮЩИЕ - мгновенно возвращают управление. Ждите ответа через N мс. Для этого заведите отдельный таймер

[sc200457]

В данном случае проблема потери байт не от неправильной схемотехники а от ошибки
(* СОЕДИНЯЕМСЯ С ТЕНЗОПРЕОБРАЗОВАТЕЛЕМ М0801 ПО ПРОТОКОЛУ METRABUS* ВСЕ ИДЕТ НОРМАЛЬНО*)
SysComWrite(0,ADR(SEND),7,0);

sz:=SysComRead(0,ADR(rcvBUF),18,0); (* ЗДЕСЬ ТЕРЯЮТСЯ ПРИНЯТЫЕ БАЙТЫ ОТ 2-Х ДО 5-ТИ *)

Нельзя в туже микросекунду ждать ответа от прибора -SysCom функции НЕБЛОКИРУЮЩИЕ - мгновенно возвращают управление. Ждите ответа через N мс. Для этого заведите отдельный таймер

Функции работают по прерыванию от USART в фоновом режиме?

[Филоненко Владислав]

Да, есть буфер приёма и буфер передачи. И прерывания USART. Всё для удобства клиента:)

[Разаренов Федор]

Проблему можно решить аппаратной доработкой контроллера (необходимо допаять один резистор). Это можно сделать самостоятельно (материалы по доработке готовяться и будут скоро выложены на форуме) или обратившись в наш сервис-центр.

Размещаю информацию о схемотехнической доработке RS485 в ПЛК100, ПЛК150. Смотрите прикрепленный файл.

[richie]

Федор, что-то немного не скачивается...
Все время просит авторизации, хотя форум вроде бы меня узнал.

[vojt]

В этой теме я кажется нашел ответы на мои вопросы. У меня похожий протокол обмена с весовым индикаторм СІ5010A (CAS). И тоже самое происходило с ответом. C библиотекой UNM я как-то добился правильного приема, но он был очень громоздким. Следуя рекомендациям в этой теме, я добился правильного приема с библ. SysLibCom и примером Example_SysLibCom с форума. Действительно нужно поставить таймер после передачи команды и перед приемом ответа, я поставил 100 мс.
С 485 у меня тоже какие-то глюки, как-то ни сразу идет нормальный обмен. Поэтому попробую сделать переделку по методике Федора. Пример пока еще очень сырой, когда доработаю могу выслать.

[pms160]

Здравствуйте Владислав !!

Беспокоит Вас Александр из Краснодара. У меня возник еще один вопрос.
Может быть Вы смогли помочь !
Мне нужно подключить к ПЛК-100 6 счетчиков СИ8 по RS485, а ПЛК-100 к компьютеру. Всвязи с этим возник вопрос как лучше подключить ПЛК-100
к компьютеру - по RS485 или Ethernet. Возможно ли сделать ПЛК-100
на одной линии RS485 и ведущим по отношению к СИ8 и ведомым по отношению к компьютеру.
А в библиотеках CodeSys я не нашел команд работающих с Ethernet.
Не подскажите где можно найти команды работающие с Ethernet.
Ведь физически интерфейс есть. Кроме того имеются ли драйверы
для компьютера на Delphi принимающие данные с Ethernet лнии.

С уважением Александр.

[Малышев Олег]

1) Для передачи данных из /в контроллер используйте готовое решение. Например протокол МодбасTCP/CoDeSys Gatway для Ethernet или owen_io.dll/modbus OPC/owen OPC для RS485
2) Два мастера на сети не очень хорошо (придется организовывать передачу метки) - можно использовать режим "прослушивания" линии - реализовано для owen opc и owen_io.dll - наверное самый легкий путь
3) Для ethernet - через Codesys Gateway ищем OPC Для Delphi - или смотрим пример для OPC owen (сейчас в состав не входит - но по запросу можно получить)+ смотрим на диске ПЛК конфигурирование OPC сервера. Через модбас TCP - конфигурируем в PLC_configuratio Modbus (TCP) слейв и ищем библиотеку для работы со слейвом мобас.
4) Тяжелый путь - вручную программируем сокеты или RS485 через SysLibSockets или SysLibCom

[pms160]

pms160
pf,kelbkcz

[richie]

Господа, Овенцы!
Сегодня звонил в Вашу службу тех. поддержки.
Задал вопрос про задержку от момента передачи до приема, сославшись
на SysComWrite и SysComRead.
К сожалению, не представившийся товарищ сказал, что задержка не
описана в документации, но она есть и равна примерно 2 миллисекунды!

За это время мой прибор на 115200, с частотой 400 Гц генерации значений успеет практически всю посылку целиком запихать в порт.

А народ долго-долго "ловит блох" в своих программах под ПЛКшки. :)

Это беда ПЛК-100/150 или из CodeSys наследуется?
А с Modbus-RTU такая же неприятность будет?

[Филоненко Владислав]

Да, задержка есть и обусловлена необходимостью выдержать паузу 3,5 символа между пачками по стандарту RTU. На скорости 115200 пауза составляет 0,347 мс.

[richie]

Да, задержка есть и обусловлена необходимостью выдержать паузу 3,5 символа между пачками по стандарту RTU. На скорости 115200 пауза составляет 0,347 мс.

Пауза 3,5 байта в Modbus-RTU регламентирована спецификацией протокола. И является признаком конца пакета.

Я имел в виду, нет ли в ПЛК бяки когда я, получив пакет (концом считаю
тишину в линии длиной 3,5 байта), начинаю выдавать ответ, но "слишком
рано", чтобы ПЛК успел принять пакет?

[Филоненко Владислав]

Можно подробнее. Как посылаете запрос/принимаете ответ?
Пример кода? Описание опрашиваемого прибора?

[pms160]

Информация для Малышева Олега от pms160.
Огромное спасибо за краткое объяснение программирования Ethernet
для ПЛК-100.
У нас возник еще один вопрос, на который хотелось получить
подсказку. Мы хотим в ПЛК-100 привязаться к реальному времени.
Мы в окне переменных указали переменную:
VAR
DATA: DT;
END_VAR

А в окне программ указали строку
DATA:=DT#;

Однако CodeSys при компиляции указывает на ошибку в этой стороке :
Invalid date and time
Не подскажите в чет тут может быть ошибка.
С уважением Александр.

[Филоненко Владислав]

а где сама дата-то?

[Малышев Олег]

Для чтения записи часов реального времени используйте библиотеку SysLibTime.lib она читает/пишет данные RTC - поиск по данному форуму позволит найти формат обращения к данной библиотеке.

[Kirill]

посмотрите это описание бибилиотеки.
1156

[pms160]

От pms160.

Огромное спасибо за SysLibTime.
У нас возник еще один вопрос.
Входа ПЛК-100 мы собираемся использовать
как входы счетчиков. Период изменения
сигнала порядка 500мс, а скважность
порядка 200мс. Чтобы не пропустить
импульсы хотелось обрабатывать их по
прерыванию. Имеется ли в CodeSys
такая функция обнаружения фронта
на каком либо одном входе по прерыванию.

С уважением Александр.

[pms160]

Еще вопрос от pms160ю

Нам нужно организовать запись в энергонезависимую память
ПЛК-100. Причем данные будут перезаписываться часто - раз в 10сек.
Не подскажите где лучше разместить соответствующие
переменные. В паспорте ПЛК написано, что Flash память допускает
50000 перезаписей. На сколько я понимаю Retain память это flash
VAR
Ratain
schetchik_1: int;
END_VAR
Где лучше разместить переменную schetchik_1: ?

С уважением Александр.

[Малышев Олег]

Если стандартный цикл ПЛК -1 мс нормально - зачем прерывания, если на входах все же 500 мкс и 200мкс заведите на вход модуль счетчик(PLC Configuration) - не потеряете импульсов. Если нужна реакция на 500 мкс - вполне подойдет Task во FreeWeeling - до 4 кГц

[pms160]

Здравствуйте.
Беспокоит pms160.
У нас возник еще один вопрос на который хотелось услышать подсказуц.
Я слышал, что в библиотеки CodeSys Standart имеется флаг Power, который взводится пока питание подано на ПЛК и падает как только
питание пропадает. Но в своей библиотеки я не нашел такого флага и у меня нет описания библиотеки Standart.
Не поможете получить эту информацию.

С уважением Александр.

[Филоненко Владислав]

Не совсем верно.
Данный параметр появляется при добавлении модуля Statistic в конфигурации ПЛК. Как добавить описано в документации по PLC Configuration.
Библиотека Standard.lib описана как в Help в CoDeSys, так и на диске есть описание