Имитация модулей ввода-вывода для удобной отладки

[Нидвораич]

Приветствую :)
Прошу пнуть в нужном направлении, дальше я сам :)
У меня есть СПК и два модуля МУ и МВ.
Несмотря на то, что они стоят рядом на столе - коммутировать их выходы в процессе отладки совершенно неудобно.
Хочу написать имитатор этих модулей.
Требования к нему:
1) графический интерфейс с возможностью переключать состояния входов мышкой
2) работа по модбасу, чтоб не надо было в спа каждый раз что-то перенастраивать для отладки. Подключился к живым модулям - работаем с живыми, подключился к имитатору - работаем с ним.

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

Отсюда вопрос: какой общий порядок действий должен быть?
Я создал проект СПК107, там создал модбас девайс, прописал ему адрес как у реального модуля, регистры, вроде бы, прописал.
Через эмулятор компортов создал связать двух виртуальных ком-портов.
Запустил два виртуальных контролёра:
1) с моим рабочим проектом
2) с модбас девайсом этим

Симулятор ком-портов увидел, что к нему подключены два устройства.
Но модуль ввода Овена в моём проекте не загорается зелёным даже. Адреса прописаны верно, скорости выставлены одинаково.

Может, для успешного соединения обязательно нужно корректно прописать регистры в имитируемом устройстве?

Или вообще вся эта эпопея обречена на провал по каким-то причинам, до которых я ещё не успел дойти?
Заранее спасибо за подсказки :)

[1exan]

Не очень понятна цель:
Если нужно отладить связь или устранить проблему - то лучше использовать реальные модули.
Для отладки алгоритма проще сделать блок эмуляции нужных значений внутри программы, отключив опрос модулей

[kondor3000]

Гораздо удобнее для этих целей использовать ОРС сервер, например MasterOPC Universal Modbus Server,
может быть слейвом, можно назначить нужные адреса регистров и задать любые значения. Проверить обмен по ТСР и RS485 с любым адресом слейва.

[Sergey361]

Может, для успешного соединения обязательно нужно корректно прописать регистры в имитируемом устройстве?

Ну вообще надо. Возможно даже буфер обмена посмотреть и понять, в чем проблема

[melky]

Можно написать в RapidScada и привязывать к ее каналам. Язык C#. могу поделиться модулем (он до конца не дописан, но уже работоспособен) для запуска программ. Имитирует работу ПЛК (ну или если разобраться чего угодно)...

Есть у разработчика платный Modbus slave. Если нужен именно Овен протокол, надо писать (нету, да и нужен ли?)...

з.ы. модуль не тот, про который эти доки https://drive.google.com/drive/folders/1PRusPYejvrFQi02ixsFt782RbUPfzFTa но суть та же. Называться будет ModSoftPlc, стоить будет дешевле, а базовая версия Free (будут некоторые ограничения)
Тут можно посмотреть как выглядит программа https://github.com/Manjey73/ModFarm_View/blob/master/ModFarm.Shared/ProgramZ.cs

В общем велкам, если кому интересно. Сотворить можно любой эмулятор, в том числе и с постоянно изменяющимися значениями. Там по тексту доки есть уже изменения. Теперь запуск не в потоках, а в задачах. Можно будет выбирать dll с программой для запуска.

[AlexandrGr]

82863
Можно так делать.
М10.0 - включен режим эмуляции входов.
Работает на S7-1200 S7-1500 S7-200 SMART(скрин с него).

[Валенок]

Если про rs485 110й то двумя скрепками соединить Rs1 и Rs2, наколотить нужных слейвов, вот и вся эмуляция
С tcp да, не прокатит, нет петлевого интерфейса. Но другой ПЛК, а остальное тоже самое

[Нидвораич]

Спасибо всем за ответы. Я почему-то не увидел, что тему уже опубликовали. И сам уже себе помог :))
Более суток ковырял эту тему, разобрался с регистрами и прочим.
Модуль ввода не подключался по причине того, что он хочет запросить в сумме 29 слов, а я создавал устройство слейва, где не было столько регистров.
Модулю вывода для счастливой жизни достаточно всего одного регистра, потому он и работал без проблем.

Ещё раз поясню мои мучения:
У меня семь контакторов шнеков управляются по показаниям весов. Для отладки мне надо имитировать ответ контактора о замыкании, вовремя тыкать туда-сюда эти самые контакторы, плюс имитировать процесс увеличения веса...
Вручную это делать очень неприятно и сложно.
Приходится загрублять все тайминги, чтоб успевать руками нащёлкать нужные состояния в MasterOPC Universal Modbus Server (естественно, я про него знаю).
Но при загрублении таймингов сильно уходят показания измеряемой скорости насыпания. Плюс - я постоянно в голове держу не отладку, а порядок тыкания кнопочек.
У меня было открыто три окна:
Кодесис с отлаживаемым проектом.
Кодесис с имитацией весового модуля.
Модбас этот описи сервер универсал с имитацией модулей через теги.

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

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

В общем и целом - я набрёл на ФБ OCL.MB_SerialSlave, который в коде, без лишних бубнов поднимает слэйв устройство. Опять же - на одном порту две штуки поднять нельзя, но можно сделать так, чтоб этот слэйв отзывался на любой ID. А дальше мне тупо повезло, что в двух моих модулях не пересекаются адреса хранения данных о состоянии выходов.
Соответсвенно - по наводке Евгения Кислова я просто завёл слэйв с общим адресным пространством для обоих своих модулей.
И вот щас всё работает. Теперь я в этот же проект могу добавить свой имитатор весового модуля, чтоб он сам включался по выходам модуля вывода. И ответку контакторов я теперь тоже могу автоматизировать, а не руками тыкать, поглядывая в таблицу на соответствие контакторов и выводов... И расположить все кнопки управления я теперь тоже могу так, как они физически на заводе стоят, а не в столбик из этих тегов в этом модбас матьего описи сервере)


Если кому интересно - вот код с максимально подробным описанием:



(* ДИСКЛЕЙМЕР.
Спасибо Евгению Кислову за пинок в нужное время в нужном направлении :)

Работа примера основана на примере 5.9.2 из документа
CODESYS V3.5 Настройка обмена по протоколу Modbus Руководство пользователя 04.08.2023 версия 3.2
Под шаблоном я буду иметь в виду готовый шаблон Модбас устройства от компании Овен.

ОБРАЩАЮ ВНИМАНИЕ!!!!!!! Весь этот финт ушами с двумя слейвами одовременно возможен лишь потому, что
конкретно у этих двух приборов не пересекаются адреса хранения состояний выходов.
Если адреса пересекаются - то нужно будет определять, какое устройство сейчас долбится к нам за данными
и класть в буфер данные для СЛЕДУЮЩЕГО по адресу устройства. Потому что ФБ выдаёт адрес устройства, которому уже всё отдал.
По словам Евгения - мастер опрашивает устройства по порядку, так что можно нахитрить в этом направлении.
Примерный алгоритм: составляем массив адресов своих устройств, на первой итерации баним их всех, чтоб не отдать кому-то не то.
Запоминаем, кто к нам долбится, смещаемся по своему массиву вправо от полученного адреса и кладём в буфер нужные СЛЕДУЮЩЕМУ устройству данные.
Разбаниваем все устройства, работаем. Но это прокатит только если между адресами имитируемых устройств нет адресов реальных устройств.
Иначе всё собъётся. Короче, к сути.

В примере реализован функционал имитации работы модуля ввода MV110_16_D_DN и модуля вывода МУ110-16R_K
Эти два названия я взял из названий готовых шаблонов модулей из пакета от Овена.
По факту у меня дискретные приборы, и меня интересовали лишь две возможности для отладки:
1) для модуля вывода - заиметь на визуализации лампочку, которая загоралась бы, когда выход модуля активен
2) иметь на визуализации кнопку, по нажатию которой имитируется замыкание входа модуля ввода.

Счётчики, ШИМы, показания датчиков мне не нужны, поэтому в этом примере они не реализованы. Но по идее - частично обработать инфу возможно.

*)
PROGRAM PLC_PRG
VAR
fbComControl: OCL.COM_Control; // ФБ управления портом COM1
fbModbusSerialSlave: OCL.MB_SerialSlave; // ФБ для реализиации модуля вЫвода
usiID: USINT;
(* Чо ваще тут происходит
в ходе экспериментов выяснилось, что шаблон модуля ввода MV110_16_D_DN работает только в случае, когда под него выделено не менее 29 байт:
см.инструкцию от модуля, "Таблица А1 - Регистры Modbus".
Он опрашивает регистр с адресом 51, забирая оттуда битовую маску значений входов. Это как раз одно слово для 16 входов.
И ещё ему ну прям никак не обойтисть без доступа к регистрам с адресами 64..79, откуда он берёт значения счётчиков импульсов.
Мне они не нужны, но без выделения под них памяти ничего не работает (имитируемый модуль висит в офлайн или мигает туда-сюда в попытках подключения).
Так как регисты в памяти должы быть расположены последоватьельно - нужно будет выделить 79-51+1=29 слов памяти.
(+1 - потому что 2-1=1, но по факту количество 2)
Шаблон модуля вЫвода MV110_16_D_DN прекрасно работает при одном выделенном для него слове.
Повторю - меня инстересует только состояние дискретных выходов, поэтому минимально необходимое количество WORD для моего случая = 1.
Насколько я понял - считывание состояния происходит с того же регистра (могу ошибаться).

Итого мы имеем: шаблон ввода хочет иметь дело с регистром 50 (1 шт). Шаблон вывода - с регистрами 51-79 (29 шт).
На самом деле - на данном этапе адресация регистров не важна. Важно именно их количество. В моём случае 30 шт.

Везение заключается в том, что у двух этих модулей не пересекаются адреса нужных нам регистров.
Соответственно - их можно расположить в памяти в таком порядке:
IN - это будет регист модуля ввода
IN01..16 - регистры счётчиков модуля ввода, без которых он жить не может
OUT - регист модуля вывода.

01 OUT
02 IN
03
04
05
06
07
08
09
10
11
12
13
14
15 IN01
16 IN02
17 IN03
18 IN04
19 IN05
20 IN06
21 IN07
22 IN08
23 IN09
24 IN10
25 IN11
26 IN12
27 IN13
28 IN14
29 IN15
30 IN16
Чтобы не путаться с нулевой адресацией и количеством - адресацию массива данных я буду начинать от 1, а не от 0.

*)

awSlaveData: ARRAY [1..30] OF WORD; // буфер данных Modbus Slave

(* в моём случае это не нужно, потому что у меня нет регистров, которые читаются и пишутся обеими участниками обмена.
Если такое есть - нужно тут в коде писать данные в такие регистры не циклично, а по необходимости.
Иначе цикличная запись будет постоянно затирать принимаемую инфу. Так делать фу.
xWrite: BOOL; // команда записи данных из программы в регистры Modbus Slave
fbWriteEdge: R_TRIG; // триггер для однократной записи
*)
axIN: ARRAY [1..16] OF BOOL; // массив состояний входов модуля ввода. Привязаны к тумблерам
axOUT: ARRAY [1..16] OF BOOL; // массив состояний выходов модуля вЫвода. Привязаны к лампочкам
END_VAR







// поднимаем COM порт с нужными настройками
fbComControl
(
xEnable := TRUE,
udiComPort := 33,
udiBaudrate := 19200,
udiByteSize := 8,
eParity := OCL.COM_PARITY.EVEN,
eStopBit := OCL.COM_STOPBIT.ONE
);
//запускаем слейва с адресом 255. Это позоляет ему отвечать на запрос с любым ID.
fbModbusSerialSlave
(
(* насколько я понял - начальный адрес является обманом для опрашивающего устройства.
Когда оно просит регистр с адресом 50 - мы ему подсовываем свой самый первый регистр,
и все остаются довольны. То есть - это смещение адресации на уровне нашего кода тут.
Если бы не было этого параметра - пришлось бы тут в коде создавать область памяти,
в которой первые 49 слов банально не использовались бы.
А так - у нас шаблон модуля вывода хочет видеть данные на 50 адресе,
шаблон модуля ввода - на 51, и мы просто указываем смещение в 50:
чтоб вместо 50 выдать то, что лежит у нас в первой ячейке, а вместо 51 - то, что во второй.
50 51 64 ... 79 - шаблоны модулей думают, что читают по этим адресам
OUT IN IN01 IN16 - вот эти данные
1 2 15 30 - на самом деле - данные у нас лежат вот с такими индексами.
*)
c_uiStartAddr:=50,
xEnable :=fbComControl.xActive,
hCom := fbComControl.hCom,
usiSlaveId := 255,
pData := ADR(awSlaveData),
szSize := SIZEOF(awSlaveData)
);

// сорян за хардкод :) Уже некогда разбираться с преобразованиями
// в первой ячейке у нас лежат состояния вЫходов (которые обманным образом транслируются под видом регистра с адресом 50)
axOUT[1]:=awSlaveData[1].0;
axOUT[2]:=awSlaveData[1].1;
axOUT[3]:=awSlaveData[1].2;
axOUT[4]:=awSlaveData[1].3;
axOUT[5]:=awSlaveData[1].4;
axOUT[6]:=awSlaveData[1].5;
axOUT[7]:=awSlaveData[1].6;
axOUT[8]:=awSlaveData[1].7;
axOUT[9]:=awSlaveData[1].8;
axOUT[10]:=awSlaveData[1].9;
axOUT[11]:=awSlaveData[1].10;
axOUT[12]:=awSlaveData[1].11;
axOUT[13]:=awSlaveData[1].12;
axOUT[14]:=awSlaveData[1].13;
axOUT[15]:=awSlaveData[1].14;
axOUT[16]:=awSlaveData[1].15;

// во второй - состояния входов

awSlaveData[2].0:=axIn[1];
awSlaveData[2].1:=axIn[2];
awSlaveData[2].2:=axIn[3];
awSlaveData[2].3:=axIn[4];
awSlaveData[2].4:=axIn[5];
awSlaveData[2].5:=axIn[6];
awSlaveData[2].6:=axIn[7];
awSlaveData[2].7:=axIn[8];
awSlaveData[2].8:=axIn[9];
awSlaveData[2].9:=axIn[10];
awSlaveData[2].10:=axIn[11];
awSlaveData[2].11:=axIn[12];
awSlaveData[2].12:=axIn[13];
awSlaveData[2].13:=axIn[14];
awSlaveData[2].14:=axIn[15];
awSlaveData[2].15:=axIn[16];

[Нидвораич]

Не очень понятна цель:
Если нужно отладить связь или устранить проблему - то лучше использовать реальные модули.
Для отладки алгоритма проще сделать блок эмуляции нужных значений внутри программы, отключив опрос модулей

Хотелось без переделок рабочего проекта сделать полную имитацию устройств. Я уже знаю, как в проекте понять, где он запущен - на рабочей железке или на виртуальном контролере.
И да, знай бы я заранее, сколько гемора я хапну с этой имитацией - я бы так сделал - просто завёл бы ёщё одну визуализацию и повесил бы её на веб-морду. И со второго монитора тыкал бы всё, что мне нужно.
Это реально проще и удобнее. Почему-то я упёрся рогом в имитацию работы по сети, и вот доупирался до результата :)

Ну зато я покопался в Модбасе. Ещё позавчера для меня модбас и rs-485 представляли что-то одно и то же примерно :)))

[melky]

Пока не изучал код.
1. Так понимаю там привязка через шаблоны + использование каких-то fb. Ставить CodeSys 3 не планирую, своего Г хватает на компе.
2. Каким образом вы создаете эмуляцию? все на виртуальных ПЛК CodeSys ? нужна работа по реальным COM портам? не помню, можно ли натравить виртуальный COM порт на другой виртуальный, не пробовал ни разу
3. на COM порту должно быть несколько имитируемых устройств ?

Если рисунком сделаете как хотите, чтобы понять можно ли это организовать на одном ПК.

4. Что нужно от имитируемых устройств? ну например модуль вывода какой-нибудь MX110 или модуль ввода, или аналогового ввода ?
5. какая нужна скорость работы модулей ?

з.ы. давайте начнем с простого модуля, например вывода - марка/модель
чтение маски выходов, запись выхода - что еще нужно? например какая видуализация? где ручное управление, где автоматическое?

[Нидвораич]

Пока не изучал код.


0. Спасибо, не заморачивайтесь :)
Изначально я упёрся в то, чтоб рабочий проект оставался без каких-то доработок периода отладки. Поэтому всю периферию хотел сделать совершенно отдельно - во втором проекте или в какой-то сторонней программе. На тот момент я ещё не представлял всех сложностей и ограничений, с которыми столкнусь.
На сегодняшний момент - выше описанный код позволяет мне успешно имитировать работу двух модулей: МУ110-224.16Р и МВ110-224-16ДН.
Я могу в отладочном проекте имитировать входы модуля ввода одним щелчком мыши в удобном мне месте, реагировать на выходы модуля вывода программно (я в курсе про скрипты в ОПС модбас сервере, но это дичь). В этот же отладочный проект я добавил имитацию весового модуля, который шлёт в основной проект данные по RS-232.
НО. Ещё раз повторю - у этого способа есть только один плюс - мне никак не надо переделывать основной рабочий проект. Для него вся периферия - что железная, что имитированная, видится и работает одинаково.
А теперь о минусах:
а) мне тупо повезло, что эти два модуля имеют разную адресацию регистров. Если бы имели одинаковую или пересекающуюся (например, у меня был бы модуль вЫвода не на 16, а на 32 контакта) - ничего не прокатило бы.
б) каждый раз для отладки приходится запускать программу Virtual Serial Ports Emulator и в ней настраивать связь двух виртуальных портов - для 232 (весовой модуль) и 485(модули ввода и вывода).
в) каждый раз приходится запускать вторую копию виртуального контроллера, чтоб на нём крутился проект имитации.
Сейчас я бы просто в своём рабочем проекте сделал отдельную визуализацию с имитацией нужных мне железяк и повесил бы её на вёб-морду, вытащив её на второй экран компа. Да, основной проект пришлось бы переделать. Но это заняло бы куда меньше времени.



1. Так понимаю там привязка через шаблоны + использование каких-то fb. Ставить CodeSys 3 не планирую, своего Г хватает на компе.

1. Да, слева в рабочем проекте - шаблоны, справа в имитируемом - ФБ, создающие слэйв устройство.
82901


Пока не изучал код.
2. Каким образом вы создаете эмуляцию? все на виртуальных ПЛК CodeSys ? нужна работа по реальным COM портам? не помню, можно ли натравить виртуальный COM порт на другой виртуальный, не пробовал ни разу


2. Я создал вируальный ПЛК, в нём через ФБ открыл порт 485 и через ещё один ФБ создал виртуальный слейв, отзывающийся на любой айдишник. Далее в программе Virtual Serial Ports Emulator создал виртуальную связь между компортом рабочего контролера и имитирующего.



3. на COM порту должно быть несколько имитируемых устройств ?
Если рисунком сделаете как хотите, чтобы понять можно ли это организовать на одном ПК.


3. Это одна из проблем.Я не нашёл, как можно на одном компорту заиметь более одного слэйв устройства в одном проекте, поэтому реализовал через "универсальный" слэйв.



4. Что нужно от имитируемых устройств? ну например модуль вывода какой-нибудь MX110 или модуль ввода, или аналогового ввода ?


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



5. какая нужна скорость работы модулей ?


5. Любая - у нас не критичны задержки какие-то в доли секунд

Так что не заморачивайтесь) Создавая пост, я хотел получить наводку на какой-то метод удобной отладки проекта. В целом - теперь понимаю, что проще всего просто в одном проекте реализовать режим отладки с имитацией нужных мне данных.
Так что спасибо большое за готовность помочь :))

[melky]

да мне самому иногда надо, пригодилось бы. Только не знаю как к этому подойти.
Я могу запустить сколько угодно модулей в/в и по идее на одной линии связи. Так или иначе виртуальные COM порты создавать придется. Единственное, их можно создать один раз и забыть, например в Tibbo VSP или USR-IOT виртуал COM порт.

4. да это вроде не проблема в визуализации Scada. На счет имитации связи надо подумать, связь она или есть, или ее нет :)

[МихаилГл]

Че все так сложно... Я для такого параллельно ввел в программу наладочный режим. Ну и переключатель режима. Если он включен, то все "поле" имитируется кнопками на экранной форме, нсли нет, то с входов.

Но это актуально только для однотипных механизмов, есть такой минус. Но если программа у вас универсальная, то этот минус исчезает.

Скрин приложил бы визуализации для одного из тысячи механизмов, но пк недоступен...

[EFrol]

Вероятно, здесь каждый придумал свой собственный способ отладки сложных проектов.
Если позволите, расскажу о своём.
В OPC Lectus можно на один порт повесить несколько ведомых узлов (устройств).
В каждом узле можно создать свою Modbus-таблицу. После запуска все регистры доступны для редактирования.
В лог-окне можно наблюдать, как и в какой последовательности ПЛК (или ПР) опрашивает эти узлы.
У меня есть панель СП310, в которой в удобном виде созданы элементы для имитации всех параметров ТП.
В Lectus'е есть возможность переносить считанные значения из Master-узла (который опрашивает панель) в Slave-узел,
т.е. Lectus из этой панели сам переносит имитируемые значения параметров в регистры имитируемых узлов.
Кстати, вместо панели можно подключать и реальное устройство, значения его регистров будут переноситься в регистры иммитируемого.
Это оказалось очень удобно: слева - реальный или виртуальный ПЛК (или ПР), справа - панель, где задаются параметры виртуально процесса.
СП310 подключаю через ModbusTCP - скорость отладки увеличивается в разы.

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

[melky]

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

Скажем так, когда вы думаете о CodeSys и языке ST - это одно. А вот когда вам надо это сделать для ПЛК, где только FBD или LD - ну добавьте в такой ПЛК еще и отладочную часть программы. Вот будет весело, особенно делать отладку для отладочного кода :)

[МихаилГл]

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

Скажем так, когда вы думаете о CodeSys и языке ST - это одно. А вот когда вам надо это сделать для ПЛК, где только FBD или LD - ну добавьте в такой ПЛК еще и отладочную часть программы. Вот будет весело, особенно делать отладку для отладочного кода :)

У меня нет как такового отладочного кода, есть подмена входных сигналов. Код один, но на входах либо реальные, либо имитируемые.

Но в последнее время я стал эту часть удалять, ибо заказчики несут всякий бред, не вникая в суть, и я решил расширенный код им просто не выдавать. Ну вот такой я нехороший человек!)

[melky]

На объекте и не должно быть никакого отладочного кода. Ну или спрятанный так, что о нем будете знать только вы.
Ну на этапе пнр одно, я говорю об окончательном коде.

[МихаилГл]

На объекте и не должно быть никакого отладочного кода. Ну или спрятанный так, что о нем будете знать только вы.
Ну на этапе пнр одно, я говорю об окончательном коде.

Не соглашусь. У нас на австрийском оборудовании есть режим симуляции для отладки без датчиков.
И я не собирался ничего скрывать, это было даже в документации мной описано.

[melky]

Но в последнее время я стал эту часть удалять, ибо заказчики несут всякий бред, не вникая в суть, и я решил расширенный код им просто не выдавать.

просто сталкиваясь с квалификацией обслуживающего персонала на объектах - это более верное решение, не выдавать расширенного кода :)
я об этом... Меньше знают, крепче спишь :)

[capzap]

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

Скажем так, когда вы думаете о CodeSys и языке ST - это одно. А вот когда вам надо это сделать для ПЛК, где только FBD или LD - ну добавьте в такой ПЛК еще и отладочную часть программы. Вот будет весело, особенно делать отладку для отладочного кода :)

Как обычно какой то бред, создание себе сложностей, чтоб потом героически из преодолевать, а нельзя между основными кодом и физическими входами выходами переменные не на прямую прокладывать а через прокладку, которая легко меняется на такую же только от симуляции, надо тестируй, надо работай в реале,в чем сложность то, язык программирования тут вообще на последнем месте

[Нидвораич]

Че все так сложно... Я для такого параллельно ввел в программу наладочный режим. Ну и переключатель режима.

вот этот код избавит Вас от переключателя :) он сам определяет, где запущена программа - на реальном ПЛК или на виртуальном контролере.



wsVendorNameOfVirtualKontroller :WSTRING:="3S - Smart Software";
xInit: :BOOL:=TRUE;


IF xInit THEN
SysTarget.SysTargetGetVendorName(pwszName:=ADR(wsV endorName), pnMaxLength:=ADR(udiVendorNameLeng));
//определяем, где ща крутится прога. На реальноё курве или на виртуальной бобре
IF OSU.WFindSubstringPosAfterN( wsSource:=wsVendorName, wsWhatToFind:=wsVendorNameOfVirtualKontroller, uiSearchFrom:=1) = 1 THEN
xOTLADKO_MODE:=TRUE;
ELSE
xOTLADKO_MODE:=FALSE;
END_IF
xInit:=FALSE;
END_IF

[МихаилГл]

Никогда не использовал виртуальный плк, мне всегда хватало эмулятора из меню онлайн...

[melky]

capzap а физический вход или выход на удаленном модуле, И ?
в моем случае в качестве удаленного модуля выступала плата шлюза кондиционера в Modbus, без кондиционера НЕ РАБОТАЕТ, кондиционеры еще не смонтированы. Придумывай как будешь тестировать сам называется.

а как-то 6-ть кондеев на стол водрузить совсем не то же, что 6-ть модулей MX110

[capzap]

capzap а физический вход или выход на удаленном модуле, И ?
какую мысль Вы здесь пытаетесь донести? Мы здесь говорим о замене физических устройств на эмуляцию, уже пришли к общему мнению что демо-режим для отладки предпочтительнее делать в одном проекте, удаленный коннект ни какой роли не играет и только Вы на своей волне, то про запрет на кокой то код отладки на реальном объекте, сейчас вместо эмуляции какой то ящик хотите себе на стол поставить что бы что? Если не знаете логику работы устройства которое нужно подключить к контроллеру и не можете с имитировать его работу, не чего и браться за такую работу, меньше повода будет ныть что Вас окружают дебилы программисты ПО и разработчики железок

[melky]

capzap не все можно выжать при отладке без реального обмена и скорости работы. В любом случае любую программу вы потом доводите на объекте на реальном железе, нет?
Вот прямо все можете добиться в эмуляции? В смысле речь о той эмуляции, где вы говорите понажимать несколько кнопок в течении 1 секунды.

по поводу отладочных частей программы, ну как бы есть разница, когда у вас ST и вы просто обходите код стороной, и когда у вас FBD, где код все равно исполняется, увеличивая цикл программы.

[capzap]

не все можно выжать при отладке без реального обмена и скорости работы. В любом случае любую программу вы потом доводите на объекте на реальном железе, нет?довожу, к реальному обмену и скорости работы это не относится


о той эмуляции, где вы говорите понажимать несколько кнопок в течении 1 секундыгде я такое сказал, это были не мои слова, на них я предложил функциональный блок который, один, хоть каждый цикл будет менять состояние четырех бит, если таких ФБ два то восемь и т.д.


когда у вас ST и вы просто обходите код стороной, и когда у вас FBD, где код все равно исполняется, увеличивая цикл программына сколько, на условные 200мкс?

[melky]

А5-25, да какая разница в имитации переменных в программе, если проблема проявляется именно в опросе этих переменных с устройствами?
То есть логика ок, эмуляция одним устройством (ПР200) ок. а вот нескольких под руками не было, пришлось ждать когда все соберут. А потом просто потеря времени на поиск причин.

Эмулятор мог бы помочь решить проблему раньше, но это не точно конечно.

[capzap]

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

[melky]

вы мыслите только CodeSys-ом или типа Siemens-ом, а в мире есть еще куча других ПЛК, где средства отладки мягко говоря далеки от возможностей указанных.

любую программу это какую? которая при этом еще может выполнить поведение того или иного устройства не вручную

[capzap]

а в мире есть еще куча других ПЛК, где средства отладки мягко говоря далеки от возможностей указанных.
Я мыслю что Вам надо идти в таком случае на те форумы этих контроллеров и там высказывать свое авторитетное мнение

[melky]

тема была не о контроллере, а об имитации модулей ввода вывода однако. Какой при этом человек использует контролер? да начхать. Овен, Сименс, Дельта и т.д.
И тема не о проверке потери связи с модулем.

[МихаилГл]

Подеритесь еще тут...

Кстати, иногда и эмуляция не поможет, т.к. реальное железо работает не так, как ты думаешь, и даже так, но иногда по другому. Был у меня случай с ИП320... На столе работает, на объекте работает, но почему то не всегда адекватно, оказалась, что с модбас у этого устройства не все так хорошо, пришлось делать обход этого глюка.
В плк слэйве по разному обрабатывал команды с ип320. Одна обработка начала то работать, то нет. Оказалось ип320 контрольную посылку делает, или чтото вроде этого. Писал я тут уже про это год назад. Весело было, когда перед отъездом с объекта вдруг пульт перестал на некоторые кнопки реагировать, я уж думал они отказали... Полчаса не мог понять что не так.

[Нидвораич]

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

https://owen.ru/forum/showthread.php?t=35385&p=364957&viewfull=1#post364957

[melky]

Нидвораич да, я видел ту ссылку, но так как работаю в RapidScada хотел сделать на ней, к тому же есть реализованное решение по запуску программ и привязки к каналам. Нужен только код, который будет эмулировать устройство, организованный циклом while или do/while

[capzap]

я тут тихонечко оставлю ссылку на ещё одно решения для эмуляции нажатий, срабатывания дискрет в эмуляции плк
https://disk.yandex.ru/d/HEHM9AD1WL13jQ

[kondor3000]

я тут тихонечко оставлю ссылку на ещё одно решения для эмуляции нажатий, срабатывания дискрет в эмуляции плк
https://drive.google.com/file/d/13a1kClvONidpeIxCVqVgkg1nb0rFL9qP/view?usp=sharing

Ссылка просит ввод мыла и пароля

[Сергей0308]

У меня не просит:

82979

[Нидвораич]

я тут тихонечко оставлю ссылку на ещё одно решения для эмуляции нажатий, срабатывания дискрет в эмуляции плк
https://disk.yandex.ru/d/HEHM9AD1WL13jQ

это не совсем то. Подобное можно было и на модбас сервере организовать. Изначально я имел в виду УДОБНОЕ и визуально понятное расположение элементов управления.
83128
Вот, например, у меня сейчас кнопки на имитаторе расположены точно так же, как на заводе. Лампочки - это сигнал от моего ПЛК. Тумблеры - это для имитации сработки оборудования.
Мне одного взгляда достаточно, чтоб понять, какой контактор сейчас просится в работу. И одним нажатием я могу сымитировать его работу.
И это пока что модель, где есть 7 контакторов и весовой модуль. Дальше их станет под 20 шт. И когда это всё расположено в столбик, как у Вас на примере - это боль.
83129

тем более - в моём случае я могу любой дискретный выход расположить рядом с любым дискретным входом на визуализации имитатора. Я совершенно не обязан запоминать их адреса в приборе.
Вижу лампочку - тыркаю тумблер или жму кнопку возле неё. ОЧЕНЬ удобно.
А со всеми этими списками в столбик - нужно постоянно в голове соотносить адресацию и назначение. Ужос

[capzap]

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