Какой может быть "REAL" при подсчете импульсов ?Цитата:
Сообщение от Василий_S
Вид для печати
Какой может быть "REAL" при подсчете импульсов ?Цитата:
Сообщение от Василий_S
Четырёх ком-портовая мокса воткнута как плата расширения в ПК. Появилась возможность разделить ПЛК на 4 группы. Номера ком-портов хорошо просматриваются в диспетчере устройств. К ним обращаются 4 программы, каждая к своему порту.Цитата:
Сообщение от IVM
Запрос, ожидание по таймауту или пока длина буфера будет равна 75, затем - считывание данных из буфера. 0.09 сек, поставленные на таймаут вполне достаточны.
Элементарно: импульсы (содержатся в формате DINT) надо пересчитывать в реальные единицы с учётом цены этих импульсов, к-та трансформации, а при получении значений текущей мощи ещё и делить на 200. Получаются, иногда, числа с запятыми.Цитата:
Сообщение от Вольд
Поэтому решил, чтобы не таскать по проводам знаки, порядки и мантиссы, лучше буду брать данные целым числом. И выиграл на этом в том, что за 1 запрос снимаю данные по 8 входам сразу, больше в буфер не лезет.
ОС Windows не является системой реального времени. По этой причине может возникнуть путаница с пакетами, принимаемыми из ПЛК.Цитата:
Сообщение от Василий_S
Ты не правильно поставил задачу. Правильно писал IVM. Еще раз повторяюсь. Надо было чтобы ПЛК тупо считали импульсы от счетчиков и передавали накопленную сумму в ПК. А в программе ПК делай все расчеты и прочее и не было бы никаких проблем.Цитата:
Сообщение от Василий_S
Не согласен.Цитата:
Сообщение от Вольд
Хотя примерно так и делается, только разница в сбросе счётчиков.
Потом, ПЛК в данной системе - что-то вроде БД. Комп может вырубиться и данные можно потерять.
Обоснуй свои мысли.Цитата:
Сообщение от Василий_S
Вы, по сути предлагаете то же самое, только счётчики всё равно надо обнулять в один прекрасный момент. И всё равно придётся синхронизировать это обнуление с выполнением программы "наверху" и придётся это делать опять-таки по времени. И там наверху, просто, будут другие проблемы. Так выгоднее - к этому решению пришёл.
Ладно, Вольд, это тема для другого разговора. Не эта бы фигня - всё было бы ништяк. В целом и в подавляющем большинстве система работает. И показатели бъют в рамках своёй точности и методике обработки данных.
В бы лучше что-нибудь про явление с "отпусканием линии" где в КС непонятно что. Я впервые услышал об этом.
С одним направлением поисков определился - проверим ситуацию с заземлением. А если история будет продолжаться в том же духе?
У тебя максимальное время в течение которого ты не можешь принять правильный пакеты от ПЛК какое ? Правильный пакет это тот, у которого правильная КС. С какой периодичностью ты шлешь запросы в ПЛК ?
У тебя накопленные импульсы хранятся в ПЛК и никуда они не потеряются пока сам не сбросишь счетчики. Разрядность счетчиков можно сделать очень большой, тогда не понадобится их часто обнулять. Обработку результатов намного удобнее вести в приложении для ПК. Ты сделал стратегическую ошибку при постановке задачи. Ладно бы тебе кто-то навязал свою идеологию, но ты сам принимал решение.Цитата:
Сообщение от Василий_S
Остапа несло-о! Какие слова, какой типаж.Цитата:
Сообщение от Вольд
Что не нравится ? Ничего, перетопчешься. Сам себе проблемы создал.Цитата:
Сообщение от Василий_S
Ситуация интересная. Вот, например, на одном ком-порте висят два контроллера. К каждому устройству даётся возможность сделать запрос до 20 раз, для чего на "верху"организован цикл. Если ответ на запрос проходит проверку по трём критериям, то программа выходит из цикла многоразового запроса к одному устройству и переходит к другому. В случае, если количество попыток достигло 20-ти, то в текстовый файл записывается строка с содержанием адреса устройства, времени запроса, отметки о наличии 20-ти попыток и содержание ответа устройства. В случае если данные были приняты не с первой попытки (кроме 20-й), - также делается запись в файл.Цитата:
Сообщение от Вольд
В текстовом файле видно, что при повторных, (далеко не частых) попытках данные принимаются, в основном, со 2-й и 3-й попытки. Устройства "шалят" не синхронно.
Но есть моменты, когда в течении 10 секунд данные, с одного устройства, не принимаются (не проходят проверку по трём фильтрам) в то время, когда с другого устройства данные принимаются "на ура".
Т.е. видно в течение 10-ти секунд одного из 18-ти секундных циклов делаются записи с адресом одного устройства, кол-во попыток = 20 и содержание ответа, где в КС стоят нули. Причём остальные данные - корректны. На следующем цикле ответы от этого устройства принимаются.
В случаях приёма данных не с первой попытки КС в записанной строчке есть.
Пока хоть что-то в кучке мусора не соответствует критериям определяющим пакет, мусор остается мусором. Как бы чего не казалось и не хотелось. Много чего похоже на кабачковую икру.Цитата:
Сообщение от Василий_S
Хотелось бы увидеть алгоритм проведения запроса и обработки полученного ответа. Неявно это уже звучало:
Вот тут чел тоже подрывался про неработающую железку. Смотрим итог.Цитата:
Сообщение от Вольд
http://www.owen.ru/forum/showthread.php?t=16524
Все таки смущает зависимость КС от времени суток. Вроде чушь, но учитывая что
и то что 90% работы в офисах происходит в первый и последний час )))) как-то закрадываются сомнения, несмотря на отсутствие их у Вас.Цитата:
Сообщение от Вольд
А что это за три критерия ? Сколько линий связей у тебя подходят к ПК ?Цитата:
Сообщение от Василий_S
Жутко некорректное сравнение. Сравнил офис с промпроизводством. И еще ты связываешь два родных ПЛК на короткой ЛС, а Василий_S ПК и кучу ПЛК на длинющих ЛС. Это в корне разные ситуации.Цитата:
Сообщение от Валенок
Вообще ASCII не использую - RTU, а требования жёстче. На складе скоммутировал 600м ПВС без всяких резисторов. Сходил поел. Ошибок 0.Цитата:
Сообщение от Вольд
Есть живые объекты где 100..300м в непонятной куче кабелей (прокладывал не я) - ошибки стремятся к нулю. Опять же - нет резисторов, и часть - звезда.
А родные-неродные ПЛК - а какая разница ? Куча ПЛК ? А без разницы. Пока опробованный максимум - 12 слейвов. Из них 4xПЛК63, там пришлось ковырять по 20-30 параметров из каждого.
Соббсно мысль - проблема мастера. На ПК
Ты в программе для ПЛК можешь напрямую работать с COM-портом, а он в программе для ПК не может.
Почему? COM API - отменили?
ПК - как ПЛК с рандомным циклом где-то в 15-.. мс. Если данные в его буферах не теряются - то какая разница.
У него программа для ПК на VB сделана.Цитата:
Сообщение от ASo
Я тут предлагал Василию проверить работу своей программы на эмуляторе слейва, а так же неплохо бы ОРС поставить, чтоб сравнить как читаются плк, но ему видимо нужно ОВЕН обосрать, других целей этой беседы я не вижуЦитата:
Сообщение от Вольд
Капитан, не надо нагнетать.Цитата:
Сообщение от capzap
Я так понимаю Вы тоже против использования проверенных мастеров, по сбору данных. Самопальный мастер круче штатного слейва плк? Это из-за чего интересно, потому что парень авторитетно заявляет, что у него масса "ловушек"?Цитата:
Сообщение от Вольд
А что такое проверенный мастер в данном случае ? Я думаю, мужик только тем и занимается, что ищет ошибки в своей программе для ПК.
ОРС сервер напримерЦитата:
Сообщение от Вольд
ЗЫ мне процитировать надо, что Ваш мужик уверен в правоте своей программы, а моими советами займется позже?
А куда ему этот ОРС сервер в своей программе присобачить ? Нет у него никакой уверенности, потому и мечется. У него легкая паника, поэтому и посты неадекватные. Я бы на его месте сидел и долбил свою программу до полной победы.Цитата:
Сообщение от capzap
Василий пропал куда-то (но дело его живет)
Ну всяко бывает. Например глаз замылился. Я вот предложил обрисовать алгоритм.Цитата:
Я думаю, мужик только тем и занимается, что ищет ошибки в своей программе для ПК
И какая разница - на каком языке написано. Сериал-порт - место где последовательно появляются байты и утверждается что появились нули в месте КС.
Если какие-то помехи, что возможно, то какие-то избирательные, гурманы так сказать. Едят исключительно КС. Это нормально ?
Вот скажите уважаемый Вольд, какая разница для слейва - кто его опрашивает ? Я могу на ПЛК поменять частоту опроса.
ОС Windows периодически вмешивается в работу прикладной программы (прерывает). Я думаю разберется мужик со своими проблемами, вроде он толковый. А то на форуме периодически такие дятлы появляются, просто страшно становится за Россию.
А причем здесь ПЛК-слейв ?
ПЛК, вероятно, все правильно делает, а вот у приложения для ПК с приемом пакетов-откликов проблемы возникают. А может и с программой ПЛК что-то у него не так. Короче, надо сидеть и разбираться и все у него для этого есть. А нам волноваться особо не стоит.Цитата:
Сообщение от Валенок
Ну так на это и capzap намекает достаточно толсто
За шайбу незасчитанную волнуемсяЦитата:
А нам волноваться особо не стоит
Да, это ужас какой-то, если гол действительно был, а его не засчитали ! А установить истину при нынешних технических средствах не проблема (все ходы записаны). Короче, скандал.Цитата:
Сообщение от Валенок
В общем, получается такая штука. В моменты, когда в ответе из ПЛК в КС стоят нули, сама КС равна 256 в децималах или 100 в хексах (должно ли быть такое вообще?). Т.е. получается, что в КС,в положенные два символа,, при значении равном 100 в хексах, записываются второй и третий символ (нули), а единица куда-то теряется.
Был проведён эксперимент: "ловить" содержимое ответа ПЛК при условии:
1. если в КС стоят два нуля, как хексовские символы;
2. если в КС стоит один ноль, как хексовский символ;
3. если в КС пусто
4. если превышен таймаут ожидания.
При этом в строку текстового файла записывалось:
1. Адрес ПЛК;
2. Время записи;
3. количество повторных запросов к ПЛК;
4. содержимое буфера;
5. отдельно вычисленная КС в децималах;
6. перевод вычисленной КС в хексы;
7. реальные символы из КС;
8. длина буфера;
9. флаг функции вычисления КС (1, если вычисленная КС совпадает с реальной, 0 - если не совпадает)
10. флаг таймаута ожидания (1 - если время превысило уставку, 0 - если нет.)
Результат такой: везде, где в месте КС стоят нули вычисленная КС = 256 в децималах.
Переведённая подсчитанная КС в хексы показывает 0, поскольку функция расчитана на перевод двух символов.
Вырезанная - показывает то, что есть - "00"
При этом длина буфера равна требуемой - 75, ну и флаг по КС равен логическому нулю, да, и флаг по таймауту тоже в нулях.
Пример:
содержимое буфера:
:23 03 20 (0058 0000) (007Е 0000) (00А3 0000) (0006 0000) (0000 0000) (0038 0000) (0003 0000) (0000 0000) 00 ||
, вроде перепечатал без ошибок. В скобках - подсчитанные импульсы на 8-ми входах ПЛК (Hex), жирным шрифтом - содержимое КС
Вычисленная КС = 256(Dec)
Количество повторных запросов - 20 (такая уставка)
длина буфера = 75 - видимо, приём ответа от ПЛК полный и нет записей содержимого буфера в другой файл по событию, если длина буфера меньше 75.
Что получается, ПЛК теряет "1" - первый символ из 100(Hex) и пишет в КС два нуля?
Вот пока в пути и не рядом с компом, появилось несколько вопросов
Модбас аскии чем определяется конец посылки?
Сколько байт занимает контрольная сумма и сколько это в количественном формате отображается в консоли
:) пока все, на телефоне не вижу текст поэтому мысль потерял
Посылка по модбасу в ASCII-режиме заканчивается последовательностью "возврат каретки-перевод строки".
Перед ней КС занимает 2 символа, насколько понимаю.
Приёмное устройство - MOXA CP-114IS/DB9M V1.3 на 4 порта. Может не стыкуется мокса с овеном в "отдельные моменты"?
Блин вроде всё правильно, а при расчете кс инверсия и прибавление единицы делается
И самое главное не вставляется ли высчитанная кс на клиенте в приемный буффер,а потом уже логинится в файл
Может так и задумано в ПЛК Овен, что 256(Dec) представляется двумя нулями и надо иметь ввиду, что это 100(Hex), следующая цифра после FF? Интересно, почему овеновцы молчат?
Вы не катите на овен, есть те же орс серверы модбас, ставим их и смотрим логи, появятся ли там подобные ошибки, поймите алгоритм lrc достаточно прлст, чтоб программист его не смог соблюсти. И чем мусолить эту тему, прлтестируйте свою программу на комп.эмуляторе слейва. Тем более когда у Вас известен весь пакет с нулевой кс, Вы знаете какое/кие числа там находятся и заполнить эмулятор проблем нет и в случае если в течении n-ного времени ошибок не будет,тогда предъявляйте документированную претензию