dm37

по С++ обновил описание https://ru.files.fm/u/a2sfccuf#/list/ файл uC_cpp.7z

У вас всё работает так как вы и написали. Т.е. если не сбрасывать PacketIDX, то при выборке из второго массива будет считываться не элемент 0, а элемент 4 можно, как вариант сделать так: unsigned char *PacketPntr = NULL; // static int PacketIDX = 0; // static int packet_switch = 0; int dataLen = 0; // //printf("\nPacketType = %d:", PacketSwitch);// printf("\nAsking NByte = %d:", ch); // if(packet_switch != PacketSwitch) { PacketIDX = 0; packet_switch = PacketSwitch; } ...

Мои наработки по использованию языка C++ для микроконтроллеров: -микроконтроллеры ATtiny2313, ATmega32 -компилятор IAR Embedded Workbench for Atmel AVR 6.80 -симулятор Proteus 7.10 Что получилось можно посмотреть здесь https://ru.files.fm/u/a2sfccuf#/list/ файл uC_cpp.7z Внутри: - пример с динамической индикацией (исходники + proteus) - пример с LCD на HD44780 (исходники + proteus) - небольшое описание

Подразумевается, что доходишь до команды return и если условие выполняется, то дальше код можно не смотреть

"Буратино", всё таки предложу ещё раз посмотреть книжку Андрей Александреску "Современное проектирование на C++" и всё что с ней связано (у людей уже есть наработки в этой области - приводил выше), Прочитайте стр.17 (предисловие) - написано прямо то что вы хотите. книга

Тоже есть опыт использования продукции Овен, есть работающие проекты на ПЛК63, ПЛК100 + СП270. Отношение конечно плохое. ПЛК у Овен получились не очень. Что не понравилось: - в ПЛК крепления верхней платы идёт (шло) на пластмассовых винтах, которые быстро ломались (после покупки сразу меняли на металлические). Элемент питания для RTC тоже сразу меняли (почти всегда были старые или не рабочие) - если программировать через RS232, то постоянно терялась связь со средой разработки. Использовать переходники UBS-COM тоже не получалось (ПЛК критичны к уровням RS232), даже ноутбук со встроенным RS232 глючил, пришлось в цех тащить плату c COM-портами и вставлять в обычный ПК. Где то на форуме Овен говорили, что ПЛК110 лучше держат связь со средой разработки при отладке. - панель оператора СП270. Конфигуратор (IDE) без предупреждений просто отказалась открывать проект, который создавался несколько дней. Как потом опытным путём выяснил - количество элементов отображения какого то типа (не помню уже какого) превысило 255. После этого проект умирал без предупреждений. Писал про этот глюк на форуме, но мне разработчики панели так ничего и не ответили. - Теперь ПЛК63: в спецификации указан доступный пользователю объём RAM. Создал массив элементов с учётом данного размера, загружаю в ПЛК, ПЛК виснет. Хорошо есть комбинация из трёх пальцев, позволяющая вернуть ПЛК к жизни. В итоге выяснилось, что доступный объём меньше чем указано. В общем ПЛК Овен работает, если у вас всё же хватит терпения довести проект до конца. У нас уже несколько лет работает и проблем вроде нет. Только СП270 всё же глючит при отображении (сейчас её вроде уже не выпускают). Среда разработки CodeSys 2.3, язык ST, многофайловые поддерживаются. Стандартное меню в ПЛК63 не использовал, сделал своё. После мучений с Овен по возможности несложные проекты стали делать на ПЛК Delta (дешёвые ПЛК, которые применяются на производстве), правда среда разработки не поддерживала язык ST (не знаю как сейчас).

если исполнитель должен заботиться о защите линий по входам 220V, то я скорее выберу свой вариант преобразования из 220V в 24V (с защитой) и возьму обычный модуль дискретного ввода, в противном случае получается необоснованный огород. В принципе мы так и делаем.

С++ для микроконтроллеров. в первую очередь эта статья http://easyelectronics.ru/rabota-s-portami...erov-na-si.html и примеры к ней https://github.com/KonstantinChizhov/Mcucpp/tree/dev Многие будут отсылать к книге Андрея Александреску "Современное проектирование на С++", но как то пока сложновато. тоже в основном смотрю в этом направлении, пробую как раз для AVR (8 бит). Задача стоит иметь расход RAM (а потом и Flash) аналогичный применению с использованием Си. Для себя сделал вывод, что для uC необходимо (желательно) использовать шаблоны классов со статическими членами, тогда вроде всё получается...

В своё время рассматривали Schneider Electric Modicon M340 (BMX XBP 1200 + BMXP342020 + ...)

Занимался как раз задачами автоматизации птичника (более 10 лет). Расскажу с чем мы столкнулись. Как показала практика все системы должны быть распределёнными (как минимум допускать расширение), либо связаны по сети (диспетчеризация). Готовые системы не устраивают не зависимо от производителя, должен быть индивидуальный подход. Минусы использования ПЛК (тип не имеет значение): 1) ОЧЕНЬ дорого, особенно по нынешним ценам; 2) в качестве датчиков температуры использовали DS18B20 (DS18S20). Ни один нормальный ПЛК не поддерживает данный тип датчиков (городить что то по modbus не очень хороший вариант) 3) частично лицензионный софт 4) иногда быстродействие, как ни странно (например, при реализации фазоимпульсной модуляции) 5) модули для контроля входов 220V как правило с трудом выдерживают режим работы 24/7 (приходится опять городить что-то свое). При разработке основная проблема была с нехваткой портов ввода/вывода, а также памяти (как RAM так Flash), как говорили уже здесь быстродействия вполне хватало (в ОСРВ потребности не было). В итоге даже начинал рассматривать вариант разработки своего ПЛК (хотели переделать ПЛК Delta, они дешевле и используют STM32 (правда среда разработки плохая, нет ST) либо сделать что-то своё аналогичное, платы можно заказать в Китае). По поводу требований заказчиков - в итоге мы (заказчики) забрали разработку софта себе, а разработчик оборудования поставлял только железо. Вот так. Скрипты не нужны, иначе вас заставят отвечать за ошибки в оборудовании (как вы собираетесь доказывать, что виноват скрипт, а не основной софт). Лучше создать железо и базовый софт и продать это всё заказчику, если у них есть кому сопровождать, пускай сами делают всё под себя, можете даже провести обучение. Если нет, поддержка у вас и ни в коем случае не давать дополнительных возможностей в виде скриптов (сломают). Помню как мы по несколько раз в неделю бегали в цех для восстановления параметров блока, пока начальник цеха не наказал их рублём за шаловливые ручки. Речь в данной теме шла о софте: итог (моё мнение) - всё равно придётся плодить версии под каждого заказчика (заказчик всегда прав), единственно, что можно это попробовать решить за счёт конфигурации блока (недоступной заказчику). Правда я немного не понимаю почему у вас это сводится к изменению ПО, как правило оно тянет за собой и изменение аппаратной части.

в своё время рассматривал в основном два метода кодирования сигнала манчестер и вроде 4b/5b, почитайте о них.

Один из первых проектов был похож на ваш (RXQ1-433 + AT90S2313 + IAR, любительская разработка, использовали на своём предприятии для телеметрии). Правда нам пришлось ввести байтстаффинг для устойчивой синхронизации начала пакета и заточен на наш протокол. Т.е. пока устройство не примет весь пакет, не проверит crc, не передаёт его по rs485 (ну и так же обратно). Код, конечно, не идеальный (давно это было в 2003), но устройство рабочее и можно посмотреть как мы это реализовали тогда. radio.7z

Подскажите, где то описано (ГОСТ,...) , что необходимо проводить повторные испытания на климатику, ЭМС и т.д. для оборудования подвергшемуся модернизации (небольшие аппаратные изменения, в том числе изменение монтажа, установка дополнительных или удаление плат, блоков, реле...). p.s. оборудование используется в энергетике В тех. решении, по которому проводилась модернизация, нет упоминания о повторных испытаниях.

to АНТОХА дак никто же этого не отрицает Уверен, что почти каждый будет проверять работу RS485 без растяжек с True Fail-Safe. Правда, если это потребует переделку софта, то не везде это применишь (совместимости не будет). P.S. Просто, если человек спрашивает, то нужно объяснять (пусть даже 2+2=4), для этого и существует форум. В своё время был очень хороший форум на telesys.ru, правда потом он стал полем разборок "профессионалов". Начинающих просто "забивали". Не хотелось бы здесь увидеть подобную манеру общения.

в архиве cport310 есть файл readme.txt всё (правда по английски) написано а если кратко, то так (на примере Delphi 7): - открываем в Delphi файл cport-3.10\sources\CPortLib7.dpk - в открывшемся окне "Package - CPortLib7.dpk" жмём кнопку "Compile" - закрываем окно "Package - CPortLib7.dpk", но запрос "Сохранить" жмём "Нет" - открываем в Delphi файл cport-3.10\sources\DsgnCPort7.dpk - в открывшемся окне "Package - DsgnCPort7.dpk" жмём кнопку "Compile", потом "Install" - закрываем окно "Package - DsgnCPort7.dpk", но запрос "Сохранить" жмём "Нет" - проверяем на вкладке компонентов наличие вкладки "CPortLib" - все файлы cport которые будет требовать компилятор копируем из cport-3.10\sources\ в C:\Program Files\Borland\Delphi7\Projects\Bpl\, как правило это *.dcu, *.dfm, *.pas, CPort.inc, CPortImg.res вроде всё

to zltigo для информации во вложении со страницы 22 и дальше... отвечать вам не буду - бесполезно. Что хотел сказать, сказал выше. Каждый остаётся при своём мнении. Обсуждения не получается. И вопрос к модераторам: хамство здесь разрешено? Modbus_over_serial_line_V1_02.pdf

to zltigo Надеюсь вы погорячились требуя стандарт на MODBUS с подтяжками (знаю, что вы понимаете, что такое протокол и интерфейс). Речь шла о том, что большинство поставщиков оборудования с RS485 используют подтяжки. И если вы доработаете схему блока до вашего варианта, не факт, что он вообще работать будет и кому вы тогда будете предъявлять претензии - MOXA, Advantech? А заказчик требует что-бы работало. И ваши доводы, по поводу кривых рук разработчиков из MOXA, ему будут не интересны. Скорее всего он сделает "не правильные" выводы. P.S. Кстати, разработчики из MOXA ещё те ребята, любят совмещать выходные линии RS485 и RS232. При такой схеме включения частенько вылетает драйвер RS232 и соответственно RS485 перестаёт работать. Приходиться резать дорожки или выбрасывать драйвер RS232.

немного в поддержу juvf Если вы работаете по протоколу modbus по RS485, будьте добры придерживаться стандартов (использовать подтяжку A и В), в противном случае оборудование сторонних разработчиков ваши изыски по RS485 не поймёт. Если вы разработчик всей системы (и мастера и слейва), то зачем вы вообще используете modbus. Вы нашли способ, используя драйверы RS485 с True Fail-Safe, повысить надёжность передачи данных на большие расстояния - это замечательно, но не надо навязывать своё решение всем, тем более грубить. Напишите статью на эту тему и поделитесь своими наработками. Например здесь http://www.analog.com/media/en/technical-d...otes/AN-960.pdf на стр. 7 есть описание RS485 с True Fail-Safe, где сказано, что используя новые драйверы отпадает необходимость использовать подтяжку А и В, значит ранее такая необходимость была? На стр. 6 приводится расчёт резисторов подтяжки.

Промышленное оборудование, обычно, позволяет выбирать как настроить измерительный канал: пассивный или активный (в настройках), правда не всё оборудование это поддерживает. Иногда есть выбор и напряжения питания 24В, 48В. Т.е. как приёмник может быть активный или пассивный, так и передатчик может быть активный или пассивный. И довольно часто подобное оборудование не правильно подключают: в петле порой оказывается либо два пассивных устройства или, что ещё хуже, два активных устройства, порой и с разными напряжениями. То что петлю питает потребитель это вообще как то странно, на какой стороне стоит генератор тока, тот и питает, причём здесь закон ома? По закону ома ток в цепи будет одинаковый, вне зависимости от расположения генератора тока. А вот при передаче дискретных сигналов цепь в основном питает приёмник

т.е. вы подключаетесь к какой либо паре устройств работающих по modbus (запросы отправляете не вы) и задача стоит разобрать протокол (синхронизироваться)? если да, то можно со сдвигом принятых данных считать crc и где crc верна, там и есть начало пакета. Определить "запрос" или "ответ" можно уже по протоколу.

Можно принимать байты по одному с таймаутом, т.е. таймаут только на приём одного байта. Пока синхронизация приёма пакетов не нарушилась работаем только с crc, если нарушилась, то устанавливаем таймаут равный времени приёма одного байта + небольшой запас (не помню интервал тишины в modbus, вроде три байта). Если передача идёт по стандарту modbus, то таймаут на два-три байта тишины должен помочь

посмотрите это: http://www.chipdip.ru/catalog-show/digital...k&sort=hits как вариант за ваши деньги http://www.chipdip.ru/product/dso5102bm/ и по круче с логическим анализатором http://www.chipdip.ru/product/mso5102d/

Изначально кнопок было 6 (влево-вправо-вверх-вниз-ENTER-ESCAPE). Количество кнопок можно сделать любое от 1 до 8. Функции на кнопки назначаются в каждом меню отдельно, так что всё зависит от вашей фантазии. Если вам нужно именно ваше сочетание кнопок, могу подкорректировать и выслать вам на почту, чтобы не плодить версии. Во вложении проект с 6-ю кнопками (выжимка из одного проекта) + работа с датчиком DS18B20 + RTC DS1307 (i2c soft). ds1820.7z

В проектах avr_menu исправлена небольшая ошибка (из-за copy/paste), которая не позволяла вывести регистры вывода 74HC573 из третьего состояния. Также добавил видео демонстрирующее функционал проекта avr_menu https://ru.files.fm/u/a2sfccuf#/list/ avr_menu.7z

Демонстрационный пример AVR_Menu2 Описание примера: Пример, показывает вариант построения многоуровневого меню для текстовых LCD индикаторов на базе контроллера HD44780, управление с помощью клавиатуры (8 кнопок), приём 16 дискретных сигналов, передача 16 дискретных сигналов. В состав проекта входят исходные коды на языке C и проект для Proteus. Оборудование: - ATmega32; - LCD 1604 (HD44780); - клавиатура (8 кнопок: Up, Down, Left, Right, Enter, Escape, Menu, Reserve); - 2 регистра ввода (74HC245); - 2 регистра вывода (74HC573); - зуммер. Программное обеспечение: - среда разработки: IAR Embedded Workbench 6.70.4 (AVR) - среда эмулирования: Proteus 7.10 ------------------------------------------------------------------------------- Пароль для доступа в меню настроек: нажать кнопку Menu и последовательно нажать кнопки Left -> Right -> Up -> Left -> Right avr_menu1 (LCD4004) - вариант с LCD индикатором 40x4 (2xHD44780) Дополнительно небольшое видео работы проекта в proteus по ссылке: https://ru.files.fm/u/a2sfccuf#/list/