Просмотр полной версии : ПЛК63 + SysLibCom, потеря байтов
Симптомы - при чтении из "порта" кол-ва байт меньше чем находится в буфере.
Например в буфере 10 байт,
SysComRead( port, ADR( dest ), 10, 0 ) -> 10
все хорошо,
SysComRead( port, ADR( dest ), 16, 0 ) -> 10
все хорошо, а
SysComRead( port, ADR( dest1 ), 5, 0 ) -> 5
SysComRead( port, ADR( dest2 ), 5, 0 ) -> 4
причем теряется шестой байт.
НА ПЛК100 ВСЕ РАБОТАЕТ !!! Следовательно проблема не в кривой ПРОГРАММЕ, не в кабельном соединении а именно в ( ПЛК63 + SysLibCom )
Выкладываю примеры, где можно увидеть данную проблему.
БЫЛО БЫ ОЧЕНЬ ЗДОРОВО, ЕСЛИ ПРЕДСТАВИТЕЛИ "ОВЕН" ОТПИСАЛИСЬ БЫ ПО ДАННОЙ ТЕМЕ.
P.S. Разница между xxxmaster1 и xxxmaster2:
xxxmaster1 - чтение ответа в одном цикле
xxxmaster2 - чтение ответа "разнесено" по циклам
О примерах.
В примерах организован обмен данными по протоколу modbus через rs485.
plc63master-plc100slave
ПЛК100 - modbus slave, через "PLC Конфигуратор" ( plc100slave.pro )
ПЛК63 - modbus master ( plc63master.pro ), отправка запросов и чтение ответов через SysLibCom. Запрос - константа "REQUEST", ожидаемый ответ - константа "RESPONSE". Ответ от slave "складывается" в part1 и part2.
Eсли ( FIRST_PART_SIZE = 0 ) или ( FIRST_PART_SIZE = RESPONSE_SIZE ), то " все хорошо ", иначе " потеря данных "
plc100master-plc63slave
ПЛК63 - modbus slave, через "PLC Конфигуратор" ( plc63slave.pro )
ПЛК100 - modbus master( plc100master.pro ), отправка запросов и чтение ответов через SysLibCom.
Это было сделано, для того, чтобы показать - на ПЛК100 + SysLibCom работает нормально.
Техподдержка отпишитесь, пожалуйста. Проект встал на этапе выбора контроллера: ПЛК63, ПЛК100+ИП320, или панельный контроллер другого производителя. Просто надо будет налаживать обмен по нестандартным протоколам и если на ПЛК63 SysLibCom нормально работать не будет, то будем рассматривать другие варианты, а не ковыряться с этой проблемой.
Филоненко Владислав
19.03.2012, 21:35
Крайне непонятный код. Постоянно какие-то смещения в разных массивах. Зачем все это?
А просто 2 подряд чтения без всех этих состояний работает? Без реального прибора сэмулировать только на 1 ПЛК63 не получится.
Крайне непонятный код. Постоянно какие-то смещения в разных массивах. Зачем все это?
А просто 2 подряд чтения без всех этих состояний работает? Без реального прибора сэмулировать только на 1 ПЛК63 не получится.
Не по существу.
Берем 2 контроллера, соединяем их по rs485, заливаем в ПЛК100 - plc100slave.pro, запускаем, отключаемся. Заливаем в ПЛК63 plc63master.pro, делаем breakpoint на 52-ой строчке и следим за переменными resultOfRead, part1, part2. Чтение ответа от устройства специально разбито на две части. Размеры частей задается константой FIRST_PART_SIZE. Если ( FIRST_PART_SIZE = 0 ) или ( FIRST_PART_SIZE >= 0 ), то "ответ" будет читаться одним куском.
Может у меня просто контроллер неисправный, или мозги, или это болезнь всех ПЛК63.
В случае с мозгами, пожалуйста, скажите где ошибка в коде.
Берем 2 контроллера, соединяем их по rs485, заливаем в ПЛК100 - plc100slave.pro, запускаем, отключаемся. Заливаем в ПЛК63 plc63master.pro, делаем breakpoint на 52-ой строчке и следим за переменными resultOfRead, part1, part2. Чтение ответа от устройства специально разбито на две части. Размеры частей задается константой FIRST_PART_SIZE. Если ( FIRST_PART_SIZE = 0 ) или ( FIRST_PART_SIZE >= 0 ), то "ответ" будет читаться одним куском.
Если ( FIRST_PART_SIZE = 0 ) или ( FIRST_PART_SIZE >= RESPONSE_SIZE ), то "ответ" будет читаться одним куском.
Малышев Олег
20.03.2012, 10:45
на вскидку попробуйте поставить вместо
SysComRead( port, ADR( part1[ counter ] ), firstPartSize - counter + 1, 0 );
код
SysComRead( port, ADR( part1[ counter ] ), (firstPartSize - counter) + 1, 0 );
это все таки Паскаль на не C
может я и ошибаюсь
на вскидку попробуйте поставить вместо
SysComRead( port, ADR( part1[ counter ] ), firstPartSize - counter + 1, 0 );
код
SysComRead( port, ADR( part1[ counter ] ), (firstPartSize - counter) + 1, 0 );
это все таки Паскаль на не C
может я и ошибаюсь
"Грешно смеяться над больными людьми"
Я извиняюсь, если некорректно выразился. Под "больными людьми" я имел ввиду СЕБЯ и своих коллег. Просто данный совет мне показался несколько неконструктивным.
a - b + 1 -> ( a - b ) + 1 ...
Следующий совет : a - b + 1 -> 1 + ( a - b )... и тд. по всему коду. Так можно и 2 года " экспериментировать ".
Данная тема была создана в расчете на техподдержку "Овен". У них наверняка под рукой есть два контроллера. Поэтому и использовались 2 "овеновских" плк. И писал две группы примеров, когда ПЛК63 мастер, и ПЛК100 мастер, для сравнения.
63 регулярно делаю мастером. Проблем не имею.
Есть биб-ка modbus.lib. Она рабочая. Исходник открыт. Изучайте.
А где можно найти исходник?
Извиняюсь за свой предыдущий глупый вопрос.
В Modbus.lib читают одним блоком в
rBuf: ARRAY[0..511] OF BYTE;
....
Size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf), SIZEOF(rBuf), 0));
а меня интересует извлечение и буфера по частям
С Modbus.lib у меня тоже вроде никогда проблем не было
И все таки я жду ответа от официальной техподдержки.
Может зря...
И все таки я жду ответа от официальной техподдержки.
Может зря...
как минимум уже двое высказалось :)
Малышев Олег
20.03.2012, 15:13
К сожалению, сотрудник, ответственный за ПЛК 63/73 сейчас приболел. А насчет двух 63 - вы не поверите :) но лично у меня их нет сейчас.
Понятно.
Просто хотелось получить конструктивный ответ:
- ты дурак, и программа у тебя дурацкая ( + пояснения )
- не та прошивка ПЛК, не та версия SysLibCom ( есть более новая, ну вдруг.. ) и т.д.
- бракованный ПЛК, попробуйте другой
- это болезнь ПЛК63, не заморачивайся
Там вообще-то ПЛК100 и ПЛК63, но это наверно не важно
если речь идет не о модбас, попробуйте бибку UNM, вроде её рекомендуют http://www.owen.ru/forum/showthread.php?t=11279
и еще вопросик, а для какой цели между двумя плк одного производителя использовать нестандартную передачу данных?
Все пропала тема.
В проекте требуется наладить обмен данными с устройством ( счетчик ) по нестандартному протоколу. Раньше использовали ( ПЛК100 + ИП320 ). Теперь вдруг захотелось ПЛК63 ( не мне.... ). Начал переделывать под ПЛК63 и смотрю, что-то как-то все очень плохо работает. Два дня капался пока не "локализовал" неисправность.
Эти примеры не часть моей программы, я их специально написал для форума. Жду конструктивного ответа.
( ПЛК100 + ИП320 ) - не понравилось потому что, имел место такой дефект: периодическая потеря связи между ПЛК100 и ИП320 по RS232. Причем разъем чуть, чуть пошевелишь связь восстанавливается. Кабель меняли, результат тот же. В ПЛК DB9 даже визуально стоит "криво". Разбирали, пропаивали, результат тот же. Наша статистика 2 таких брака из 10.
+ ПЛК63 дешевле чем ( ПЛК100 + ИП320 ).
Хотели еще ПЛК73 попробовать, но теперь я боюсь его заказывать. Начальство может не понять
Два овеновских ПЛК были использованы, чтобы нельзя было все свалить на другого производителя
незнаю насчет потерь байтов, у меня наоборот на симуляторе слейва проскакивает два запроса подряд, потому что пересылка одним махом через SysComWrite не дает требуемых пауз между пересылками
Естественно.
Но почему ЧТЕНИЕ ответа блоками глючит ???
КТО-НИБУДЬ МОИ ПРИМЕРЫ НА " ЖЕЛЕЗЕ " ПРОБОВАЛ ???
"Если интервал тишины продолжительностью 1,5 возник во время передачи фрейма, принимающее устройство должно игнорировать этот фрейм как неполный"
В Вашем нестандартном протоколе есть понятие интервал тишины?
Я не работаю с портом напрямую, а через буфер. И интервалами между битами управлять не могу.
Про интервалы между кадрами
1. очищаю буфер порта
2. пихаю целиком запрос через SysWriteCom
3. пауза ( 100ms )
4. читает ответ
5. пауза ( 100ms )
6. переход на 1.
Если ( FIRST_PART_SIZE = 0 ) или ( FIRST_PART_SIZE >= RESPONSE_SIZE ), то "ответ" будет читаться одним куском и ошибок нет.
Дело-то как раз в чтении ответа по частям
SysComRead(ComHandle, ADR(rBuf), SIZEOF(rBuf), 0) не пробовали нолик заменить на другое значение и всетаки приемный буфер читать не прерывно, через операцию WHILE
capzap, если честно, смотрел примеры?
Все это пробовал... Я этим 2 дня сидел, уже много чего попробовал
Интересная техподдержка у Овена. Попробуй то, попробуй сё.
Я примеры прислал, а никто их так не посмотрел толком.
Ладно, если завтра ответа не будет, то будем искать что-то другое.
Проблему с чтением ответа по частям конечно можно обойти, но очень уж не хочется ставить на объект глючный контроллер. Мало-ли что еще вылезет.
Все спасибо за участие
глючный контроллер.
Код. Раз не работает.
Замороченный, особенно с таймерами. Вы хотите чтоб с этим разбирались ?
Ладно Вам дуться, я по десять раз проверяю проект, а трехгодовалый ребенок подходит и набирает комбинацию клавиш и выскакивает какой нибудь глюк, несуществует в природе понятия все проверил, всегда можно что то упустить
Код. Раз не работает.
Замороченный, особенно с таймерами. Вы хотите чтоб с этим разбирались ?
Что именно, не работает:
1. открытие порта
2. настройка порта
3. отправка запроса
4. чтение ответа
что?
Функции для работы с таймером специально написал, что не засорять код, а привлечь внимание к главной проблеме.
И да, я хочу чтобы Вы разбирались. Мне же пришлось с этим разбираться. У меня были готовые "либы" для работы с определенными устройствами на ПЛК100. Тот же самый код очень глючит на ПЛК63.
Я же не просто написал, что "у меня программа глючит, и теряет где-то байты". Я не поленился и написал примеры, где эту проблему можно обнаружить. И чет мне не вериться, что техподдержка Овена не может найти ПЛК100 и ПЛК63, чтобы этот пример проверить. Понимаю, что влом, но у каждого своя работа.
Кто-нибудь пробовал примеры на "железе"??? Никто ни одного конструктивного вопроса по программе не задал.
Если у Вас есть примеры, где ответ от какого-то устройства читается частями, и все работает, то был очень признателен его получить.
1.У меня все работает
2.Про исходник modbus.lib говорил. Хотя я и её не использую - только syslibcom. Но modbus.lib рабочая - изучайте
3.Я использую групповые запросы везде где это возможно в принципе
4.Делая 63-ого мастером, и опрашивая, например МВА8 - размер ответа 101 байт. СП270 читал/писал блоками по 50..100 байт. ПЛК110-60 слейв - чисто попробывал - 248 байт (Почему-то 250 не шмог :( )
5.Я до сих пор не понимаю акцента на слове "частями"
Всё что в п.4 я никогда и не пытался сделать в одном цикле. Зачем ?
6.Так работая с таймерами вы только за..ли код и моск
7.Ну накой вам чётность ? Краткое описание Вашего нестандартного протокола ? Там нет похожего на контрольную сумму ?
8.Не забывайте что ПЛК100 слейв отвечает в рамках modbus(RTU)
И ровно в этих рамках надо ловить ответ. См. Википедию
9.У Вас с этого ПЛК modbus.lib работает ?
10. Пример - см. п.2
В Modbus.lib читают одним блоком в
rBuf: ARRAY[0..511] OF BYTE;
....
Size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf), SIZEOF(rBuf), 0));
Это я у же писал. Что еще изучать по данной теме в modbus.lib я не знаю.
Это ни нестандартный протокол а modbus rtu. Суммы там правильные:
REQUEST : ARRAY [ 1..REQUEST_SIZE ] OF BYTE := 16#10, 16#04, 16#00, 16#00, 16#00, 16#04, 16#F2, 16#88;
16- адрес устройства
04 - код функции
00, 00 - адрес первого регистра
00,04 - кол-во регистров
crc - 88F2
Если под рукой нет программы для подсчета crc,
http://www.lammertbies.nl/comm/info/crc-calculation.html
а по поводу "частями", пожалуйста почитайте самый первый пост.
Если у Вас есть примеры обмена данными для ( ПЛК63 + SysLibCom ), буду очень признателен их увидеть.
К функциональности modbus.lib никаких вопросов. Но меня он в данном случае не интересует. Для обмена данными этот протокол был выбран только потому, что он есть в PLC Конфигураторе, а протоколе ОВЕН мне разбираться лень........
В Modbus.lib читают одним блоком в
В разные циклы читают последовательные куски одного блока
Еще раз
Симптомы - при чтении из "порта" кол-ва байт меньше чем находится в буфере.
Например в буфере 10 байт,
SysComRead( port, ADR( dest ), 10, 0 ) -> 10
все хорошо,
SysComRead( port, ADR( dest ), 16, 0 ) -> 10
все хорошо, а
SysComRead( port, ADR( dest1 ), 5, 0 ) -> 5
SysComRead( port, ADR( dest2 ), 5, 0 ) -> 4
причем теряется шестой байт.
я не говорю SysLibCom в ПЛК63 вообще не работает. Я прошу пояснить именно ЭТУ проблему.
Пытаться прочитать весь ответ в одном цикле конечно не стоит, особенно если он несколько сот бай.
Раз уж я взял modbus rtu. Можно так:
resultOfRead : DWORD;
buffer : array [ 0..255 ] of byte;
....
resultOfRead := SysComRead( port, adr( buffer ), sizeof( buffer ), 0 );
" перекладываем из буфера в контейнер ответа"
И это будет работать, потому что из буфера "заберут" все содержимое.
По протоколу ответ не может превышать 256 байт.
А если из буфера порта забрать меньше его содержимого, то происходит ПОТЕРЯ ДАННЫХ.
Ладно пора спать. Я наверно фигова объясняю
И это будет работать, потому что из буфера "заберут" все содержимое.
По протоколу ответ не может превышать 256 байт.
А если из буфера порта забрать меньше его содержимого, то происходит ПОТЕРЯ ДАННЫХ.
Я в разных циклах в один буфер читаю куски большого блока последовательно укладывая их, ничего оттуда не беру до признака окончания. И ничего не теряю
В modbus.lib сделано практически тоже самое.
У Вас теряется - см пост.19 ответ 1 (часть б)
См. исходник modbus.lib
Вдумайтесь
А если из буфера порта забрать меньше его содержимого, то происходит ПОТЕРЯ ДАННЫХ.
Я всегда недоедаю котлету. Я требую объяснить почему я голодный ?
Валенок, пожалуйста приведи фрагмент кода чтения ответа, только с определениями переменных. Дался тебе ентот modbus.lib. Ты свой рабочий код покажи.
P.S. Вы в Овене работаете?
Просто я говорю " глючит " и выкладываю пример. Вы говорите все работает и примера не даете. А modbus.lib не в счет.
На форуме есть уже несколько тем с очень похожим содержанием, без ответа почему теряются байты.
См. исходник modbus.lib
Вдумайтесь
Я всегда недоедаю котлету. Я требую объяснить почему я голодный ?
Это сарказм?
Исходник не дам. Разве только пример с закрытой б-кой. Хотя примеры-выкладывал. В Овене не работаю - можете справится у них.
А что вы так против модбаса.либа - я вот его по косточкам разобрал, википедию почитал - и свой мастер сделал.
Это сарказм?
Зачем забирать меньше чем там есть ? :confused:
Исходник не дам. Разве только пример с закрытой б-кой. Хотя примеры-выкладывал. В Овене не работаю - можете справится у них.
А что вы так против модбаса.либа - я вот его по косточкам разобрал, википедию почитал - и свой мастер сделал.
Я не против modbus.lib, прото мне сейчас не нужен. В проекте нужно сделать обмен с устройством по нестандартному протоколу. Modbus rtu использовал просто для примера. Если я сказал, что глючит обмен между ПЛК63 и шнайдеровским счетчиком, меня в техподдержке с ходу в сад послали. А так обмен между двумя овеновскими плк по modbus. Типа не отвертятся. Но ошибался. Кто-то заболел, контроллеров у них нет и т.д.
Очень кратко - тот протокол как выглядит ?
Зачем забирать меньше чем там есть ? :confused:
1. Очищает буфер порта
2. Посылаем запрос
3. пауза
4. Читаем 10 байт из буфера порта
5. Если прочитанное "правельное", то
Если прочитан весь ответ, то (6)
иначе 4
иначе 6
7. пауза
8. на 1
я ответ читаю порциями.
Очень кратко - тот протокол как выглядит ?
Какой протокол?
Я посылал запросы и ожидал ответов в формате modbus rtu
REQUEST : ARRAY [ 1..REQUEST_SIZE ] OF BYTE := 16#10, 16#04, 16#00, 16#00, 16#00, 16#04, 16#F2, 16#88;
16- адрес устройства
04 - код функции
00, 00 - адрес первого регистра
00,04 - кол-во регистров
crc - 88F2
Если под рукой нет программы для подсчета crc,
http://www.lammertbies.nl/comm/info/...lculation.html
счетчик я обсуждать не буду
1. Очищает буфер порта
2. Посылаем запрос
3. пауза
4. Читаем 10 байт из буфера порта
5. Если прочитанное "правельное", то
Если прочитан весь ответ, то (6)
иначе 4
иначе 6
7. пауза
8. на 1
я ответ читаю порциями.
блин хигню написал, ночь уже
1.Отправили, взвели таймер
2.Читаем.Что-то есть - перевзводим таймер. время вышло - выходим на проверку данных
PS
А счетчик есть и в modbus.lib
И я про тот, другой, протокол спрашивал
Паузы - в сад
шнайдеровский счетчик в сад. Здесь я его обсуждать не хочу. Не та тема.
Пойми из буфера порта читаю небольшими порциями. Да можно при чтении запросить макс. возможное для данного протокола количество байт из буфера. И проблема пропадет. НО почему теряются байты при чтении ответа из буфера частями. На ПЛК100 работает на ПЛК63 - глючит. А на еще каком-нибуть ПЛКxxx, будет другой глюк.
Меня не интересует, как можно сделать по другому. Я знаю как сделать. Меня интересует имено ентот глюк.
Вы попробуйте, если не влом конечно, и есть возможность заменить
Size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf), SIZEOF(rBuf), 0));
на
Size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf), SIZEOF(rBuf), 0));
if ( size > 0 ) then
size := size + DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf[ 1 ]), SIZEOF(rBuf) - 1, 0));
end_if
Вы попробуйте, если не влом конечно, и есть возможность заменить
Size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf), SIZEOF(rBuf), 0));
на
Size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf), SIZEOF(rBuf), 0));
if ( size > 0 ) then
size := size + DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf[ 1 ]), SIZEOF(rBuf) - 1, 0));
end_if
ошибся
Size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf), 1, 0));
if ( size > 0 ) then
size := size + DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf[ 1 ]), SIZEOF(rBuf) - 1, 0));
end_if
когда читаете - знаете сколько прочитали. Ну за каким читать меньше или больше ?
PS
Все. Спокойной ночи.
ошибся
Size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf), 1, 0));
if ( size > 0 ) then
size := size + DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf[ 1 ]), SIZEOF(rBuf) - 1, 0));
end_if
Вы хорошо подумали когда это написали ?
PS
Все. Утро вечера - сами знаете ..
Допустим в буфере появился "мусор" ( каким образом, даже думать не хочу ). Читаем 100 байт, первые 10 "мусор", а дальше идет верный ответ от устройства. Т.е. надо дочитать ответ. Читаем недостающие байты. И тут облом. Теряются байты.
Вот зачем
Вы хорошо подумали когда это написали ?
PS
Все. Утро вечера - сами знаете ..
Можно подробно.
Спокойной ночи
в место единицы видимо Size должны были написать
Блин, уже жалею, что ПЛК63 на объекте, и раньше, чем через пару недель туда не доберусь. Очень интересно было бы проверить теорию "шестого байта"...
А нет ограничений на то, что в одном цикле должна быть только одна команда SysComRead? Или это требование относилось к тому, что в одном цикле или SysComRead, или SysComWrite... Или я что-то путаю, и такого совсем нет...
Жалко, нет функции, которая сказала бы количество байт, доступных для чтения... Хотя всё равно не спасло бы - где гарантия, что между ней и чтением не изменится кол-во данных...
Жалко, нет функции, которая сказала бы количество байт, доступных для чтения... Хотя всё равно не спасло бы - где гарантия, что между ней и чтением не изменится кол-во данных...
Разве SysComRead не возвращает количество доступных байт
Блин, уже жалею, что ПЛК63 на объекте, и раньше, чем через пару недель туда не доберусь. Очень интересно было бы проверить теорию "шестого байта"...
А нет ограничений на то, что в одном цикле должна быть только одна команда SysComRead? Или это требование относилось к тому, что в одном цикле или SysComRead, или SysComWrite... Или я что-то путаю, и такого совсем нет...
Жалко, нет функции, которая сказала бы количество байт, доступных для чтения... Хотя всё равно не спасло бы - где гарантия, что между ней и чтением не изменится кол-во данных...
В одном цикле SysComWrite и SysComRead теоретически можно. Но если посылается запрос устройству, который требует ответа, то ведь устройство должно принять запрос, обработать, послать ответ. Слишком длинный рабочий цикл получиться.
Я читать ответ частями и в одном цикле, и разносить по циклам. Результат тотже
в место единицы видимо Size должны были написать
В каком месте???
Может кто-нибудь посмотрел примеры?
Обсуждение свелось к предложениям - "нафига ... ", " зачем ..."
Еще раз. Эти примеры не имеют ничего общего с моими проектами. Я их специально написал, чтобы показать проблему.
А нужно это затем, что если есть такой глюк, то его надо учитывать в алгоритме программ, чтобы потом "блох" не вылавливать.
size := size + DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf[ 1 ]), SIZEOF(rBuf) - 1, 0)); смысл от этой строки, если до этого каждый цикл, переменной size будет присваиваться 0 либо 1. Друго дело если Вы накапливаете size, то и вычитать тогда нужно не 1 а size-прочитанных байт.
Хотели услышать ответ, честно говорю не смотрел Ваш проект, вернусь домой попытаюсь открыть
смысл от этой строки, если до этого каждый цикл, переменной size будет присваиваться 0 либо 1. Друго дело если Вы накапливаете size, то и вычитать тогда нужно не 1 а size-прочитанных байт.
Хотели услышать ответ, честно говорю не смотрел Ваш проект, вернусь домой попытаюсь открыть
Size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf), 1, 0)); (* запрос на чтение одного байта *)
if ( size > 0 ) then (* если прочитали один байт, пробуем прочитать остальное *)
(* здесь size равно 1 *)
size := size + DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf[ 1 ]), SIZEOF(rBuf) - 1, 0));
end_if
(* здесь size равно 1 *)
size := size +
эта связка зачем?
эта связка зачем?
можно так
size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf[ 1 ]), SIZEOF(rBuf) - 1, 0)) + 1;
без разницы
надо же учитывать что один байт УЖЕ ПРОЧИТАН здесь
Size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf), 1, 0)); (* запрос на чтение одного байта *)
size - кол-во байт прочитанных из буфера порта
Это
Size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf), SIZEOF(rBuf), 0));
заменить на это
Size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf), SIZEOF(rBuf), 0));
if ( size > 0 ) then
size := size + DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf[ 1 ]), SIZEOF(rBuf) - 1, 0));
end_if
Это
Size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf), SIZEOF(rBuf), 0));
заменить на это
Size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf), SIZEOF(rBuf), 0));
if ( size > 0 ) then
size := size + DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf[ 1 ]), SIZEOF(rBuf) - 1, 0));
end_if
Size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf), SIZEOF(rBuf), 0));
заменить на это
Size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf), 1, 0));
if ( size > 0 ) then
size := size + DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf[ 1 ]), SIZEOF(rBuf) - 1, 0));
end_if
По результатам выполнения оба куска кода равнозначны.
Это не для того, чтобы "лучше работало", а как " эксперимент ", раз уж мои примеры не смотрят
я понимаю, что Вы делите чтение на два этапа,сперва первый байт, затем пытаетесь записать оставшийся приемный буффер в массив rBuf начиная с индекс 1. У Вас после этого кода видимо Size еще где то используется для сравнения, сколько Вы всего приняли байт за два этапа? Для чего Вы накопление делаете. Судя по Вашим ответам разговор шел, что читать буффер Вы пытаетесь за несколько циклов, тогда суммирование уже смысла не имеет, так как с каждым новым циклом значение Size будет максимум равно 1
По результатам выполнения оба куска кода равнозначны.
Это не для того, чтобы "лучше работало", а как " эксперимент ", раз уж мои примеры не смотрят
В чем суть эксперимента? Наверное когда
Size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf), 10, 0));
if ( size > 0 ) then
size := size + DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf[ 1 ]), SIZEOF(rBuf) - 1, 0));
end_ifна первом этапе пытаетесь прочитать 10 байт, а приходит 6, то у Вас не клеится второй этап или как?
Это из вчерашней полуночной беседы.
[Валенок] сказал посмотреть как сделано в modbus.lib. Этот кусок кода чтение ответа из буфера порта и modbus.lib
rBuf: ARRAY[0..511] OF BYTE;
....
Size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf), SIZEOF(rBuf), 0));
Из чего видно, что посылается запрос на чтение 512 байт ( максимальная длина ответа по modbus ascii ). Я описывал симптомы другой проблемы...
Почитайте первый пост. И важно читать ответ по частям в одном цикле или разных, результат тотже
И важно читать ответ по частям в одном цикле или разных, результат тот же
И НЕ важно читать ответ по частям в одном цикле или разных, результат тот же
по первому посту, если ПЛК меняются ролями, то отсутствуют потери байта, если чтением занимается плк100?
В конце концов, можно попробовать читать из буфера порта по-байтно. На ПЛК63 результат будет тот же, только потерь будет больше...
Это из вчерашней полуночной беседы.
[Валенок] сказал посмотреть как сделано в modbus.lib. Этот кусок кода чтение ответа из буфера порта и modbus.lib
rBuf: ARRAY[0..511] OF BYTE;
....
Size := DWORD_TO_WORD(SysComRead(ComHandle, ADR(rBuf), SIZEOF(rBuf), 0));
Из чего видно, что посылается запрос на чтение 512 байт ( максимальная длина ответа по modbus ascii ). Я описывал симптомы другой проблемы...
Почитайте первый пост. И важно читать ответ по частям в одном цикле или разных, результат тотже
по первому посту, если ПЛК меняются ролями, то отсутствуют потери байта, если чтением занимается плк100?
Так точно !
а если этим занимались бы два ПЛК100, как считаете мог бы читающий ПЛК терять байты?
иначе проблема была бы в программе, и я не стал бы на форуме тему сосздавать
чего это сразу в программе, Вас кто то допустил к управлению СОМ-портом, Вы ему только передаете массив байт, а непосредственно передачу он осуществляет самостоятельно
а если этим занимались бы два ПЛК100, как считаете мог бы читающий ПЛК терять байты?
У меня нет второго ПЛК100. Но думаю что нет. Дело не в том как организован modbus slave в "PLC Конфигуратор", потому что если на ПЛК63 из буфера "выгребать" все содержимое, то потерь не возникает. Следовательно slave "отвечает" правильно.
В конце концов, можно попробовать читать из буфера порта по-байтно. На ПЛК63 результат будет тот же, только потерь будет больше...
Просто я не хочу писать еще один пример. Их все равно не смотрят.
да, но откуда Вы знаете, что заканчивая свою работу, функция SysComRead не снимает сигнал готовности к приему для передающего устройства, а новая функция не поднимает этот сигнал и вовремя этого импульса не теряется байт который как раз доставлялся
ЗЫ предположу, что если в настройках Вы выставите 7-N-1 количество потерянных байт может изменится
да, но откуда Вы знаете, что заканчивая свою работу, функция SysComRead не снимает сигнал готовности к приему для передающего устройства, а новая функция не поднимает этот сигнал и вовремя этого импульса не теряется байт который как раз доставлялся
А что про это где-то написано? Или это предположение?
ЗЫ предположу, что если в настройках Вы выставите 7-N-1 количество потерянных байт может изменится
я правильно понял
7 - кол-во бит данных
N - контроль нечетности
1- количество стоп-бит
А что про это где-то написано?ни где, можно сказать предположение. В моей практике был подобный протокол, причем СГП уходил на передающее устройство, а не использовался в своем приемном буфере.
по 7-н-1 верно
ЗЫ кстати на форуме написано, что буффер надо читать пока он не станет равным нулю, а не частями :)
да, но откуда Вы знаете, что заканчивая свою работу, функция SysComRead не снимает сигнал готовности к приему для передающего устройства, а новая функция не поднимает этот сигнал и вовремя этого импульса не теряется байт который как раз доставлялся
Работать можно только с буфером порта, а как там себя ведет " исполняемая система" codesys, мне не известно.
И опять же на ПЛК100 потери байтов нет
И опять же на ПЛК100 потери байтов нет
может на 63 передача организована более правильно, ведь он моложе ПЛК100 :)
Скорее уж наоборот :). Сейчас попробую
судя по сертификатам ПЛК100 начал выпускаться раньше на два года
Не вышло, пробовал
8-E-1, 8-O-1, 8-N-2, 8-N-1, на скоростях 112500, 57600 и 19200
В modbus serial количество бит данных должно быть 8.
http://modbus.org/docs/Modbus_over_serial_line_V1_02.pdf
Просто у меня в примерах для обмена используется modbus rtu
capzap, Вы работаете на Овен ?
capzap, Вы работаете на Овен ?
тут все получают пайку от ОВЕНа
monteg, вы уже кучу времени убили на разбирательство в одному Вам известных косяках, не жаль времени? Вам уже советовали, но осмелюсь повторить - напишите мастера используя только библиотеку syslibcom, без modbus.lib
Есть у кого еще что сказать по теме ?
тут все получают пайку от ОВЕНа
я не про это, просто интересно
у всех статус "пользователь"
у всех статус "пользователь"
бывает еще модератор и супер модератор
monteg, вот тут первый пример (http://www.owen.ru/forum/showthread.php?t=11279) - в архиве файл pr1.pro. относительно подробно расписано как что и почему делается
Филоненко Владислав
21.03.2012, 15:21
А просто 2 подряд чтения без всех этих состояний работает? Без всех этих наворотов?
monteg, вот тут первый пример (http://www.owen.ru/forum/showthread.php?t=11279) - в архиве файл pr1.pro. относительно подробно расписано как что и почему делается
Там не используется ПЛК63
тут все получают пайку от ОВЕНа
monteg, вы уже кучу времени убили на разбирательство в одному Вам известных косяках, не жаль времени? Вам уже советовали, но осмелюсь повторить - напишите мастера используя только библиотеку syslibcom, без modbus.lib
Точно, всех на уши поставил. Есть такие неспокойные.
А просто 2 подряд чтения без всех этих состояний работает? Без всех этих наворотов?
Не знаю про какие навороты Вы говорите. Сделал еще один пример - plc63master3.
В начале декларативной части есть константа FIRST_PART_SIZE, задающая размеры блоков чтения ответа. Если ( FIRST_PART_SIZE = 0 ) или ( FIRST_PART_SIZE >= RESPONSE_SIZE ), от ответ прочитается одним блоком, иначе ответ из буфера будет извлекаться двумя блоками
resultOfRead1 := SysComRead( port, ADR( part1 ), firstPartSize, 0 );
resultOfRead2 := SysComRead( port, ADR( part2 ), secondPartSize, 0 );
Если установить breakpoint на 54-ю строку, и посмотреть содержимое переменных, то все сразу видно.
Про какие навороты вы говорите, там код меньше 100 строк. Первая лаб. работа в институте более объемная. Надо Просто не полениться и залить проекты в железо. Неужели у техподдержки Овен под рукой нет одного ПЛК100 и одного ПЛК63
Там не используется ПЛК63
а если в настройках целевой платформы выбрать за место плк100 свой плк63?
а если в настройках целевой платформы выбрать за место плк100 свой плк63?
А если попробовать мой пример...
рад бы, да не имею плк63 :)
а если в настройках целевой платформы выбрать за место плк100 свой плк63?
Нашел на складе MBA8... Пример PR1 прекрасно работает.
Внимание вопрос, считаете ли Вы замену корректной:
byte_read:=SysComRead(port_number, ADR(buf_otvet), 8, 0);
на
byte_read:=SysComRead(port_number, ADR(buf_otvet[ 0 ]), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 1 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 2 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 3 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 4 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 5 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 6 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 7 ] ), 1, 0);
Кто-нибудь, положит этим мучениям конец. Скажет, что-нибудь дельное по теме...
WHILE SysComRead(ComHand, ADR(Buffer), SIZEOF(Buffer), 0) <> 0 DO ; END_WHILE
SysMemCpy(ADR(buf_otvet[0]),ADR(Buffer[0]),1);
SysMemCpy(ADR(buf_otvet[1]),ADR(Buffer[1]),1);
SysMemCpy(ADR(buf_otvet[2]),ADR(Buffer[2]),1);
SysMemCpy(ADR(buf_otvet[3]),ADR(Buffer[3]),1);
SysMemCpy(ADR(buf_otvet[4]),ADR(Buffer[4]),1);
SysMemCpy(ADR(buf_otvet[5]),ADR(Buffer[5]),1);
SysMemCpy(ADR(buf_otvet[6]),ADR(Buffer[6]),1);
SysMemCpy(ADR(buf_otvet[7]),ADR(Buffer[7]),1);
а почему Вас такой то код не устраивает?
Передача данных осуществляется непрерывно, если больше определенного размера, то передача делится на кадры. Если приемный буфер переполняется, то начинают теряться данные, проверка четности и контрольная сумма не исправляют код а лишь информируют что данные некорректны. Поэтому всякая трата времени процессора на второстепенные задачи, вроде закрытия ПОУ, открытия ПОУ (причем с таким же функционалом) неизбежно приведет к потере данных, рано или поздно. То что один ПЛК справляется с двумя чтениями подряд, так может у него объем буферной памяти больше, другая микросхема и т.п. Поэтому заостряю еще раз внимание, на то что прочитать информацию надо за более короткий срок, а потом уже делайте с ней (информацией) что угодно
Лучше бы так разбирались как SysComWrite заставить соблюдать интервалы тишины между кадрами
ЗЫ посмотрел один из проектов, впечатление удручающее по поводу использования функций для таймера, полный атас :)
Ответе, пожалуйста, вы сотрудник Овен?
Если да, то значит у Вас можно уточнить тех. нюансы, которые отсутствуют в документации. Например может ли переполниться буфер порта rs-485 от приема 13 байт... А если это предположения, то у меня от своих уже голова пухнет
Ответе, пожалуйста, вы сотрудник Овен?
Если да, то значит у Вас можно уточнить тех. нюансы, которые отсутствуют в документации. Например может ли переполниться буфер порта rs-485 от приема 13 байт... А если это предположения, то у меня от своих уже голова пухнет
Я не сотрудник ОВЕН, точно так же как процессор и набор микросхем используемый в ПЛК не принадлежит ихней торговой марке. После такого высказывания с Вашей стороны, мне лично не понятен Ваш вопрос, по поводу кто еще чего дельного скажет, успехов в самостоятельном плавании
Схема тривиальная:
1. открываем порт
2. настраиваем порт
3. очищаем буфер
4. посылка запроса
5. пауза
6. чтение ответа
7. пауза
8. переход на пункт 3.
Паузы стоят довольно большие 50ms. Этого времени вполне достаточно, чтобы полностью получить ответ из 13 байтов. К тому же если бы буфер и переполнялся бы,
SysComRead( port, ADR( dest1 ), 5, 0 ) -> 5
SysComRead( port, ADR( dest2 ), 5, 0 ) -> вернул тоже 5, но с мусором
Ладно всем спасибо за участие, извините за потраченное на меня время
Я не сотрудник ОВЕН, точно так же как процессор и набор микросхем используемый в ПЛК не принадлежит ихней торговой марке. После такого высказывания с Вашей стороны, мне лично не понятен Ваш вопрос, по поводу кто еще чего дельного скажет, успехов в самостоятельном плавании
Извини, не хотел обидеть, поставить под сомнения квалификацию и т.д.
Просто голова уже кругом идет. Я спрашивал о сотрудничестве с Овен, только потому, что рекомендации техподдержки можно считать официальными рекомендациями производителя.
А предложениями "что-то такое попробовать" и "что-то додумать" я за два дня наелся. Данная тема изначально была ориентирована на техподдержку.
Я ДЕЙСТВИТЕЛЬНО, НИКОГО НЕ ХОТЕЛ ОБИДЕТЬ
Нашел на складе MBA8... Пример PR1 прекрасно работает.
Внимание вопрос, считаете ли Вы замену корректной:
byte_read:=SysComRead(port_number, ADR(buf_otvet), 8, 0);
на
byte_read:=SysComRead(port_number, ADR(buf_otvet[ 0 ]), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 1 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 2 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 3 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 4 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 5 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 6 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 7 ] ), 1, 0);
я считаю, что авторитетно поставить крест определить корректность этого решения может Александр Приходько, создававший эти примеры. от себя могу сказать, что не вижу абсолютно никакого здравого смысла в восьми чтениях буфера по 1 байту вместо 1 чтения по 8 байт.
что вам не нравится в примере? прочитали из буфера 8 байт, можете начинать проверять корректность посылки (адрес устройства, № функции...)
p.s. единственное, что у меня вызывает некоторые сомнения - ваша таймерная пауза между отправкой команды в буфер и переходом к чтению буфера в 100мс. по моему мнению это многовато.
Филоненко Владислав
22.03.2012, 10:34
Всегда ответ надо читать по 1 байту и сразу анализировать. Ожидать что пришли все байты и только нужное количество байт нельзя. По 1 байту считываем, каждый анализируем на корректность и принимаем решение о конце пачки/бракованной пачке.
Пример с таким чтением в 2 приёма я проверю, но не скоро.
а кто их ждет? читаем, сразу проверяем, но пачкой читаем, а не поштучно.
я считаю, что авторитетно поставить крест определить корректность этого решения может Александр Приходько, создававший эти примеры. от себя могу сказать, что не вижу абсолютно никакого здравого смысла в восьми чтениях буфера по 1 байту вместо 1 чтения по 8 байт.
что вам не нравится в примере? прочитали из буфера 8 байт, можете начинать проверять корректность посылки (адрес устройства, № функции...)
p.s. единственное, что у меня вызывает некоторые сомнения - ваша таймерная пауза между отправкой команды в буфер и переходом к чтению буфера в 100мс. по моему мнению это многовато.
Здравого смысла здесь и нет. Просто почему-то после такой замены пример не работает. А такая большая задержка была использована специально. За 100ms данный ответ с очень большой вероятностью окажется полностью в буфере "мастера". А дальше пытаюсь его прочитать из буфера, но не целиком, а частями. Я писал примеры, не с точки зрения практичности, а чтобы проблему, которую я описывал было легко обнаружить...
Ладно это уже не важно, в следующих четырех проектах будем использовать контроллеры другого производителя.
Всем спасибо за участие, терпение, и потраченное время. Всем удачи
Всегда ответ надо читать по 1 байту и сразу анализировать. Ожидать что пришли все байты и только нужное количество байт нельзя. По 1 байту считываем, каждый анализируем на корректность и принимаем решение о конце пачки/бракованной пачке.
Пример с таким чтением в 2 приёма я проверю, но не скоро.
Если библиотека позволяет вести пакетный обмен, то и надо этим пользоваться. Вероятно, проблемы при обмене по RS-485 при использовании SysLibCom связаны с не совсем корректным управлением шиной сети. Порядок обмена по RS-485 должен быть такой:
1) Master сети захватывает шину (сразу после подачи питание на устройство, выполняющего роль Maser);
2) Master делает небольшую паузу и загружает выходной буфер пакетом байт, данные посылаются в сеть;
3) Master после загрузки буфера держит шину пока весь пакет данных не будет выпихнут в сеть и не дойдет до Slave;
4) Slave после приема пакета должен сразу захватить шину и только после этого Master отпускает шину и становится на прием.
Передача от Slave к Master должна происходить аналогично. После приема пакета от Slave Master захватывает шину делает паузу и далее процедура повторяется.
Очень важным моментом при обмене по RS-485 является то, что шина в каждый момент времени должна быть захвачена хотя бы с одной стороны, ну и процедура перехвата шины должна быть скоординирована. Если не учесть эти моменты (касается того, кто писал программу прошивки для ПЛК63), то может происходить то с чем столкнулся многострадальный monteg.
Всегда ответ надо читать по 1 байту и сразу анализировать. Ожидать что пришли все байты и только нужное количество байт нельзя. По 1 байту считываем, каждый анализируем на корректность и принимаем решение о конце пачки/бракованной пачке.
Пример с таким чтением в 2 приёма я проверю, но не скоро.
Так точно. Но почему тогда именно чтение по 1 байт на ПЛК63 глючит.
Чтение по 1 байту можно же считать частным случаем чтением двумя блоками.
Заменя
byte_read:=SysComRead(port_number, ADR(buf_otvet), 8, 0);
на
byte_read:=SysComRead(port_number, ADR(buf_otvet[ 0 ]), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 1 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 2 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 3 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 4 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 5 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 6 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 7 ] ), 1, 0);
приводит к ошибкам, про которые я говорил
Если библиотека позволяет читать пакет байт, то и надо читать пакет. Вероятно, проблемы при обмене по RS-485 при использовании SysLibCom связаны с не совсем корректным управлением шиной сети. Порядок обмена по RS-485 должен быть такой:
1) Master сети захватывает шину (сразу после подачи питание на устройство, выполняющего роль Maser);
2) Master делает небольшую паузу и загружает выходной буфер пакетом байт, данные посылаются в сеть;
3) Master после загрузки буфера держит шину пока весь пакет данных не будет выпихнут в сеть и не дойдет до Slave;
4) Slave после приема пакета должен сразу захватить шину и только после этого Master отпускает шину и становится на прием.
Передача от Slave к Master должна происходить аналогично. После приема пакета от Slave Master захватывает шину делает паузу и далее процедура повторяется.
Очень важным моментом при обмене по RS-485 является то, что шина в каждый момент времени должна быть захвачена хотя бы с одной стороны, ну и процедура перехвата шины должна быть скоординирована. Если не учесть эти моменты (касается того, кто писал SysLibCom), то может происходить то с чем столкнулся многострадальный monteg.
Интересная теория. Ну так в ком проблема ПЛК63?
Потому что на ПЛК100 ТОТЖЕ КОД работает
Интересная теория. Ну так в ком проблема ПЛК63?
Эта теория многократно и успешно проверена на практике. В свое время я очень плотно занимался этими делами. В обмене по RS-485 в прстейшем случае учавствуют два устройства - Master и Slave. Проблемы могут возникнуть если некорректно работают с сетью или тот или другой или оба вместе.
Если "железо" у ПЛК100 и ПЛК63 сделано совершенно одинаково, то, возможно, у Вас неисправен ПЛК63.
А о каком коде речь, тот что написали Вы или тот, что зашит в ПЛК63 ?
Да я все про свои примеры...
Я вот поэтому и просил разобраться с моими примерами, может сам код неверный, может ПЛК63 мне попался не совсем исправный, а может это авторская задумка СОЗДАТЕЛЕЙ ПЛК63.
А отвечают, ты дурак, у тебя код не сложный ( 100 строк) , на фига это надо, или попробуй то, или подумай что будет если что. Поймите я не занимаюсь разработкой "железки" с rs485. Все эти технические нюансы должны интересовать тех, кто проектировал ПЛК. Меня интересовала другая конкретная проблема. (см. первый пост), а какие там внутри микрухи и как они взаимодействуют, лично мне не интересны.
Если бы кто-нибудь "официальный" сказал, что это авторская задумка, так работать не будет, или будет работать плохо, то обсуждение на этом бы и закончилось.
Да я все про свои примеры...
Я вот поэтому и просил разобраться с моими примерами, может сам код неверный, может ПЛК63 мне попался не совсем исправный, а может это авторская задумка СОЗДАТЕЛЕЙ ПЛК63.
А отвечают, ты дурак, у тебя код не сложный ( 100 строк) , на фига это надо, или попробуй то, или подумай что будет если что. Поймите я не занимаюсь разработкой "железки" с rs485. Все эти технические нюансы должны интересовать тех, кто проектировал ПЛК. Меня интересовала другая конкретная проблема. (см. первый пост), а какие там внутри микрухи и как они взаимодействуют, лично мне не интересны.
Если бы кто-нибудь "официальный" сказал, что это авторская задумка, так работать не будет, или будет работать плохо, то обсуждение на этом бы и закончилось.
Скорее всего, Ваш код корректен если он работает на ПЛК100. А вот если железо ПЛК63 исправно, а связь по RS-485 плохая, то некорректно написана программа прошивки ПЛК63 в той части, которая ведет обмен по сети.
Так точно. Но почему тогда именно чтение по 1 байт на ПЛК63 глючит.
Чтение по 1 байту можно же считать частным случаем чтением двумя блоками.
Заменя
byte_read:=SysComRead(port_number, ADR(buf_otvet), 8, 0);
на
byte_read:=SysComRead(port_number, ADR(buf_otvet[ 0 ]), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 1 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 2 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 3 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 4 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 5 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 6 ] ), 1, 0);
byte_read:= byte_read + SysComRead(port_number, ADR( buf_otvet[ 7 ] ), 1, 0);
приводит к ошибкам, про которые я говорил
Если чтение пакета байт на ПЛК63 идет нормально, то и пользуйтесь этим, что Вы уперлись в чтение по одному байту. Чтение пакетом и быстрее и надежнее (сбоев при обмене будет меньше).
Скорее всего, Ваш код корректен если он работает на ПЛК100. А вот если железо ПЛК63 исправно, а связь по RS-485 плохая, то некорректно написана программа прошивки ПЛК63 в той части, которая ведет обмен по сети.
Может и так, но у меня нет ни второго ПЛК63, ни другой прошивки. Если кините ссылку на другую прошивку ( у меня 2.12 10 0f), буду благодарен, попробую. Мне сейчас все равно заняться нечем, siemens жду...
Если чтение пакета байт на ПЛК63 идет нормально, то и пользуйтесь этим, что Вы уперлись в чтение по одному байту. Чтение пакетом и быстрее и надежнее (сбоев при обмене будет меньше).
а здесь другое говорят
Всегда ответ надо читать по 1 байту и сразу анализировать. Ожидать что пришли все байты и только нужное количество байт нельзя. По 1 байту считываем, каждый анализируем на корректность и принимаем решение о конце пачки/бракованной пачке.
Пример с таким чтением в 2 приёма я проверю, но не скоро.
Может и так, но у меня нет ни второго ПЛК63, ни другой прошивки. Если кините ссылку на другую прошивку ( у меня 2.12 10 0f), буду благодарен, попробую. Мне сейчас все равно заняться нечем, siemens жду...
Что можете ответить на пост #63 ?
а здесь другое говорят
Глупость это. Еще раз повторяю: обмениваться пакетами байт и быстрее и надежнее. Это благо, что в SysLibCom такая возможность есть.
Может и так, но у меня нет ни второго ПЛК63, ни другой прошивки. Если кините ссылку на другую прошивку ( у меня 2.12 10 0f), буду благодарен, попробую. Мне сейчас все равно заняться нечем, siemens жду...
Siemens это хорошо, но ооооочень дорого. Усли не трудно сообщи во сколько раз ПЛК63 дешевле аналога Siemens. Я думаю многим будет интересно.
Всегда ответ надо читать по 1 байту и сразу анализировать. Ожидать что пришли все байты и только нужное количество байт нельзя. По 1 байту считываем, каждый анализируем на корректность и принимаем решение о конце пачки/бракованной пачке.
Пример с таким чтением в 2 приёма я проверю, но не скоро.
Что можете ответить на пост #63 ?
не на ту кнопку нажал... сори
Что можете ответить на пост #63 ?
А что я могу на это ответить....
А что я могу на это ответить....
Прочти пост #140 и #141.
Siemens это хорошо, но ооооочень дорого. Усли не трудно сообщи во сколько раз ПЛК63 дешевле аналога Siemens. Я думаю многим будет интересно.
Извини я поставками не занимаюсь, я спросил, потянет ли бюджет проекта siemens, сказали - легко.
Конечно siemens дороже, уж раза в 2 точно
и еще один недостаток ждать долго, нам сказали 5 недель
Извини я поставками не занимаюсь, я спросил, потянет ли бюджет проекта siemens, сказали - легко.
Конечно siemens дороже, уж раза в 2 точно
Я думаю не в 2, а в 5 раз дороже по железу. А еше среда программирования платная и все прочее. Как написал однажды один посетитель формума - "У Siemens нужно платить за каждый пук" и это правда. Но если контора платит, то вперед.
Приношу извинения, я НЕ ХОТЕЛ РЕКЛАМИРОВАТЬ ДРУГОГО ПРОИЗВОДИТЕЛЯ.
Приношу извинения, я НЕ ХОТЕЛ РЕКЛАМИРОВАТЬ ДРУГОГО ПРОИЗВОДИТЕЛЯ.
А где тут реклама ? И дорого и долго.
Глупость это. Еще раз повторяю: обмениваться пакетами байт и быстрее и надежнее. Это благо, что в SysLibCom такая возможность есть.
Конечно хорошо, что есть такая возможность. Полностью согласен.
Но если в буфере порта 100 байт, а ты запрашиваешь 10, а потом еще 10, то теряются байты. Не всегда, но очень часто. Я упираюсь не затем, что хочу сказать какое г. делает Овен, там одни глюки и т.д. Я просто хочу разобраться в проблеме. Потому когда в реальном проекте начнешь делать обмен данными с 20 устройствами ( modbus, DCON, нестандартные протоколы ), и вроде все правильно, и алгоритм отлажен, до "дыр", и вдруг появляются мелкие, но жуткие, "косяки". Ты начинаешь заново отлаживать весь проект, сидишь пару дней, а потом оказывается что "косяк" в стандартной библиотеки. Ты конечно в это не веришь. Делаешь экспериментальный пример только на работу с портом. И оказывается, что проблема именно в библиотеки ( или как эта библиотека работаем на целевом контроллер )
А где тут реклама ? И дорого и долго.
Ну и слава богу. Вдруг за рекламу, другого производителя меня бы "заблочили"...
Конечно хорошо, что есть такая возможность. Полностью согласен.
Но если в буфере порта 100 байт, а ты запрашиваешь 10, а потом еще 10, то теряются байты. Не всегда, но очень часто. Я упираюсь не затем, что хочу сказать какое г. делает Овен, там одни глюки и т.д. Я просто хочу разобраться в проблеме. Потому когда в реальном проекте начнешь делать обмен данными с 20 устройствами ( modbus, DCON, нестандартные протоколы ), и вроде все правильно, и алгоритм отлажен, до "дыр", и вдруг появляются мелкие, но жуткие, "косяки". Ты начинаешь заново отлаживать весь проект, сидишь пару дней, а потом оказывается что "косяк" в стандартной библиотеки. Ты конечно в это не веришь. Делаешь экспериментальный пример только на работу с портом. И оказывается, что проблема именно в библиотеки ( или как эта библиотека работаем на целевом контроллер )
Вы, кажется, сами запутались и всех запутали. Пользуйтесь тем что работает и успокойтесь, хватит воду в ступе толочь.
Я надеюсь, что кто-то, все-таки посмотрит мои примеры. И либо подтвердит мои предположения или скажет где у меня в коде ошибка
Я надеюсь, что кто-то, все-таки посмотрит мои примеры. И либо подтвердит мои предположения или скажет где у меня в коде ошибка
Опять 25 !?. В чем состоят Ваши предположения, можете коротко и ясно сформулировать ?
Опять 25 !?. В чем состоят Ваши предположения, можете коротко и ясно сформулировать ?
Понятно.
Просто хотелось получить конструктивный ответ:
- ты дурак, и программа у тебя дурацкая ( + пояснения )
- не та прошивка ПЛК, не та версия SysLibCom ( есть более новая, ну вдруг.. ) и т.д.
- бракованный ПЛК, попробуйте другой
- это болезнь ПЛК63, не заморачивайся
А обсуждение свилось к вот к этому ( в образном смысле ):
Пример из бытовой электрики:
- нельзя "скручивать" медные и алюминиевые провода
- почему нельзя? можно я же так делал и все работало
Механически скрутить медный и алюминиевый провод конечно можно, но со временем обязательно появятся проблемы с проводкой.
я уже и письмо писал на на "support@owen.ru"
"Молчит, проклятый"
А обсуждение свилось к вот к этому ( в образном смысле ):
Пример из бытовой электрики:
- нельзя "скручивать" медные и алюминиевые провода
- почему нельзя? можно я же так делал и все работало
Механически скрутить медный и алюминиевый провод конечно можно, но со временем обязательно появятся проблемы с проводкой.
Всех уморил. Лучше работай с Siemens, дорого да мило. Всем будет спокойней.
Какие ПЛК в проект включат, с теми и буду работать
Какие ПЛК в проект включат, с теми и буду работать
Вот и славно. Аминь !
Всех уморил. Лучше работай с Siemens, дорого да мило. Всем будет спокойней.
Аминь !
Это есть конструктивный ответ?...
Это есть конструктивный ответ?...
Нет никаких особых проблем, в основном все из "пальца высосано".
Нет никаких особых проблем, в основном все из "пальца высосано".
Проблемы есть, не фатальные, но есть. А вот ответы точно из "пальца высосано". Ни о чем.
Проблемы есть, не фатальные, но есть. А вот ответы точно из "пальца высосано". Ни о чем.
Короче говоря, все дураки один Вы умный. На этом надо и завершить тему, а то все до неприличия растянулось. Очень Вы всех утомили. За такое короткое время такое количество постов ! Просто рекорд. Но пора Вам и честь знать.
Ни о чем.
У Вас есть несколько мва8, 1 плк63, десяток метров хотя бы пвс ?
Короче говоря, все дураки один Вы умный. На этом надо и завершить тему, а то все до неприличия растянулось. Очень Вы всех утомили. За такое короткое время такое количество постов ! Просто рекорд. Но пора Вам и честь знать.
Согласен, бедлам получился. Но почему я в этом виноват. Описал стенд :
ПЛК100 - RS485 - ПЛК63. Написал примеры, даже указал где breakpoint ставить и какие переменные смотреть. А зачем всё так размазали я сам не понял.
И судя по содержанию форума дурак здесь один, я.
У Вас есть несколько мва8, 1 плк63, десяток метров хотя бы пвс ?
Зачем, поясните
опрошу все. каждый за раз
А интересно кто из участников дискуссии работает в Овен. Просто я не совсем понимаю, зачем обычным "мирскИм" людям тратить на это столько времени. К тому же, если у них все работает хорошо, а проблему я сам себе придумал. Это не сарказм, я в недоумении...
опрошу все. каждый за раз
Можно исходник увидеть.
У меня один мва8 и один плк63. Кабель найдется.
Зачем исходник ?
Проверить что группы можно подставив рукописный syslibcom. Или каким-то снифером - чесно, ни разу не использовал.
ПЛК100 R.M - можете набить в слейве 1 кило ? (4 байта и ctrl-v рулит)
Зачем исходник ?
Проверить что группы можно подставив рукописный syslibcom. Или каким-то снифером - чесно, ни разу не использовал.
ПЛК100 R.M - можете набить в слейве 1 кило ? (4 байта и ctrl-v рулит)
Пожалуйста, опишите стенд по подробнее
Зачем исходник ?
Проверить что группы можно подставив рукописный syslibcom. Или каким-то снифером - чесно, ни разу не использовал.
ПЛК100 R.M - можете набить в слейве 1 кило ? (4 байта и ctrl-v рулит)
Пожалуйста, кратко опишите суть эксперимента, и какие нужны девайсы и программы.
И встречный вопрос, у Вас есть ПЛК63
Набиваете 1 к. в слейв
и пишете в слейв.
p: pointer to array[1..1000] of byte; (*это будет сетевая переменная*)
t(in:=not t.q, pt := 2сек);
if t.q then
p:=adr(..);
for i:=1 to 1000 do
p^[i]:=p^[i]+1;
end_for
end_if
А видите и меняете все это в 63. И, мимоходом, МВА8. Тоже все.Есть еще что-нить в слейв большое ?
И встречный вопрос, у Вас есть ПЛК63
На работе есть. Регулярно.
Набиваете 1 к. в слейв
и пишете в слейв.
p: pointer to array[1..1000] of byte; (*это будет сетевая переменная*)
t(in:=not t.q, pt := 2сек);
if t.q then
p:=adr(..);
for i:=1 to 1000 do
p^[i]:=p^[i]+1;
end_for
end_if
А видите и меняете все это в 63. И, мимоходом, МВА8. Тоже все.Есть еще что-нить в слейв большое ?
Нет, ничего большего, чем МВА8 нет.
Вы это уже сделали, попробовали, что-то получилось? Если да, по пожалуйста, пришлите исходник...
На работе есть. Регулярно.
А ПЛК100 ???
Вы это уже сделали, попробовали, что-то получилось? Если да, по пожалуйста, пришлите исходник...
Делал. Делаю.Работает.
А пулемета я вам, ребята, не дам.
Я сейчас все равно дома, так что до завтра. А в чем проблема и исходником. Вы за него Нобелевскую премию хотите получить...
Я правда сейчас не совсем понял ( я про кусок кода ), завтра посмотрю. Так ведь даже если я ваш замысел реализую, так опять скажите , все криво, непонятно и тд. Дайте исходник, что бы не мучится...
А МВА8 есть, как я понимаю
Завтра вечером скину. Не пишите ничего. Настройте мва8 @1 115200/8/N/1, 0ms
И в ПЛК100- слейв наколотите регистров. Побольше
Завтра вечером скину. Не пишите ничего. Настройте мва8 @1 115200/8/N/1, 0ms
я правильно понял
скорость = 115200
адрес устройства = 1
кол-бит данных = 8
контроль четности = отсутствует
кол-во стоп-бит = 1
задержка ответа = 0ms
И в ПЛК100- слейв наколотите регистров. Побольше
А этот исходник можно тоже скинуть. Вы все равно будете делать, так чего уж...
Есть еще что-нить в слейв большое ?
:) весь сыр бор затеивался из-за получения исходника у тех кто умеет побыстрому опрашивать слейвы, кстати если проблема в 63, то какая разница кто выступает в качестве слейва, максимальный по размеру и соответствующий стандарту у меня является PeakHMISlaveSimulator для windows, работает и через АС4
:) весь сыр бор затеивался из-за получения исходника у тех кто умеет побыстрому опрашивать слейвы, кстати если проблема в 63, то какая разница кто выступает в качестве слейва, максимальный по размеру и соответствующий стандарту у меня является PeakHMISlaveSimulator для windows, работает и через АС4
Еще раз. Примеры создавались в расчете на техподдержку производителя. Поэтому использовались только "овеновские" устройства.
ПЛК100 slave - показать, что если в ПЛК100 залить тот же код, то и описанной проблемы ( см. первый пост ) не наблюдается.
Почему именно ПЛК100, потому что у нет другого "овеновского" плк.
Использовать устройства других производителей или эмуляторы показалось не целесообразным, сразу бы свалили именно на это, и сказали, чтобы "попробовал на нашем оборудовании"
Уважаемые коллеги. Если Вы считаете, что тема "высосана из пальца", у меня все работает, а автор дурак, то пожалуйста не засоряйте тему. Она и так уже превратилась черт знает во что. Я понимаю, что у нас свобода слова, просто сообщений характера " а нафига ... " уже слишком много. Если есть конструктивные вопросы по моим примерам с радостью отвечу.
Уважаемые коллеги. Если Вы считаете, что тема "высосана из пальца", у меня все работает, а автор дурак, то пожалуйста не засоряйте тему. Она и так уже превратилась черт знает во что. Я понимаю, что у нас свобода слова, просто сообщений характера " а нафига ... " уже слишком много. Если есть конструктивные вопросы по моим примерам с радостью отвечу.
Так эпопея завершилась или нет ?
Всегда ответ надо читать по 1 байту и сразу анализировать. Ожидать что пришли все байты и только нужное количество байт нельзя.
А реализация какова? Читать по байту за цикл, это не серьёзно. Перебором через WHILE, можно нарваться на "злую собаку". Пошагово, как предлагает создатель темы, зачем писать "портянку" когда есть WHILE.
Всё по байту читаем ?
Валенок, расскажите как Вы с monteg проблему решили, а то он что-то замолк. Перенапрягся за неделю, наверное.
Не пишет, не звонит ..
А какая проблема ?
Нет человека, нет проблемы..
кто-то хотел исходник прислать...
Валенок, расскажите как Вы с monteg проблему решили, а то он что-то замолк. Перенапрягся за неделю, наверное.
не то слово
Не пишет, не звонит ..
А какая проблема ?
Нет человека, нет проблемы..
А не знаю, чего столько народа собралось вокруг проблемы "высосанной из пальца". Примеры, как я понял никто толком не посмотрел, вопросы по коду не задают. Только изводятся по по-поводу работы с таймером. Конечно функции StartTimer, StopTimer и т.д. - жутко непонятные навороты. "Без 0.5 литра не разберешся....". Захотелось сделать функции-оболочки для TON. Мне, допустим такой код глаза режет
IF scb.errors<>0 THEN
avaria:=TRUE;
ELSE
avaria:=FALSE;
END_IF
я бы так написал
avaria := not ( scb.errors = 0 );
Это вопрос "стилистики", оформления и не вижу ни какого смысла это обсуждать.
И еще граждане, коллеги, господа. Пожалуйста, пришлите какую-нибудь прошивку, или ссылку киньте для плк63, до 2.15. Я на оф. сайте не нашел. А вдруг поможет...
А реализация какова? Читать по байту за цикл, это не серьёзно. Перебором через WHILE, можно нарваться на "злую собаку". Пошагово, как предлагает создатель темы, зачем писать "портянку" когда есть WHILE.
По байту за цикл, это конечно не серьезно. В рабочих проектах у меня будет что вроде "вложения". Код толком не проверял, енто так фантазия.
Мне, допустим такой код глаза режет
IF scb.errors<>0 THEN
avaria:=TRUE;
ELSE
avaria:=FALSE;
END_IF
я бы так написал
avaria := not ( scb.errors = 0 );
Это вопрос "стилистики", оформления и не вижу ни какого смысла это обсуждать.
avaria := scb.errors <> 0;
А почему не так, зачем опять оригинальничать. Эта Ваша стилистика может привести к ошибкам, которые трудно выловить. Какой смысл смотреть Ваши примеры если железа нет, никто не сомневается что пишите Вы код правильно, так чего его смотреть. По поводу прошивки, если раньше ни кто таким вопросом не озадачивал, то вероятнее всего и прошивку в этом месте кода ни кто не правил
кто-то хотел исходник прислать...
Судя по времени выхода в эфир, наше и ваше "сегодня" несовпадают
В ящике.Про исходник - не говорил.Залейте и проверьте. Несколько деталей - обсудим здесь
PS
Все высосано из пальца.
В связке 63 с 100 - я бы предпочел мастера 63. У 100 задать слейв в пару сотен регистров - 5..6 сек, а у 63 надо еще ковырятся с адресами
Валенок, у Вас есть ПЛК63 и МВА8 ?
С какой целью интересуетесь ?
Sergey1024
06.11.2012, 11:30
Хотел бы узнать, решена ли проблема - у меня точно такая же, только с ПЛК73 (тема тут (http://www.owen.ru/forum/showthread.php?p=95146&posted=1#post95146)).
Хотелось бы узнать, по каким причинам могут теряться данные на линии в 10см, это баг али фича?
Можно сказать, что решена.
BUFFER_SIZE : DWORD := 1024;
buffer : array [ 1..BUFFER_SIZE ] of byte;
resultOfRead : dword;
resultOfRead := SysComRead( port_id, ADR( buffer ), BUFFER_SIZE, 0 );
if ( resultOfRead > 0 ) then
...
end_if
BUFFER_SIZE - размер буфера последовательного порта.
Значение константы BUFFER_SIZE нашел где-то на форме...
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot