РЕКЛАМА НА ФОРУМХАУС Чего-то я тоже не понимаю насчет "правильной последовательности". Что это означает?
@lingvo, буквально то, что написано: обработка событий в той последовательности, в которой они происходят. Любых событий, которые будут заведены на обработку. В порядке их события. Так нужно
В чем будет заключаться обработка и что произойдет, если события вдруг будут обработаны в другой последовательности? Если два события произойдут одновременно, в какой последовательности их надо обработать и почему? Я извиняюсь за глупые вопросы, но мне кажется вы говорите о банальной вещи, только не той терминологией.
По EtherCAT можно собирать состояние всех портов довольно быстро. У нас укладывались в 1 миллисекунду для 10 модулей по 16 входов. На выставке Beckhoff показывали передачу звука, АЦП+ЦАП 4-8 КГц цикл опроса.
@lingvo, если они будут не в той последовательности - то они будут интерпретированы неверно, что может привести к неверным результатам. А два события совсем одновременно не произойдут - какое-то будет раньше обработано. С другой стороны, если они действительно настолько одновременны, что могут путаться - значит, их порядок значения не имеет. Как-то так Это для контроля нужно.
Что значит неверно? Пусть, например, придут три события: 12ч 45м 32с 14мс - Датчик тока показал превышение тока в розетке. 12ч 45м 32с 16мс - Датчик счета переключился из состояния темно в светло. 12ч 45м 32с 18мс - Пользователь нажал на кнопку на стене. Какая разница в каком порядки они будут обработаны?
Время откуда возмется в событии? Встроенные часы? Синхронизация? Ведь они не просто должны быть - они должны быть синхронизированы между собой. И так мы плавно приходим к необходимости вкрячивать довольно сложную логику в каждую точку, вместо концевика, например. Ради того чтобы что?
Ниоткуда. Время я привел чисто физическое. Так какая будет разница, если события будут обработаны не в этом, а скажем, в обратном порядке? Вот и я спрашиваю, ради чего такой порядок нужен.
Обработку, как вы ее формулируете (собрать все данные - обработать - выдать результат) решают промышленные ПЛК. Но там никто в здравом уме не поручит ее решать РС. Однако приложение, как вы его описываете (освещение, розетка, кнопка и т. п, т. е "умный дом"), хоть в принципе и может быть автоматизировано про помощи ПЛК, однако как правило автоматизируется совсем по другому. Системы управления "умным домом" (KNX, Z-wave и т. д) делаюются децентрализиванными и реагирующими на события. Никто и нигде не пытается "все собрать в нужной последовательность" а затем "правильно обработать". Конечно, можно загнать себя в угол и биться лбом об стенку, однако это довольно глупо. Промышленные ПЛК просто делаются достаточно быстродействующими, чтобы цикл (сбор данных - обработка - выдача воздействия) прокручивался очень быстро, в соответствии с теоремой Найквиста - Котельникова. Тогда никакая "последовательность" никому и в гробу не нужна. А время обработки событий в системах для "умного дома" определяется временем реакции человека, чтобы система не раздражала своей "тормознутостью". Значит, если любое одиночное событие обработается менее чем за 0.3 сек и человек не заметит, то система будет выглядеть "реактивной", быстрой. А редкие случаи совместных событий, когда такая система начнет притормаживать, тоже никого не раздражают, как раз таки в силу своей чрезвычайной редкости.
Я же как говорил: собрать N сигналов 0/1 в последовательности их возникновения и передать в компьютер ASAP. Было? Но разве я говорил о том, какой должен последовать результат от компьютера? О том, что компьютер должен отреагировать и что-то там включить? Не было, это вы додумали. А если бы и должен был - то я не упоминал о том, как именно - потому что тут вопроса не было, вопрос в сборе сигналов... Как оно делается "как правило" - это вообще совсем другое дело...
Это что, логгер какой-то? Так вам просто сигналы надо с временными штампами записывать в файл. Получите свои +-0,1 с временной погрешности.
И что это меняет? Фаза выдачи управляющего воздействия может быть опущена без потери общности рассуждений, это будет частный случай цикла. А вообще, касательно "додумал", то я исхожу из (наиболее разумного в данных обстоятельствах) предположения, что вы "изобретаете велосипед" просто от незнания. Могу только повторить, что вы вольны произвольно поставленными условиями загнать себя в угол и биться там головой об стенку. А то, что условия произвольные, нетрудно догадаться по тому, что вы темните с описанием своей задачи.
@_AK_, не додумывайте, и не считайте, что все глупее вас Моя задача логически простая: требуется фиксировать сигналы с датчиков. Слово "лог-файл" вам же знакомо, наверное? И почему программа, пишущая что-то в лог, должна сделать это именно тогда, когда событие произошло, и как можно быстрее, не ожидая пока там прочухается система логирования и сподобится принять сообщение - тоже должно быть понятно. Вы же говорили о программировании - программисту должно быть это понятно. И чем отличается лог от очереди команд - тоже. Надеюсь. Вот это такой лог-файл событий, только аппаратных. Кнопки, датчики. Как получать сигналы, передавать их в компьютер, и делать это без разработки специализированной платы расширения, работающей непосредственно с шинами PC. Это для ISA еще можно было пошаманить с платами, а сейчас это очень дорого выйдет. Ну варианты ответов я в принципе уже получил...
Да, по сути так. Вопрос, где брать временные штампы: если сигналы отправляет N разных устройств - то каждое из них должно включать временную метку, при это все они должны быть синхронизированы. А если метки проставляет приемник сигнала - то необходимо обеспечить правильную последовательность их обработки, чтобы первый пришедший был принят раньше второго, независимо от загрузки компьютера, наличия свободного процесса для обработки и прочих подобных нюансов - о чем я написал уже раз десять. Именно поэтому TCP не подходит для приема N сигналов - при распараллеливании обработки не гарантируется последовательность, при обработке в один поток возможны заметные задержки в случае одновременности. Получается, надо заводить все на один контроллер, который будет отслеживать изменения и передавать пакеты сразу с N параметрами или с теми самыми метками. Ну или какую-нибудь шину типа CAN, 1-wire и т. п. и умные датчики, кидающие в эту шину события. Пока вот варианты определились - ардуино как контроллер для линий + отправка на PC или knx как шина.