Что-то или я невнимательно читал, или не уловил: каким образом построена работа с GPIO? Надо ли что-то настраивать в мохе, как до этого достучаться через ethernet?
Ну вот, реальные примеры пошли :) а то 15 дней, 20 дней.
У меня самый длинный период был 53 дня командировки, 10-12 часов в день (не считая дороги) и ни одного выходного. Только один день повалялся — приболел. А всего у меня за тот год было около 4 месяцев таких командировок.
Вы работали по скозлящему графику? :)
Я на таком графике спал за деньги. Спать ещё куда ни шло, а вот работать постоянно (было несколько ночных смен — пришлось поработать) — ну его к чёрту. Ну и каждый раз после смены я видел тех, кто всю ночь работал. Я так точно не хочу.
Ещё минус — выходные получаются короче (ровно двое суток против двух с половиной обычных) и хронически не совпадают с общими — с семьёй, например. Подмениться тоже проблема каждый раз.
Мышкой пользуюсь, без неё почти никак. Подобное кресло в моём случае — роскошь. В полевых условиях верх шика это большой кабельный барабан в качестве стола и маленький в качестве стула. Ну и прочие интересные позы… Приноровился мышь (беспроводную) держать в кармане куртки. За неимением поверхности для мыши — очень даже.
Ваш коммент напоминает мне анекдот про то, как Рабинович по телефону Битлз напел :)
Оно всё довольно понятно, если иметь представление, что такое LAD(der) и как работает контроллер.
Информации на эту тему полно, вы таки плохо искали и мало знали. Тем более, что SCADA — это немного другое. Это визуализация процесса, а CoDeSyS — это среда разработки программы для контроллера.
А что именно вы искали? Информации полно, на самом деле. Что такое PLC модем, я, например, не знаю. Попробуйте поискать отдельно по PLC и по передаче данных.
Я уже давненько писал статью про один выполненный проект. Он, конечно, не совсем про учёт энергии, но и это там тоже есть.
В двух словах, различных измерителей энергии (как счётчиков, так и нет) вагон и маленькая тележка. Многие из них имеют интерфейс ModBus. А если есть ModBus — читать с него данные не проблема хоть по воздуху, что по проводу. Хоть я и немного недолюблюваю ModBus :)
Вы бы в сторону RS-485 посмотрели. Нормальный промышленный (и довольно неплохо помехозащищённый) интерфейс, в отличие от USB. Длина кабеля почти не критична (в километр, думаю, уложитесь) и полно устройств распределённого ввода-вывода, в том числе, недорогих.
Собственно, по-хорошему, все точки ввода-вывода собираются с помощью распределённого ввода-вывода на контроллер (типа того сименса, что в шкафу), а уже из него тянутся в сервера по интерфейсу (например, Ethernet).
Если что — я занимаюсь системами промышленной автоматики и мне всегда любопытно наблюдать, как подобные вещи реализуют люди, привыкшие к десктопным решениям :)
PS возможно, я чего-то не знаю и/или ошибаюсь применительно к вашему проекту.
А я расскажу, за что АСУТПшникам не любить безопасников.
Во-1, производители средств автоматики очень любят разные проприеритарные протоколы, нестандартные (с точки зрения безопасников) порты, протоколы (UDP всякие, ISO) — а безопасники очень любят блокировать абсолютно всё, без чего могут существовать офисные хомячки. В результате мы имеет то, что связь либо не работает совсем, либо работает с совершенно необъяснимыми глюками. Я уж не говорю о том, что безопасники очень любят блокировать средства удалённого доступа — такие как VPN, TeamViewer, LogMeIn и RDP. А автоматчик к объекту цепью не прикован. И вот, как обычно, случается ЧП ночью в выходные, тебя будят в тёплой постельке, а ты даже масштаб бедствия оценить не можешь. Потому, что со слов эксплуатации — «оно само», а зайти посмотреть логи — никак…
Вот и получается, что безопасники, в сущности, втыкают палки в колёса. Абсолютно все, какие только можно воткнуть. И безопасникам никто за это голову не морочит. А когда автоматика не работает или работает странно (по причине тех самых плавающих глюков) — по голове получают автоматчики, и получают сильно. А безопасникам — хоть бы хрен.
Я на минимально-достаточном уровне иврит освоил. Если принять во внимание количество носителей, то разговор получается вполне себе шифрованным. Даже небольшая записка — уже шифровка, хоть и слабая :))))
Одна проблема: собеседник тоже должен владеть ивритом…
А не пробовали Access (Jet) использовать? Вполне себе реляционная клиент-серверная база данных. Даже если офис стоит не Professional (без аксесса), движок в винде присутствует по-любому :)
Т.е. тот же IP, но другой порт и там даже веб-морда есть?
У меня самый длинный период был 53 дня командировки, 10-12 часов в день (не считая дороги) и ни одного выходного. Только один день повалялся — приболел. А всего у меня за тот год было около 4 месяцев таких командировок.
Я на таком графике спал за деньги. Спать ещё куда ни шло, а вот работать постоянно (было несколько ночных смен — пришлось поработать) — ну его к чёрту. Ну и каждый раз после смены я видел тех, кто всю ночь работал. Я так точно не хочу.
Ещё минус — выходные получаются короче (ровно двое суток против двух с половиной обычных) и хронически не совпадают с общими — с семьёй, например. Подмениться тоже проблема каждый раз.
Оно всё довольно понятно, если иметь представление, что такое LAD(der) и как работает контроллер.
Информации на эту тему полно, вы таки плохо искали и мало знали. Тем более, что SCADA — это немного другое. Это визуализация процесса, а CoDeSyS — это среда разработки программы для контроллера.
Я уже давненько писал статью про один выполненный проект. Он, конечно, не совсем про учёт энергии, но и это там тоже есть.
В двух словах, различных измерителей энергии (как счётчиков, так и нет) вагон и маленькая тележка. Многие из них имеют интерфейс ModBus. А если есть ModBus — читать с него данные не проблема хоть по воздуху, что по проводу. Хоть я и немного недолюблюваю ModBus :)
Собственно, по-хорошему, все точки ввода-вывода собираются с помощью распределённого ввода-вывода на контроллер (типа того сименса, что в шкафу), а уже из него тянутся в сервера по интерфейсу (например, Ethernet).
Если что — я занимаюсь системами промышленной автоматики и мне всегда любопытно наблюдать, как подобные вещи реализуют люди, привыкшие к десктопным решениям :)
PS возможно, я чего-то не знаю и/или ошибаюсь применительно к вашему проекту.
Во-1, производители средств автоматики очень любят разные проприеритарные протоколы, нестандартные (с точки зрения безопасников) порты, протоколы (UDP всякие, ISO) — а безопасники очень любят блокировать абсолютно всё, без чего могут существовать офисные хомячки. В результате мы имеет то, что связь либо не работает совсем, либо работает с совершенно необъяснимыми глюками. Я уж не говорю о том, что безопасники очень любят блокировать средства удалённого доступа — такие как VPN, TeamViewer, LogMeIn и RDP. А автоматчик к объекту цепью не прикован. И вот, как обычно, случается ЧП ночью в выходные, тебя будят в тёплой постельке, а ты даже масштаб бедствия оценить не можешь. Потому, что со слов эксплуатации — «оно само», а зайти посмотреть логи — никак…
Вот и получается, что безопасники, в сущности, втыкают палки в колёса. Абсолютно все, какие только можно воткнуть. И безопасникам никто за это голову не морочит. А когда автоматика не работает или работает странно (по причине тех самых плавающих глюков) — по голове получают автоматчики, и получают сильно. А безопасникам — хоть бы хрен.
Или это тоже силами VBscript?
Не пробовал эту таблицу сделать, как шаблон (xlt), чтобы «пустая» новая книга генерировалась автоматически при открытии?
А так — круто, да :)
Хотя, без аксессовской оболочки создать и настроить базу довольно геморройно :)
Я на минимально-достаточном уровне иврит освоил. Если принять во внимание количество носителей, то разговор получается вполне себе шифрованным. Даже небольшая записка — уже шифровка, хоть и слабая :))))
Одна проблема: собеседник тоже должен владеть ивритом…