Страница 4 из 5 ПерваяПервая ... 2345 ПоследняяПоследняя
Показано с 31 по 40 из 43

Тема: СПК207 постоянно зависает визуализация

  1. #31

    По умолчанию

    C target стало всё понятно.
    По появлению ошибок связи 163 (The response is not from the expected Slave) при обновлении на target "с доп.узлами", как я понял, Вы объяснения не знаете, поэтому послали на support. Я больше месяца назад уже обращался туда по другому вопросу, вот до сих пор жду ответа, и номер заявки есть. Была надежда, что хоть Вы прольёте свет. А в TeamViewer вроде и смысла нет, сейчас с ошибками всё гладко (отдельный ФБ их считает, точнее считал).

    Евгений, а может повлиять на появление ошибки 163 с новыми target время цикла MainTask в 50ms? Вроде везде в ваших документации и примерах ставится 20ms. Ранее пробовал изменять настройки связи и MainTask увеличивал, результата не было. Сейчас настройки для 6 модулей МУ110-16К: отправляется битовая маска с циклом 0.5 сек., остальные параметры рекомендуемые - время между фреймами 20мс, таймауты везде 1000мс. Общая длина линии связи 90м., терминалы есть, скорость 38400, в самих модулях настройки по умолчанию.

    В любом случае, хотелось, чтобы потребитель знал, что при апгрейде ПО, может даунгрейдиться функциональность. Хорошо бы, чтобы такие особенности target были где-то указаны, тогда потребитель не будет терять время на "пляски с бубном" вокруг оборудования.

  2. #32

    По умолчанию

    По появлению ошибок связи 163 (The response is not from the expected Slave) при обновлении на target "с доп.узлами", как я понял, Вы объяснения не знаете, поэтому послали на support.
    Безусловно - пока что не знаю. В подобных ситуациях надо разбираться как минимум при удаленном подключении, а это гораздо удобнее делать формализованным способом - через саппорт.

    Евгений, а может повлиять на появление ошибки 163 с новыми target время цикла MainTask в 50ms?
    Может.

    В любом случае, хотелось, чтобы потребитель знал, что при апгрейде ПО, может даунгрейдиться функциональность.
    Вы проецируете вашу конкретную ситуацию на все устройства/все проекты и т.д. Это понятно.
    Но в данный момент я ни могу это не подтвердить, ни опровергнуть, потому что не видел, как это воспроизводится.
    Опять же - в рамках общения с саппортом вы бы могли отправить свой проект, они собрали бы такую же шину у нас и посмотрели, что происходит.

  3. #33

    По умолчанию

    OK, я на следующей неделе добавлю в "пустой проект" с target 3.5.4.26 счетчик ошибок и выложу результаты. Чтобы ни у меня, ни у Вас, ни в последующем у саппорта, не было сомнений, что проект тут ни причём.

    Евгений, буду очень признателен, если Вы объясните как время цикла MainTask может повлиять на появление ошибки связи 163 (Ответ не от ожидаемого Slave)? Можно ссылку, где про это можно прочитать?

  4. #34

    По умолчанию

    Владимир, буду очень признателен, если вы опишите конкретную проблему, которую в данный момент пытаетесь решить.
    Я прошу прощения, но немного потерял ее из виду после фразы

    А в TeamViewer вроде и смысла нет, сейчас с ошибками всё гладко

  5. #35

    По умолчанию

    Экспериментально не обнаружил влияния времени цикла MainTask в 20ms и 50ms на появление ошибок связи 163 с модулями вывода МУ110-16К.

    Евгений, у СПК207[М04][М05] есть некоторые проблемы, в том числе которые пытается решить автор этой темы Dmitro: зависания, ошибки связи, непомерно большое время цикла MainTask, ну и retain - это большая проблема СПК207, которая замалчивается. Решить эти проблемы, именно решить, могут только ОВЕН и 3S, а мы, потребители, можем только как-то обходить их.

    Про зависания и как их обойти писал Владимир Геннадьевич:
    Цитата Сообщение от Владимир Геннадьевич Посмотреть сообщение
    Была аналогичная проблема на объекте: контроллер работал несколько часов или даже сутки, потом происходило зависание панели, не отображались параметры и не работали кнопки. Помогало перезапуск по питанию. При попытки выявить данный дефект выяснилось, что в момент потери связи со слейвами и попытками контроллера программно их перезапустить получалась ситуация что связь терялась сразу со всеми слейвами и контроллер зависал. Методом "научного тыка" выяснили, если в момент зависания выдернуть шлейф из контроллера RS-485 на котором сидят слейвы и обратно вставить, то связь со слейвами восстанавливалась и контроллер начинал опять работать.
    В связи с чем в программу добавили еще код перезапуска мастера сети и все стало работать.
    В моём случае, зависания прекратились, когда я заменил модуль ввода МВ110-16ДН (был он один на com3) на ПР200 и "уволил" из мастеров СПК207, поставив его в slave. ПР200 оказался на голову выше СПК207 в смысле организации связи по RS-485 (и да, это рекламма ПР200). Был такой факт: вначале зависания СПК207 лечились перезагрузкой, а потом опытным путем выяснилось, что если после включения СПК207, его выключить и повторно включить, то в дальнейшем зависаний не возникало.

    Ошибки связи, которые возникали из-за обнаруженных ошибок в ПО, как и обещал Александр Приходько, были исключены в прошивке 5.480. Да, я наблюдал, что ошибки 161 (превышен таймаут) магически пропадают при переходе на эту прошивку.
    Но у меня, как я ранее писал в этой теме, появилась куча ошибок 163 (Ответ не от ожидаемого Slave). Выяснил экспериментально (прошивка 5.480) следующее: на target 3.5.4.26 эти ошибки у меня появились, так как был установлен приоритет VisuTask = 14, после изменения приоритета VisuTask = 31, ошибки 163 пропали; на target 3.5.4.20v24 ни при приоритете VisuTask = 14, ни при = 31 ошибок 163 не было.

    В сообщении #16 Dmitro приводит завышенное время цикла MainTask и будет пытаться "искать задержку" в своём проекте. Очень возможно, что это будет невыполнимая задача, по подобию: "найти чёрную кошку в тёмной комнате особенно если её там нет".
    У меня была подобная ситуация: выяснял почему время цикла MainTask было большим, до 100 ms. Причем переносил абсолютно всю логику в отдельную задачу и макс. время выполнения этой задачи было менее 1 ms. Выяснил, что если в проекте имеется иная кроме MainTask задача с приоритетом <= 15 (включая VisuTask), то время её выполнения влияет на время выполнения MainTask с приоритетом = 1. Увидеть это наглядно можно, когда эта иная задача скачкообразно увеличит время своего выполнения. Например, если приоритет VisuTask = 14, и при переходе на условно "тяжёлый" экран макс. время цикла VisuTask скакнёт с 10 ms до 40 ms, то вместе с ним макс. время цикла MainTask тоже скакнет и будет даже больше 40 ms. Тоже самое, например, с отдельной задачей по чтению и обработке большого файла: ставил приоритет до 15 включительно, макс. время цикла было до 80 ms и макс. время цикла MainTask при работе с файлом скакало соответственно до значений более 80 ms. Задачи с приоритетом более 15 не оказывают такого влияния на MainTask.
    Такое поведение не могу объяснить в рамках вытесняющей многозадачности для овеновских ПЛК/СПК с CODESYS V3.5.
    Получается какое-то зависание MainTask в момент выполнения задач с приоритетом <= 15.

  6. #36

    По умолчанию

    Для наглядности, создал экспериментальный проект с "лёгким" MainTask, второй запускаемой вручную "тяжёлой" задачей HeavyTask, а в визуализации добавил второй "тяжёлый" экран с большой таблицей. Эксперимент проводил так: производил сброс счетчиков цикла всех задач и через 3 минуты делал "грязное дело" - запускал "тяжёлый" функционал.
    Сначала приведу Monitor из конфигурации задач, когда все задачи, кроме MainTask, с приоритетом > 15:
    MainTask (циклич. 20 ms) - приоритет = 1;
    HeavyTask (циклич. 1000 ms) - приоритет = 16;
    VISU_TASK (циклич. 200 ms) - приоритет = 31.
    Прошло 2 минуты после сброса счетчиков цикла:
    (макс. время цикла MainTask = 3.3 ms, HeavyTask = 0.77 ms, VISU_TASK = 11.4 ms)
    6_все задачи с приоритетом больше 15.png
    Непосредственно после перехода на "тяжелый" экран и включения "тяжёлой" HeavyTask:
    (Заметного влияния на макс. время цикла MainTask нет.)
    7_все задачи с приоритетом больше 15 - выполнение тяжелых задач.png
    Изменил приоритеты:
    HeavyTask (циклич. 1000 ms) - приоритет = 9;
    VISU_TASK (циклич. 200 ms) - приоритет = 15.
    Один раз привожу Monitor из конфигурации задач через 2 минуты после сброса счетчиков цикла:
    (макс. время цикла MainTask = 7 ms, HeavyTask = 0.16 ms, VISU_TASK = 3.3 ms)
    0_Monitor после сброса.png
    Перешёл на "тяжёлый" экран:
    (макс. время цикла VISU_TASK = 27.7 ms повлияло на макс. время цикла MainTask = 32.3 ms)
    1_переход на тяжелый экран.png
    Запустил 1 цикл "тяжёлой" HeavyTask:
    (макс. время цикла HeavyTask = 140 ms повлияло на макс. время цикла MainTask = 146 ms)
    2_выполнение 1 цикла тяжелой задачи.png
    Запустил выполнение "тяжёлой" HeavyTask, скриншот через 3 минуты работы "тяжёлой" HeavyTask:
    (макс. время цикла HeavyTask = 138 ms повлияло на макс. время цикла MainTask = 146 ms и видно как сред. время цикла MainTask заметно увеличивается)
    3_постоянное выполнение тяжелой задачи.png
    Ещё один эксперимент. После сброса счетчиков цикла всех задач через 3 минуты вытащил MMC-карту из СПК207:
    (На несколько секунд зависло всё, в том числе связь по RS-485, на подключенном через Ethernet CoDeSys все счетчики цикла замерли, но после зависания скакнуло только макс. время цикла MainTask до 3.2 секунды (были случаи и до 4.6 сек.). При отключении от USB Host такого не наблюдается, в т.ч. пробовал карт-ридер с той же самой MMC-картой).
    4_вытащил MMC-карту.png
    Теперь ошибки 163: В экспериментальном проекте в MainTask (PLC_PRG) ловлю и считаю ошибки связи с шестью модулями вывода МУ110-16К на COM2. Но после экспериментирования с "тяжёлым" функционалом, 163-х ошибок поймалось мало, за пол часа было всего две. Не имея много времени для эксперимента (делал в пересменок), изменил приоритет VisuTask с 15 на 14 и добавил COM3 со slave, как у меня в рабочем проекте.
    Вот, в следующий раз, эксперимент заключался только в ловле ошибок 163:
    (Ровно за час поймал 4 ошибки. Частота появления ошибок вроде не изменилась. Но за 5 рабочих дней на моём рабочем проекте было до 50 на одном модуле.)
    8_Ошибки 163_29.10.2020.png
    Выкладываю используемый мною проект при проведении экспериментов (с последней указаной конфигурацией):
    Вложения Вложения

  7. #37

    Exclamation

    Резюмирую написанное в предыдущих 2-х сообщениях:
    Сначала поясню, откуда взялась тяга к задачам с приоритетом <= 15. В рускоязычном интерфейсе CoDeSys 3.5 SP5 Patch5 для Приоритета в Конфигурации указаны рамки (0..15). Сразу замечю, что в англоязычном интерфейсе рамки (0..31). Так вот, исходя из "рекомендаций" системы и выбираются приоритеты вновь созданных задач <= 15, в т.ч. и для VisuTask. Ведь написано же - до 15!

    Очень даже предполагаю, что Dmitro тоже задействовал задачи с приоритетом до 15, так как MainTask на 78 ms трудновато замутить.
    Dmitro, можно ли озвучить приоритеты задач в Вашем проекте? И проверить, изменится ли ситуация с зависанием, если приоритеты задач (естественно кроме MainTask) поставить > 15?

    Прошу уважаемых специалистов ОВЕН разъяснить результаты проведенных мною экспериментов:
    1. Почему задачи с приоритетом до 15 так влияют на MainTask, вызывая её зависание?
    2. В документе CodesysTaskManagment.pdf есть следующие пояснения по приоритету в CODESYS V3.5:
    "Для контроллеров с ОС Linux с PREEMPT RT Patch задачи с приоритетом 0…15 выполняются с
    классом планирования SHED_FIFO (задачи реального времени), а задачи с приоритетом 16…31 – с
    классом планирования SHED_OTHER. Более подробную информацию о классах планирования и
    работе планировщика Linux можно найти в сети (например, см. эту статью)."
    Справедливо ли это для всех овеновских ПЛК/СПК с CODESYS V3.5?
    3. Почему в рускоязычном интерфейсе CoDeSys 3.5 SP5 Patch5 "рекомендации" системы по приоритету (0..15)?
    4. Почему извлечение карты из интерфейса SD Card, в отличии от извлечения из интерфейса USB Host, приводит к зависанию СПК207 на несколько секунд?
    5. Почему target 3.5.4.26 и приоритет VisuTask так влияют на появление ошибок связи 163?
    6. Александр Приходько в теме "Глобальное обновление ПО для всех СПК, программируемых в CODESYS 3.5 SP5 Patch5" писал про ошибки СПК207:
    Цитата Сообщение от Александр Приходько Посмотреть сообщение
    Обновление на порядок уменьшит ошибки, но полностью не избавит. Помимо программных ошибок есть аппаратная. Ее устраним в СПК207[М05] - об этом уже было написано. Сейчас для пользователей с СПК207[М04] могу дать только такие рекомендации:
    1. Если хорошо программируете, то делайте обмен через библиотеку Modbus. Особенности ее реализации позволяют ошибки свести к минимуму
    2. Если вы будете делать обмен через конфигурацию, то при настройке модулей МХ110 выставляйте параметр RS.DL (задержка ответа по линии RS-485) 30 мс или больше(в конфигураторе МХ110 для ПК). Проблема связана с тем, что СПК не успевает переключаться в режим чтения после отправки. Увеличение периода ответа от самих модулей поможет решить данную проблему. При этом таймаут ожидания ответа должен быть 100-150мс. Данные рекомендации приведены для скорости 115200.
    Предполагаю, что наблюдаемые мною ошибки - это описанные тормоза СПК, который не успевает переключаться в режим чтения после отправки. Что же получается, в СПК207[М05] аппаратная проблема так и не была устранена или модификация СПК207[М04] в [М05] так и не произошла?
    7. У СПК207[М04][М05] не так много энергонезависимой памяти, всего retain 4kB, но и те могут запросто пропасть. Подобных сообщений на форуме много. У меня уже 2-й вылет retain. Из ремонта (замены микросхемы MRAM) СПК207 не проработал месяца, после очередной заливки проекта retain пропала. 1-й раз вылетела после перехода на новейшую прошивку и, естественно, заливки проекта. И если это физическое "убийство" MRAM, то напрашивается предположение о плохой стабилизации напряжения при процессе программирования микросхем памяти. Может ли ОВЕН набраться смелости, признать проблему и хоть что-то прояснить?

    Не хотелось, чтобы описанные выше проблемы СПК207 были списаны по причине снятия его с производства. Указанный СПК был самым отзывчивым (в смысле реакции на нажатия) и быстрым, даже по сравнению с выпускаемым сейчас СПК107[М01]. Хотя, большим недостатком его считаю нестандартное монтажное отверстие, что усложняет его замену.
    Опасаюсь также, что проблемы некогда флагмана фирмы ОВЕН, раз они не выявлены, могут проявляться и у новых овеновских ПЛК/СПК с CODESYS V3.5, представляющих определённый интерес. И нет желания опять попасть на зависающие продукты ОВЕНа. Отсюда вопрос уважаемым специалистам ОВЕН и участникам форума: наблюдаются ли описанные мною проблемы у новейших ПЛК2хх и СПК1хх[М01]?

  8. #38

    По умолчанию

    1. Почему задачи с приоритетом до 15 так влияют на MainTask, вызывая её зависание?
    Я бы не стал здесь использовать слово "зависание", но, безусловно, задачи влияют друг на друга.
    Добавление "тяжеловесной" задачи с приоритетом реального времени действительно отразится на времени цикла остальных задач.
    У вас это вызывает удивление?..

    2. Справедливо ли это для всех овеновских ПЛК/СПК с CODESYS V3.5?
    Да.

    3. Почему в рускоязычном интерфейсе CoDeSys 3.5 SP5 Patch5 "рекомендации" системы по приоритету (0..15)?
    Банальная опечатка, в свежих версиях поправили (теперь там 0..31).

    4. Почему извлечение карты из интерфейса SD Card, в отличии от извлечения из интерфейса USB Host, приводит к зависанию СПК207 на несколько секунд?
    Вы извлекаете накопитель на горячую, без размонтирования?

    5. Почему target 3.5.4.26 и приоритет VisuTask так влияют на появление ошибок связи 163?
    На этот вопрос я не готов дать ответ.
    У меня встречный вопрос:
    "Но за 5 рабочих дней на моём рабочем проекте было до 50 на одном модуле" - получение 10 ответов с кодом ошибки за сутки является серьезной проблемой в рамках вашей системы?

    6. Предполагаю, что наблюдаемые мною ошибки - это описанные тормоза СПК, который не успевает переключаться в режим чтения после отправки. Что же получается, в СПК207[М05] аппаратная проблема так и не была устранена или модификация СПК207[М04] в [М05] так и не произошла?
    Я не готов ответить, была ли проведена доработка вашего прибора (возможно, вы можете уточнить это у сервисного центра, если доработка проводилась в рамках ремонта), но в СПК207 [М05] не наблюдалось проблем с RS-485, характерных для [М04]. С другой стороны, вы могли столкнуться с другой проблемой, которая проявляется аналогичным образом.

    У меня встречный вопрос - вы пробовали проводить ваши эксперименты на "пустом" проекте (только компоненты Modbus и подсчет ошибок), без "тяжеловесных" задач, манипуляций с приоритетами и т.д.?

    7. Может ли ОВЕН набраться смелости, признать проблему и хоть что-то прояснить?
    Проблемы с RETAIN в СПК207 периодически возникали, но это всегда были единичные случаи, без систематики (непропай т.п.).
    К сожалению, прояснить что-то здесь я не могу.

    Не хотелось, чтобы описанные выше проблемы СПК207 были списаны по причине снятия его с производства.
    К сожалению, у нас нет планов по доработке / исследованиям проблем приборов, снятых с производства.

    наблюдаются ли описанные мною проблемы у новейших ПЛК2хх и СПК1хх[М01]?
    Давайте мы предоставим вам СПК107 [М01] на бессрочное (сколько потребуется) тестирование?
    И тогда вы сами сможете ответить на этот вопрос. =)

  9. #39

    По умолчанию

    Евгений, спасибо за ответы, но могли бы Вы переадресовать вопросы, на которые не в компетенции ответить, разработчикам ПЛК/СПК с CODESYS V3.5?
    1.
    Цитата Сообщение от Евгений Кислов Посмотреть сообщение
    Добавление "тяжеловесной" задачи с приоритетом реального времени действительно отразится на времени цикла остальных задач. У вас это вызывает удивление?..
    Ещё бОльшее удивление у меня вызывает Ваш ответ. Я нигде не акцентирую, что влияют на MainTask только "тяжелые" задачи. Я писал, что любая задача с приоритетом до 15 влияет на время цикла MainTask, увеличивая его, что в принципе при вытесняющей многозадачности не может быть! Я запускал условно "тяжёлые" задачи по команде, чтобы это влияние было хорошо заметно. Время выполнения задачи HeavyTask в моём проекте для экспериментов можно изменять, попробуйте, и увидите, что с любым временем задача HeavyTask (обязательное условие - приоритет до 15) будет тормозить MainTask.
    Посмотрите 1-й и 3-й скриншоты моих экспериментов без выполнения "тяжелого" функционала. Макс. время цикла MainTask = 3.3 ms, если остальные задачи с приоритетом > 15 и макс. время цикла MainTask = 7 ms, если остальные задачи с приоритетом <= 15. И это один и тот же проект! Тут же можно увидеть, что макс. время цикла VISU_TASK = 11.4 ms (приоритеты > 15) и = 3.3 ms (приоритеты <= 15). И эти результаты стабильные. Получается какая-то вытесняющая многозадачность наоборот! Во втором случае (приоритеты <= 15) задача VISU_TASK с меньшим приоритетом вытесняет задачу MainTask с большим приоритетом. Да, для меня это нонсенс! В первом случае (приоритеты > 15) все логично с точки зрения вытесняющей многозадачности.
    Кроме того, влияние задач с приоритетами до 15 избирательно, друг на друга они никакого влияния не оказывают (см. 4, 5, и 6 скриншоты). Зависает исключительно MainTask.
    Уважаемые специалисты ОВЕН, разъясните, пожалуйста, зависание (увеличение времени цикла, вопреки вытесняющей многозадачности) MainTask (только MainTask!) при наличии иных задач с приоритетом до 15.

    4.
    Цитата Сообщение от Евгений Кислов Посмотреть сообщение
    Вы извлекаете накопитель на горячую, без размонтирования?
    В моём проекте для экспериментов нет функционала с размонтированием. Причём ранее я лично интересовался у Александра Приходько на семинаре о необходимости такого функционала. Он его не рекомендовал, единственное условие для извлечения - отсутствие обращения к накопителю. В представленном проекте для эксперимента отсутствует функционал работы с накопителями вообще. И здесь, в вопросе, я указываю дополнительно на различие извлечения накопителей из интерфейсов SD Card и USB Host. Извлечение накопителя из интерфейса USB Host никакого влияния на работоспособность проекта не вызывает, в отличии от извлечения накопителя из интерфейса SD Card, приводящего к зависанию СПК207 на несколько секунд. Уважаемые специалисты ОВЕН, разъясните ситуацию.

    5,6.
    Цитата Сообщение от Евгений Кислов Посмотреть сообщение
    С другой стороны, вы могли столкнуться с другой проблемой, которая проявляется аналогичным образом.
    Евгений, можно поподробнее, пожалуйста?
    Отвечаю сразу на "встречные вопросы". Эксперимент по ловле ошибок связи можно сказать как раз и был на "пустом" проекте - ошибки были пойманы при выключенной задаче HeavyTask и без перехода по экранам. И я не замечал влияния "тяжёлого" функционала на появление ошибок связи, они "живут" своей жизнью. Да, и на полностью "пустом" другом проекте с приоритетом VisuTask = 14 ошибки были, наблюдал красные треугольнички на модулях Modbus. А про манипуляцию с приоритетами я что-то не понял, чтобы поменять приоритет надо вроде обновить проект, что в рамках одного эксперимента невозможно. У меня получилась явная зависимость появления ошибок связи от target и приоритета VisuTask. Причем target 3.5.4.26 и приоритет VisuTask = 14 исключительно любят ошибки связи 163, на приоритете VisuTask = 15 были и ошибки 161. Может статистика не полная, но на рабочем проекте (target 3.5.4.26 и приоритет VisuTask = 14) на протяжении продолжительного времени я наблюдал очень частые исключительно ошибки 163; с приоритетом VisuTask = 31 на target 3.5.4.26 всё изумительно, но не так много времени наблюдал. Вопросы про ошибки связи я поднимаю не потому, что у кого-то есть проблема в рамках системы, а потому, что по заверениям "фирмы" "в СПК207 [М05] не наблюдалось проблем с RS-485, характерных для [М04]". А наш СПК207 отправлялся в сервис как раз для модификации в [М05], и есть бумажка, в которой написано о проделанных соответствующих манипуляциях.
    Поэтому вопросы к специалистам ОВЕН остаются: по влиянию target 3.5.4.26 и приоритета VisuTask на появление ошибок связи 163; по исправлению в СПК207[М05] аппаратной проблемы, влияющей на появление ошибок связи, она так и не устранена или модификация СПК207[М04] в [М05] является неполноценной?

    7.
    Цитата Сообщение от Евгений Кислов Посмотреть сообщение
    Проблемы с RETAIN в СПК207 периодически возникали, но это всегда были единичные случаи, без систематики (непропай т.п.).
    Очень странный ответ, словосочетания "периодически возникали" и "единичные случаи" мне кажутся несовместимыми. А случаи, как видно по сообщениям форума, ну не единичны.
    И все-таки, могут ли специалисты ОВЕН прояснить ситуацию с вылетом retain у СПК207?

    Цитата Сообщение от Евгений Кислов Посмотреть сообщение
    К сожалению, у нас нет планов по доработке / исследованиям проблем приборов, снятых с производства.
    Я не прошу у ОВЕН подобных жертв и как раз таким ответом на перечисленные проблемы СПК207 просил "не отфутболивать".
    Важно для все ещё пользователей СПК207 разъяснения по приведенным проблемам, чтобы их хотя бы грамотно обходить, а не плясать с бубном вокруг оборудования. А для современных ПЛК/СПК с CODESYS V3.5 хотелась работа над ошибками и исключения, извиняюсь за выражение, "косяков" старых приборов. Если с современными приборами всё хорошо, то я очень рад, но судя по предварительным ответам Евгения, особенно по 1-му вопросу, есть сомнения.

    Цитата Сообщение от Евгений Кислов Посмотреть сообщение
    Давайте мы предоставим вам СПК107 [М01] на бессрочное (сколько потребуется) тестирование?
    И тогда вы сами сможете ответить на этот вопрос. =)
    Евгений, спасибо за предложение. Но я не очень представляю, как я вместо СПК207 воткну СПК107? Монтажные отверстия приборов сильно отличаются. А Вам или другим участникам форума, думаю не сложно будет залить в современные ПЛК/СПК с CODESYS V3.5 представленный мною проект, или поэкспериментировать со своим проектом и произвести описанные мною манипуляции. А вытащить накопитель из интерфейсов SD Card и USB Host можно без изменений проекта, просто подключившись к ПК для мониторинга. Результатом и будет ответ на мой вопрос: наблюдаются ли описанные мною проблемы у новейших ПЛК2хх и СПК1хх[М01]?

  10. #40

    По умолчанию

    могли бы Вы переадресовать вопросы, на которые не в компетенции ответить, разработчикам ПЛК/СПК с CODESYS V3.5?
    Хорошо.

    Причём ранее я лично интересовался у Александра Приходько на семинаре о необходимости такого функционала. Он его не рекомендовал, единственное условие для извлечения - отсутствие обращения к накопителю.
    Тут мне сложно дать комментарии - возможно, Александр неверно выразил свою мысль, или не понял вопрос, или это было настолько давно, что у него еще не было точной информации об особенностях работы с накопителями. Не думаю, что сейчас он бы дал такой ответ.

    Извлечение накопителя из интерфейса USB Host никакого влияния на работоспособность проекта не вызывает, в отличии от извлечения накопителя из интерфейса SD Card, приводящего к зависанию СПК207 на несколько секунд. Уважаемые специалисты ОВЕН, разъясните ситуацию.
    USB и SD - это разные устройства, которые обрабатываются разными драйверами, у которых разные приоритеты прерываний.
    Поэтому извлечение разных типов накопителей оказывает разный эффект на работу контроллера.

    Но я не очень представляю, как я вместо СПК207 воткну СПК107?
    Я не предлагал вам использовать его вместо СПК207. Просто имея на руках прибор - вы могли бы довольно быстро получить на некоторые ваши вопросы ответы, в которых вам не пришлось бы сомневаться.

    А вытащить накопитель из интерфейсов SD Card и USB Host можно без изменений проекта, просто подключившись к ПК для мониторинга.
    В четверг повторю ваш опыт на СПК1хх [М01] и отпишусь по результатам. По изучению влияния цикла задач друг на друга - проверю, когда будет время.

    Евгений, можно поподробнее, пожалуйста?
    Я не очень понимаю, какие подробности нужны в рамках моего комментария; по-моему, его смысл однозначен.
    Мне, например, не очень понятно, как вы почти в соседних предложениях сочетаете фразы "....аппаратной проблемы, влияющей на появление ошибок связи, она так и не устранена или модификация СПК207[М04] в [М05] является неполноценной?" и "с приоритетом VisuTask = 31 на target 3.5.4.26 всё изумительно".

Страница 4 из 5 ПерваяПервая ... 2345 ПоследняяПоследняя

Похожие темы

  1. ТРМ202 постоянно зависает
    от Tempest в разделе Эксплуатация
    Ответов: 14
    Последнее сообщение: 28.12.2018, 10:58
  2. Зависает визуализация СПК207
    от Roman29 в разделе СПК2хх
    Ответов: 17
    Последнее сообщение: 27.10.2017, 15:51
  3. Зависает визуализация СПК107
    от Denis_ в разделе СПК1хх
    Ответов: 9
    Последнее сообщение: 30.12.2015, 12:24
  4. СПК207 Зависает Ethernet
    от rs485 в разделе СПК2хх
    Ответов: 16
    Последнее сообщение: 28.05.2014, 00:00
  5. визуализация СПК207
    от san_diablo в разделе СПК2хх
    Ответов: 1
    Последнее сообщение: 26.06.2013, 01:13

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •