И снова здрасте,

Чтоб понять, как на каком уровне Вам давать ответы, я так и не поучил от Вас ответ на на н.у. мой вопрос, в идеале
профиль на linkedin.com

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

Важно понять и я это каждый раз Вам здесь говорю, платформа не ставит перед клиентами цель и не декларирует свою универсальность с возможностью ее интеграции в стандарт IEC-61131.

Это абсолютно иное направление (программный симулятор на базе ПК с процессорной архитектурой CPU CISCx86), ее пользователями являются разработчики автоматизированных решений, робототехники и смарт систем без использования внешней аппаратной логики на базе ARM DSP, PLC и т.д.

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

Не пытайтесь здесь в теме "натягивать курицу на глобус".

Мне очень понравилась эта публикация в оригинале, которая даст, Возможно и Вам, ответы на многие свои вопросы. Эту статью уже подхватили многие русскоязычные копирайтеры и IT писатели, но суть одна. Хотите читайте, не хотите, дело Ваше.

А собственно вот и ее русскоязычная версия
Soft PLC и дилемма инноватора.

Приятного погружения.

Задача поставлена до неприличия просто.
Чтоб дать четкий ответ мне нужны дата шиты того, что осталось после кончины PLC, или как минимум их фирменные наименования для самостоятельного поиска их описания, так же и детальная топология системы.
Сразу ограничиваю хотелки, это не должно быть станочное оборудование типа CNC, которое требует предельно высокую точность управления в реальном времени. Это не наше.
Разного рода автоматические линии или сопутствующие процессы производства, такие как QC, V&V сколько угодно, можно во всех отраслях от животноводства, до космоса...

Beep насколько помню, linkedin у нас в блоке, хотя вроде был там когда-то аккаунт, но нафик не нужен...

Ответ на вопрос был неоднократно, CodeSys и иже с ним с языками МЭК61131
А так же писал, да и хрен бы с ним, с этим МЭК, но у вас нет никакой возможности связывать уровни, локальный с верхним, либо с еще более нижним, потому что вы уперлись только в свои платы, не давая никакого шанса для простора.

По поводу счетчиков хочу напомнить, что мы в России и ваши сертификаты с ебея, алибабы тут полный НОЛЬ. Мало того, у нас поставщики в разных регионах не допускают всего многообразия, разрешенного в России а требуют только узкий список из возможных.

Систем много и разных, чаще всего использование в них именно PLC, а не SoftPLC. Хотите влезть не только в узкую специализацию, делайте выводы.

Вам тут ничего не надо, кроме понимания, что все модули ввода вывода работают через Modbus протокол, документация на модули есть у производителя, все карты регистров доступны. Все... Остальным этого достаточно, требуется только замена мозга и написания под него программы, не только включил/выключил, но и возможно Пид регулирование. Предположим это система вентиляции, где процессы не быстрые, никаких станков.
То есть не ваша забота, какую периферию применять (модули в/в, датчики)...

Учитывая что у вас нет поддержки каких либо открытых протоколов, вами задача без полной замены всей периферии не решается, на этом все. Заказчик ПРОТИВ решения все снести и построить заново.

и вы не поверите, но например вот этот ПЛК https://owen.ru/product/plk210 дефакто является SoftPLC

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

Кратко, что такое CodeSys:
CoDeSys, среда программирования, ориентированая на изготовителей контроллеров. Разрабатывая новый контроллер, они устанавливают в него систему исполнения CoDeSys Control. Собирают из ее компонентов требуемую конфигурацию, добавляют собственные ноу-хау и специфические компоненты и получают собственное инструментальное ПО. Как правило, к пользователю CoDeSys попадает в коробке вместе с оборудованием, иногда и нет. Ему нужно установить систему и перейти к решению своих практических задач. Все коммерческие и технические вопросы, связанные с поддержкой ядра контроллера, всех типов его аппаратных модулей, библиотек, стеков и конфигураторов сетей должно быть решено за него разработчиками ПЛК и CoDeSys совместно.

И в этом весь парадокс последнего утверждения, и конфликт интересов между разработчиками альтернативных платформ автоматики и картельнм сообществом где балом правит ITQ GmbH.
Можете это назвать глобальной закрытой политикой и договорняками, с пожинанеим плодов стратегий захвата рынка под проприоритарныe решения.
Этот факт есть результат медленных темпов интеграции автоматики и робототехники в те отрасли, которые по роду своей деятельности не могут себе позволить бюджеты как на начальном этапе проектирования, так и на стадии эксплуатации, Т.к. темпы окупаемости там не такие как в приоритетных для ПЛК отраслях.
Многие попытки самостоятельных разработчиков построить свою более комфортную скаду на низкоруровневых языках имели отрицательные истории, некоторые даже присутствуют и на Вашем хабре. Если найду дам линк.

Разработчики альтернативных платформ, в поисках обходных путей не связаны жесткими требованиями производителей и могут выйти за пределы протоколов управления и сбора данных, как и работа непосредственно с ядром встраиваемого софта на любых, доступных им языках в своей, более расширенной среде программирования, строить удобные пользовательские визуальные абстракции интерфейсов и управлять буквально любым внешним распространенным семейством микропроцессоров от 16 до 64-разрядных, к примеру посредством UART.
Кто работает с ним, правит миром процессорной техники.
Но, как я выше говорил, разработчикам платформ, которые содержали бы террабайты данных с SDK от производителей процессорной автоматики во всем многообразии, замыкается на открытых политиках производителей и их желанием скинуть это их ноу хау в открытый доступ в облака. Это утопия, а разрабам как мы, жизни не хватит,
чтоб построить все FSM в протоколе модбус с интерфейсами под пользователя, который визуально без необходимости опыта в тех 9 МЭК языках, построит код и будет им управлять непосредственно с ПК, без загрузки в память сторонней процессорной логики в т.ч. и ПЛК.

Поэтому мы написали свои конечные статические и динамические автоматы под простые B/B ADC/DAC комплекты, к которым можно напрямую подключать драйверы нагрузок и сбора данных, при этом всю управляющую часть на всю вычислительную производительность ПК CISC.
Интерфейсы могут напрямую работать с большинством датчиков и сенсоров которые применяются и в промавтоматике.

Т.к. Вы пользователь CodeSys, мне понятно и то, что вы не знакомы с мега количеством DAQ устройств, это не проста линейка устройств сопряжения ПК с внешним миром, это другая планета где ПЛКшники инопланетяне.






Я вне политики, это сугубо ситуация в которой оказалась Ваша страна.



Выводы выше.
И да, мы несколько опережаем время, когда ПК целиком заменят картельные технологии, как в вое время это произошло с созданием ПК и альтернативных ОС.

Боже, где вы берете весь этот бред?

Хорошо, пример вам проще, вы делаете системы весов? Вот есть у некоего заказчика весы, которые САМИ посылают пакеты данных, их надо ловить и расшифровывать.
Без вас (как разработчика системы) я такие весы не подключу, а надо чтобы я сам взял и написал в системе элементарщину и не ждал от вас манны небесной, когда вы соизволите это сделать...

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

И вот про Modbus, ну хватит уже нести ваш бред. Это открытый и стандартизованный протокол, а не что-то запретное, как вы тут пытаетесь представить.
Купил железку, в документации на нее все написано, подключил к ней RS485, 232, Ethernet и спокойно ее попросил выдавать данные. Все. Это в нормальных системах.
В вашей это куча глупости в ваших словах...

з.ы. мир ПЛК не ограничен CodeSys, но большинство спокойно поддерживают Modbus и большинство спокойно читают устройства Modbus других производителей. Будь то датчик температуры, аналогового входа или частотный преобразователь.... Вам же при этом надо будет попотеть в коде, чтобы написать опрос всего одного конкретного устройства с Modbus протоколом.
Для ПЛК или Scada систем это сводится просто к настройке опроса, без программирования.

Вообще человеку, знающему например язык ST из МЭКовских, глубоко фиолетово какой будет ПЛК, все, что ему требуется узнать, переходя с ПЛК одного производителя на другого, это разницу в архитектуре между ПЛК. Все. А будет это хардовый ПЛК или Soft совершенно при этом не важно.

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

По ходу сравните мои и Ваши ответы.


Больше того именно на ваш вопрос с весами у меня есть блестящий ответ.

Ладно, давайте посмотрим коменты в стороннем дискусе, где присутствует коллективное и не предвзятое мнение IT-шников вашей гильдии.



Хоть бери и переноси наш разговор туда...

Ржу не могу



280$ - 50$ = 230$ - простейший сервер за 10$ на срок менее 2-х лет. Ничего не напоминает, где люди, пытаясь сэкономить деньги, потом в итоге теряют? И для сведения, есть шлюзы и дешевле, чем 280$ если речь о RTU-TCP Modbus. А если использовать Ethernet - RS485 который любой протокол переварит, будет стоить еще дешевле. тот самый Com Over TCP, которого у вас нет.

И по поводу весов, вы там булочки измеряете, а люди Камазы с бетоном, соответственно применение датчиков аля AliExpress тут не подходят, а у вас упс, возможностей прочитать такие весы просто нет...

Так что ваш ответ далеко не блестящий, а больше для студентиков, обучающихся автоматизации.
Вот ваша текущая ниша...

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

Возможно мы разговариваем с тем самым chatGPT. Либо с реально немного туповатым маркетологом. Думаю, тема себя исчерпала на 146%.

Смех без причины это патология.

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



Спасибо что и за то, что Вы это мне сообщаете.



А вот собственно и та публикация о которой говорил, из за чего проекты разработчиков скад не выстреливают.
Куда приводят поиски идеальной SCADA

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

Я не вижу смысла отвечать на одни и те же вопросы в разной интерпретации, я хочу видеть развитие диалога.
Если добавить нечего, я делаю паузу, есть вероятность что сюда подтянутся к разговору более чем 1+3 участника.

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

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

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

И вам не хворать на ниве импортозамещения...

С Вашими датчиками ничего не выйдет, счет происходит физических измерений посредством ADC (многоканальный измеритель DC напряжений), соответственно юстировка принимаемых значений, тймеры, циклические опросы, триггеры, все как и положено.

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

Я Вам не скажу за всю Одессу, я сам родом из СССР до 2000 и знаю как там дают... весь этот пафос в топку.

Представьте себе, я в свое время работал в группе R&D на очень известной фирме в стране (г. Рош Аин) имеющей ISO, которая разрабатывает и поставляляет такие весы по всей стране от напольных до 500 кг балочных, до кассовых и знаю всю их подноготную всего процесса от исполнения до ввода в эксплуатацию.

Там выпускали весы со счетом показаний через копеешный ADC с интерфейсом USB COM, длина кабеля до 1 - 5м., тензодатчики именно китайские с европейским сертификатом производителя, китайцы дают любые бумаги, они с разными пределами измерений, на базе SBC под кастомной сборкой Win начиная с семки. Там же клиентский и СУБД под сервер с со сканером штрих кода, термо принтером и платежной системой счета кредитных карт.
После выпуска определенной партии весов, приглашался госповеритель и проверял каждую единицу с составлением протокола.

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

условия задачи не выполнены. смысл тогда в такой замене?
Вопрос, если там калорифер на 18 кВт, что там у вас с управлением за Optic MOSFET AC/DC Switch?

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



Можно каскадным управлением с применением промежуточных маломощных до 50А
Single Chip Microcomputer PLC Signal Amplifier Board Input and Output NPN/PNP

или напрямую к примеру с таким SSR
100A DC Control To AC Output Solid State Relay Single Phase 110V 220V 230V 380V 480V 120A Industrial DA SSR
SSR
Есть старые классические методы запуска больших нагрузок, все зависит от бюджет, от категории объекта, к примеру последнее решение вполне прокатит для аэропортов, потому что дорогое, но с длительным жизненным циклом, что в дальнейшем сэкономит клиентам крокодиловы слезы.

18 кВт и одна фаза? вы с вентиляцией вообще работали? Это уже 3-х фазник будет


опять 25, Modbus не только под PLC, забудьте уже. Точнее поймите, примите и реализуйте, и у вас не будет проблем.... и возможно отбоя.

Без этого ваша система Г...

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


Не хотим дважды наступать на оди и те же грабли, много народу на этом поломало свои копья, упор в замене существующих промышленных SoftPLC c привязкой (интерпретацией МЕК в абстрактной обвертке) ведет в никуда и будет очередной версией недоскады. Я выше здесь писал об этом и приводил опыт людей. Больше скажу, из личного опыта наблюдений, в тех отраслях где я работал, это более 25 фирм, только одна или 2 из них (климатические контроллеры и шоу управление) разрабатывала железо с применением протокола Modbus в варианте RTU,если память не изменяет на базе MCU Renesans RL78, но впоследствии они соскочили на BACNET под управлением ПК. Другая фирма сидела на ТСР с покупными лицензиями адресов и тряслись за каждый запоротый борад в процессе SMD сборки, вели учет как в аптеке.


Как Вы думаете, почему такие гиганты как тот же Intel и их конкуренты, в купе с McSoft, всячески обходят эту написания специализированной OC тему,, стороной, при этом штампуют штампуют свои формфактор доски под IPC, сбрасывают на них цены, дают их под OEM лицензиями на свободное растерзание для всех отраслей, но почему то кроме опенсорсных типа RTOS решений воз и ныне там?
Я выше давал линк на англоязычную статью с исследовании проблем, которые мы здесь и пытаемся обсуждать, лично для меня это светофор.

Ваша версия ответа?

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

Мое видение систем в принципе (упрощенно)

1. Замкнутая система (это вот ваша как есть)
2. All in One - монобрендовая, но когда ты вынужден купить все сразу потому что любой компонент не будет работать без другого (ну, на вскидку примеров нет, но наверняка существуют)
3. Модульные однобрендовые системы, где можно приобретать частями, но только от одного производителя. (Где купив PLC и при желании добавить Scada вынуждены приобретать ее у того же производителя)
4. Модульные системы, которые можно собирать из компонентов разных производителей. (где купив PLC одного производителя можно купить Scada другого производителя, базу данных третьего и так далее)

Вы сейчас на уровне 1, Желания перейти на уровень 4 по всем вашим сообщениям нет. Упоротый отказ

забудьте про MCU, не лезьте в низкоуровневую часть, работайте через API (протоколы, в том числе Modbus и являются тем самым API между железом и связью с внешним миром)

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

К примру из единичных проектов я делал GUI под такой лазерный дальномер где производитель заботливо снабдил PCE-LDS-70 прибор для всех интерфейсов и это его стратегия продвижения на рынке. Все заработало с 1-го пинка через USB COM и у меня таких решений тьма за всю мою практику. И что дальше?

Ну прочтите уже что из себя представляют протоколы вашу маму...

Там то же самое, производитель вам пишет:
Регистр 0, тип данных uint16, битовая маска состояний. Бит 0 - Жора начал "жарить рыбу", бит 1 - Вася пошел ловить рыбу, бит 2 - Вася поймал рыбу.
Регистр 1,2 - Температура воды, тип данных float (младшим байтом вперед)

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

Соответственно Modbus бывает RTU (для работы с ком портами) и TCP для работы по Ethernet и вариация Com over TCP (тот же RTU но бегающий поверх TCP) - но это уже "раздел" каналов связи, который должен быть независимо от протоколов.

В общем если вы не понимаете таких простых вещей, то что вам объяснять дальше то?

з.ы. Мой выбор это Level 4 (см. выше) остальное в топку, в сад, куда хотите. Ваше ПО там же....

Чтобы вам стало понятнее, то то, что вы называете SDK - это СПЕЦИФИКАЦИЯ протокола, а не железа, как вы думаете.

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

На вскидку вариант подачи производителя SDK для модуля NAVIA BT-01

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

Beep еще раз, если дело касается протоколов, то это как раз их Спецификация, какими средствами вы создадите программную часть для работы по тому или иному протоколу это как раз задача программиста.
Все, что вам требуется знать о протоколах это правила формирования пакетов для передачи и получения данных и правила (код) расчета контрольных сумм пакетов.
Для открытых протоколов это все доступно. Для Modbus на 200%.

Надеюсь код для каналов связи (TCP, COM, Com over TCP) раз вы общаетесь с разными железками у вас уже есть. Это уже не уровень протоколов а уровень сети.

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


Вам про Ивана (Modbus) а вы мне в ответ про Болвана.... Или вы реально бот чат GPT

Если вам лень писать самим, то на просторах нета наверняка есть готовые библиотеки для работы с Modbus, точно есть и на Питоне и на разных языках типа C++ и прочих.

Сами то пробовали этим заниматься? Если нет, устал повторять что нет интереса в переделках велосипедов, почитайте в подкасте мнение коллективного разума разрабов на примере конкректно взятого железа:
Программирование Modbus RTU Master на примере Simatic S7-1200 и ПЧ Sinamics V20
Пробовали ознакомиться с выставленным нами завершенными проектами? Это не рядом с промавтоматкой, если что.
Собственно я понял что за пределами Ваших интересов.

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

2. Адрес устройства или подчиненного устройства идентифицирует ваш прибор. Он содержит один байт информации. В ASCII он кодируется двумя шестнадцатеричными символами, в RTU — одним байтом. Допустимые адреса находятся в диапазоне от 0 до 247.
Код функции определяет тип сообщения. Он содержит один байт информации. В ASCII он кодируется двумя шестнадцатеричными символами, в RTU — одним байтом.
Настройки Com-порта Modbus


Стартовый бит ASCII
= 1 Биты данных = 7
Если четность четная или выключена, то стоповые биты = 1
Если четность отсутствует, то стоповые биты = 2


Стартовый бит RTU
= 1 Биты данных = 8
Если четность четная или выключена, то стоповые биты = 1
Если четность отсутствует, то стоповые биты = 2

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

Мы в.у. обходим посредством счета физических аналоговых значений со стороны аналоговых приборов.

Как то так.

Какой то набор букв. Даже не слов.

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

я пользуюсь Scada системой, где реализован Modbus, как мастер так и слейв. Кто то пользуется OPC сервером Инсат, там так же реализован Modbus как мастер так и слейв, Кто-то пользуется другими Scada системами, где так же реализован Modbus.
Их масса.... всех даже не перечислишь. А вы такие умные, утверждаете, что




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

И если что, я и другие реализуют другие протоколы на базе либо Scada, либо OPC, и вполне успешно, без ваших гнусных инсинуаций по поводу SDK, потому что производители устройств предоставляют описание своих протоколов. И да, они не в виде библиотек, а просто в виде текстовых файлов....

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

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



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

Virtual Serial Port Driver SDK

Больше Вам manjey73 мне особо и нечего здесь добавить, булку крошим по столу.

Ваша система не подходит для решения типовых задач автоматизации АВОК, примите это как данность и отвалите.
Удачи вам в решении студенческих работ.

И еще момент, в России Windows умрет в сентябре, возродится после 1028 санкций так что про Россию забудьте вдвойне...


Интересно, когда вы научитесь читать? Повторю последний, самый последний раз.

Есть система, разработчик системы подумал и реализовал сетевой уровень (в вашем понимании использовал SDK по работе с портами и Ethernet)
При этом реализовал стандартизованные протоколы (Modbus)

1. позволил пользователям пользоваться устройствами Modbus без программирования
2. позволил пользователям программировать другие открытые протоколы, кроме Modbus (так как в системе реализован сетевой уровень)

В вашей системе нет даже пункта 1, не говоря уже о пункте 2.
Делаем выводы, система не предназначена для распределенного использования, может работать только сама в себе.
Ожидания дополнительных возможностей туманно.
Вывод - зачем тратить время на систему, которая возможно никогда не вырастет до желаемого уровня? Не зачем. Значит такую систему в топку...

Тема, в которую Вы ввалились, не Ваша, так что пусть ее автор решит кому валить.
Вам так же встретить свою достойную автоматизатора пенсию в здравом уме

Мне вот интересно, как люди выстраивают свою философию и пытаются ею насаждать окружение?

Что меня побудило выставить платформу здесь на обзор, так это тема которой люди интересуются помимо автоматизации АВОК

Цитата(LordN @ 26.3.2009, 8:26)

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

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


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




Да хоть и в предпоследний, Вы явно никогда не работали группах R&D от того и стиль Вашего общения мягко говоря как у колхозника времен свершившейся революции 18 года - "Не пойду я в твой колхоз!"



Прежде всего сами по себе протоколы погоды не строят, если Вы не строите по ним обращения на знакомых Вам МЕК языках в среде их компилятора.



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



Читайте ответ на 1 свое утверждение.


Так спору нет, т.к. Вы ушли от сути темы и саме себе решили, что если иная платформа не работает с внешней логической топологией класических контролеров, включая и сами эти контролеры, то


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


[b]
Ну прямо отец настоятель - это в топку, это на задний двор на удобрения... что там еще?
А приход в этом молебном доме, ты да я, да мы с тобой, что никак без не предвзятого арбитра не вносит истину в спор, как в стихотворении про 3-х мудрецов и дырявый таз.

Не уходите в философствование - не Ваше это. Гугл переводчик и википедия не самые лучшие друзья...
- революция была в 17, а не в 18 году,
- колхозник, он потому и колхозник, что он УЖЕ в колхозе,
как он может "не пойти в колхоз" ?
- и да, у нас уже есть свой колхоз, в Ваш - не хотим.
- и разберитесь уже наконец с Модбасом.

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

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

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

Продолжаем.

Поднятая автором поста тема и увы, ее явного или скрытого игнора многими IT сообществами, в т.ч. и здесь есть результат неосведомленности среди техно фронтов (здесь в обсуждении присутствует 3+ субъективных мнения).

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

Отсюда и разночтения, как терминологии, так и в одобрении прав на существование в своем планктоне.

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



Или это



Народ смотрит на это как на НЛО и просто веселится от неслыханного и невидимого дива дивного...

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

Обратите внимание. там CodeSys 3.5 еще и с EtherCAT, а наличие COM портов, дополнительно к Ethernet позволяют использовать и Modbus и черта лысого....
Сравните со своей системой, где только USB 3.0

а так же о чем писали выше, для многих здесь это никакое не НЛО, а такой же точно ПЛК, только полностью Soft, особенно если производитель оставил доступ к системе для возможных настроек VPN, сети и так далее.

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


Слесарю слесарево ...
Люди поставили перед собой эту задачу и довели до логического финала, я кстати с их девопосм веду переписку, история развития покрыта мраком и тайной.

Что касается нашего, вроде уже не первый раз говорю :

Я не кодер С++,
в моем случае Вам будет предоставлено поле или набор полей в виде String Array, для отправки в RS-485 счета данных в протоколе Modbus RTU через RS-485:



Но нафик оно мне надо, еще и проводить обработку принимаемых данных для их отображения в понятном для Вас виде, если я могу через ADC без танцев с бубном и изучению документации сенсоров, просто считать напряжения, отобразить их на экране и установить в качестве переменных триггерного значения, причем селективно или одновременно 10 каналов в один порт?
Сенсоры в моем случае любые резистивные или ttl

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

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

Принимайте любое изречение на свой счет. Если вам это не надо зачем-то, то зачем ваше надо другим? причины всегда зеркальны.

В моем случае это выглядит так:

И так

Это как раз Вы сюда сунулись со своим надувным монастырем и норовите все переосмыслить под свою веру.

первое сообщение темы



есть ли под неё толковый, не винды, софт, среды разработки и т.д.

Тот линк, на который ссылка в его вопросе



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

Дальше в последующих коментах народ резко переключил свое внимание на железо, оставив тему софта в глубоком стендбае.

О, графику из 90-х подвезли))) Без обид, я в колледже на олимпиадах такую же хренрню делал, выглядело точно также убого, но для школьника это допустимо.

Комбобоксы - мои глаза вытекают, как теперь это развидеть... Когда я к ним впервые применил customDesing у меня один в один всё также развалилось, но я нашел решение примерно за полчаса.

Ashihara,
Ну изначально как бы и не было задачи изголяться в отображении элементов рабочей консоли как это есть у игровых консольных приставках. Это стандартный Silver набор среды, в которой разрабатывалось ядро, c упором на темную тему.
По ходу не сказать, что я в восторге от многих интерфейсов именитых систем, начиная от Visual C++ и заканчивая тем же Code Sys. Я здесь интересовался, но ответ не получил какой бы интерфейс имел предпочтения или линк на примеры интерфейсных абстракций.
Я собственно и не вижу смысла в чем то из ряда вон запредельного, это прежде всего среда - инструмент, тему изучал но ни у кого нет единого мнения и правил и здесь Важен исходный продукт работы в среде. Что касается клиентских (HMI) представлений фронтальной панели, если она присутствует в проекте, то согласен, здесь кроме функционала, важна и эргономика работы с отображаемой телеметрией и элементами управления, хотя бы и с клубничкой вместо классической кнопки, когда это вендинговый автомат...

Кстати о птичках, вы видали мониторы проекта SpaceX? Как по мне, это синяя монохромная жуть.

Вы про это? Silverlight
Если да, то у вас совсем все печальненько....

Не про этот. В моем случае это банальное наименование одного из предложенных средой разработки стилей, отображаемых элементов на фронтальной панели, их по ходу 4.
Этот мне больше интересен чем другие.
Для понимания с Вашей каланчи, это такой графический "фонт", только вместо текста графика.

Не пытайтесь в своей голове генерить гугл поисковые предположения, проще спросить.
Среда, как ранее сообщил, разработки и компиляции - LabVIEW, которая, в свою очередь написана, как и Linux, в основном на Cи.

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

Стиль вырвиглаз это точно...

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

Пример вычислений:
взять показания двух аналоговых входов (Х1 и Х2),
вычесть одно из другого (Е = Х1 - Х2),
умножить их разницу на некий коэффициент (Y = Z*Е),
подать полученное произведение на аналоговый выход.