Добрый день, подскажите, почему при установке связи с ПЛК в проекте выходит сообщение "PLC2: stopped" контроллер один в проекте откуда взялся второй ?? Искал в форуме ничего подобного не нашел..
Заранее спасибо.
Вид для печати
Добрый день, подскажите, почему при установке связи с ПЛК в проекте выходит сообщение "PLC2: stopped" контроллер один в проекте откуда взялся второй ?? Искал в форуме ничего подобного не нашел..
Заранее спасибо.
Как при этом ведет себя сам ПЛК?
Добрый день. Подскажите надо ли беспокоиться по этому поводу или нет. Во время работы ПЛК110-60-К-М В Кодесис появилось предупреждение
Вложение 15440
при этом ПЛК продолжал работать и даже сеть по RS485 функционировала (через библиотеку). Через некоторое время (не сразу) убрал это окно и появилось другое
Вложение 15441
Как я понял контроллер временно остановил работу, а потом снова сам запустился. Модуль Button в конфигураторе не добавлял, пока идет отладка на столе. Сеть работатет через библиотеку.
ПЛК остановился и запустился.
Случаи самоостановки из-за дребузга кнопки при отсутствии модуля Button были, случаи самозапуска нет.
Обмен по RS485 идёт всегда, это не показатель.
P.S. Вы случаем не используете доступ к конфигурации через %Qххх.ххх? В этом случае компилятор CoDeSYs не отслеживает распределение ОЗУ этой области, а судя по M-модификации переменных у Вас много - можно легко вылезти за пределы настроек размеров ОЗУ в таргете.
Обмен у меня идет не через конфигурацию, а через библиотеку. Поэтому если ПЛК станет, то и обмена не будет.
Таким способом использую доступ к входам и выходам ПЛК. Я их объявил в глобальных переменных для удобного переноса на другой контроллер в случае необходимости.Цитата:
Вы случаем не используете доступ к конфигурации через %Qххх.ххх?
Есть еще слэйв в конфигурации на данный момент около 20 регистров, но это еще не все, будут еще добавляться. Доступ к нему через указатели. То есть имеется структура, в которую в начале цикла ПЛК считывается содержимое конфигурации слэйва, а в конце цикла записывается содержимое структуры обратно в конфигурацию.
Гопак по граблям - экстрим-версия . Доступ к I/O через абсолютные адреса + указатели в программе == гарантия проблем.Цитата:
Сообщение от amn
А уж доступ к конфигурации по указателю - компилятор CoDeSys просто закрывает глаза на все проверки и нажимает на газ, что записывается, куда записывается, можно ли, есть ли выравнивания....А так как компилятор протестанты писали - русский Авось не прокатывает.Цитата:
Сообщение от amn
Владислав, Вы хотите сказать, что даже если все внимательно проверено, выравнивание и все такое, то рано или поздно проблемы будут все равно? В компиляторе есть ошибки, из-за которых указатели работают непредсказуемо? Если я объявил входы/выходы в глобальных переменных, то в каких ситуациях будут проблемы? Расскажите подробней, а то я все проекты так делаю. Входы/выходы не проблема объявить в самой конфигурации, их не так уж и много, но не хотелось бы отказываться от указателей, очень удобно добавлять/удалять/переставлять регистры для конфигурации, а их будет много. Но если дело настолько серьезно, то надо срочно все переделывать.
Отсутствие проверок (а компилятор не проверяет указатели и доступ по абсолютным адресам) провоцирует к опискам. А работа с указателями вдвойне опасна, т.к. указатель может принимать любое значение.
Еще опаснее работа с конфигурацией как с массивом, доступным по указателю. Одиночное чтение 1 параметра не по указателю безопасно, т.к. по сути является атомарной операцией.
Как пример проблем - пользователь использовал доступ по абсолютным адресам и превысил лимит ОЗУ на конфигурацию, заданный в таргете. Хотя у него была M версия, но размер области можно регулировать, а он этого не сделал, т.к. компилятор не предупредил его об этом (при доступе по абсолютным адресам проверок размера областей I/O не осуществляется). Как результат его мастер или slave стал работать с областью ОЗУ за пределами области конфигурации и портить данные в ней. Ошибка плавающая, т.к. поведение зависит от данных, записываемых в эту область. Наблюдались самопроизвольные остановки, зависания, порча данных, изменение алгоритма работы.
Другой пример - пользователь обращался к конфигурации как к массиву по указателю. И неверно учёл смещения данных. При этом он обращался к невыровненным данным как к выровненным, что вызывало исключительную ситуацию в процессоре и перезагрузку.
Ещё пример - опять указатели и обновление программы в режиме "online change" пользователь не отслеживал такой режим и ожидал что ПЛК сам поменяет значения указателей на таблицы констант (или вообще об этом не думал) - как результат указатели указывали не туда после смены ПО.
Т.о. работать так, конечно можно, но если делать надежное ПО с длительным циклом сопровождения - лучше не использовать указатели и использовать символьные имена переменных. Благо import/export конфигурации + текстовый редактор позволяют легко переносить и изменять конфигурацию не теряя настроек и символьных имён.