И собственно как это все реализовать?

Управлять по веб - возможно. Где сделать таймер - зависит в первую очередь, для чего этот таймер нужен.

Однако в целом пока ваши вопросы - это как "рация на транзисторах или на бронепоезде?" и отвечать на них серьезно очень трудно. Если очень вкратце - задача про проверку трехфазных машин и задача управления по веб - абсолютно разные материи и смешивать их не нужно.

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

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

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

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

Можно полагать каждой ардуине нужно будет присвоить свой статический ip адрес. Мне не понятно как нажатием кнопки в WEB будут передаваться данные по Ethernet? Если есть материалы на данную тему, пожалуйста поделитесь ссылкой, у меня не получается правильно сформулировать поисковой запрос. 

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

Почитайте про принцип действия протокола MQTT

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

Что пишут про W5100 ethernet shield:

На коммутаторе CISCO за 800 баксов выгорел порт на линии этого шилда. На коротком шнурке с 510 Ом сборкой работает еще более менее. На производстве с длинными проводами в условиях регулярных помех стабильно вешается. С бубном долго плясал, пока обратил на сопротивление внимание. Еще не хило греется сам кристалл при таких условиях работы.

 

Долго ломал голову почему шилд не работает на Длинковских свичах ( пеербрал кучу ) и работает на нонем тпом коммутаторе. Оказалось все дело в сборке резиторной ( мелкая такая шестиногая ) что припаяна прямо за спинкой RJ45.

Сборщики традиционно путают сборки с номерами 510 и 511. Это разница в сопротивлении на порядок.

У меня стоит 511 нужно 510

Этот номинал резистора установлен не просто так. При установке резисторов в 51Ом микросхема W5100 начинает сильно греться и возрастает потребляемый ею ток. Резисторы 510Ом частично решают эту проблему при сохранении работоспособности модуля. Если Вас не устраивает номинал этих резисторов мы Вам можем перепаять на требуемый номинал.

 

Кто же дешманские железки в дорогие циски втыкает? Домовые провайдеры давно уже поняли, что выше D-Link-a на access не стоит ставить.

Что же касается помех... я как-то раздолбанным перфоратором потрещал около чипа. Тоже подвисало. Но несистематически. Провод был ~1 метр.

У меня в серверной девайс с модулем на этом чипе проработал >1 года без сбоев и ребутов в пластиковом корпусе и монтаже на макетке (с проводками). Так что если не жестить, то чип отличный.

Для кидания коммуникаций между станками есть более другие протоколы/среды - RS485, CAN и т.п.

Это не станки... долго расписывать про это. Так что же мне применить? Стоимость устройств значения не имеет, здесь главное надежность и безотказность. 

Здесь главное понять - нет 100% надежности и безотказности в самосборе. Его, конечно, нет и в кровавом энтерпрайзе, но там вероятность отказа снижена до долей процента за счёт вложенного адского количества человеко-часов разработчиков. Если Ваша фамилия не Безос - не стоит писать насчёт "Стоимость устройств значения не имеет".

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

 

Может посмотреть в сторону готовых решений? Типа такого

https://usa.banggood.com/NC-1000-Ethernet-RJ45-TCP-or-IP-Remote-Control-...

Или понадежней https://relaypros.com/Relay/Relay/ip_relay_control

 

На банггуде, судя по виду, микрочиповский ENC28J60 + какой-то МК. 

Удалось ли китайцам обойти проблемы ENC - вопрос, конечно.

А что скажите за это чудо - W5500 Ethernet контроллер от Keyestudio?

https://aliexpress.ru/item/32849752167.html?spm=a2g0s.8937460.0.0.125f2e0eaIQLwU&_ga=2.69645904.1930021594.1600328387-1424054140.1583838569&_gac=1.90909032.1600337905.CjwKCAjwkoz7BRBPEiwAeKw3qzwgPSaH1QYuhW8uPV93Z-21QpWFDHsq0ZMNMircuknJRV-RDBHTtxoCwV0QAvD_BwE

Почему чудо? Просто на одной плате всё разведено. Keyestudio - неплохая контора, не косячит. Можно ещё взять от РоботДина шилд + Nano - будет то же самое, но помельче.

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

Я бы взял Nano+ шилд от роботдина + ещё одну платку с винтовыми коннекторами. Всяко лучше, чем "втыкачки". 

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

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

https://aliexpress.ru/item/32966745493.html

https://aliexpress.ru/item/4000391983809.html

https://aliexpress.ru/item/32933662259.html

Благодарствую.

а вот интересно, прилетит на нану такую большой пакет, ну очень большой, положит?

Нану точно не положит. У Wiznet свой буфер, куда он складывает байты с пакета. Насколько я помню - он просто будет их в /dev/null спускать, если никто не выгребает своевременно. А вот ENC28J60 раком встанет. Это, конечно, вина не его , а драйвера... Но тем не менее - с Ардуиной на стоковых библиотеках Wiznet гораздо безопасней.

Нана просто скажет "не могу обработать, пришлите поменьше".

А вот это вроде еще интересней. Сетевой трансформатор еще прилепили и дроссель. 

Чушь.

IСMP 3 4, чушь

Какой ICMP в ответ? В даташите покажи.

ТРИ ЧЕТЫРЕ

То что ты просишь даташит на стандарт интернета говорит о том, что разговаривать с тобой дальше не о чем.

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

"даташит на стандарт интернета" стоит отлить в граните, я щитаю. О том, что это скажет Nano при том, что весь TCP/IP стек реализован Wiznet в чипе, я вовсе промолчу.

Задача, по моему мнению, элементарная, даже не читал все, да и зачем это все?

Бери не шильд, а красный модуль он нормально работает на всяких линиях

 

А можете ссылку дать на этот модуль? 

Продолжаю дальше изучать сию тематику и наткнулся на STM32...

Отладочная плата NUCLEO-F446ZE - это высокопроизводительная STM32 Nucleo-144 плата на базе микроконтроллера STM32F446ZET6U (32 бит, 180 МГц, ARM Cortex-M4) с памятью Flash 512Кбайт.

Нужна ли мне такая "моща"?  Сразу и RG45 на плате, только все на одном чипе. Вроде как ардуиновский код работает на этой приблуде.

А есть еще такое - CPU: STM32F103VET6, TQFP 100 pins FLASH: 512Kb, SRAM: 64Kb

Последний сразу в сторону, не разглядел на нем сразу ENC28J60. Ну и похоже Nucleo это бренд от STM.

Каким-то образом он работает без стороннего чипа с сетью. 

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

ЗЫ раз стек протокола в чипе то проблем быть на W5500 не должно

Вопрос здесь не в ардуине, а в стабильности системы 24\7. 

надежность это LINUX, и возможно

Raspberry Pi

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

если вы думаете, что для создания "стабильной системы" вам достаточно купить плату стм32 нуклео и все заработает само - вы супер наивный человек. Это примерно такое же заблуждение, как то чтоб стать великим теннисистом, достаточно купить дорогую ракетку.
Сама по себе стм32 с сетью не заработает и готовых ардуино-библиотек для нее нет.Чтобы научится пользоваться возможностями верхних линеек стм32 - вам понадобится минимум 2-3 года. Одно только описание спецификаций мк стм32f103 занимает более 1000 страниц английского текста.
Если вы только пару дней назад услышали про контроллеры, ардуино, стм32 - не стоит сразу замахиваться строить синхрофазотрон, начните с задачки попроще. Возьмите ардуину нано с шилдом, на нее хотя бы в инете достаточно примеров кода. На стм32 вы с нуля стартовать вряд ли сможете, если вы не опытный ембеддер и знаток сетевых протоколов

Закажу, куплю написанный вами код под мои задачи. 

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

Итак, я заморочился и посмотрел, что же происходит при флуде Wiznet W5500. Напомню, что у нее дефолтовый размер буфера сокета 2048/2048 (RX/TX).

Скетч для Arduino имитирует обработку с задержкой:

#include <SPI.h>
#include <Ethernet.h>

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
/*
  IPAddress ip(192, 168, 1, 177);
  IPAddress myDns(192, 168, 1, 1);
  IPAddress gateway(192, 168, 1, 1);
  IPAddress subnet(255, 255, 0, 0);
*/

// telnet defaults to port 23
EthernetServer server(23023);
boolean alreadyConnected = false; // whether or not the client was connected previously

void setup() {
  Ethernet.begin(mac);
  Serial.begin(115200);
  server.begin();
  Serial.print("Server listen on: "); Serial.println(Ethernet.localIP());
}

void loop() {
  EthernetClient client = server.available();

  if (client) {
    if (!alreadyConnected) {
      client.flush();
      Serial.println("We have a new client");
      alreadyConnected = true;
    }

    int16_t bytesAvailable = client.available();
    if (bytesAvailable > 0) {
      delay(15000);
      for (int16_t i = 0; i < bytesAvailable; i++) {
        char thisChar = client.read();
        Serial.write(thisChar);
      }
    }
  }
}

Скрипт для PowerShell бахает разом в сокет большой фрагмент данных (заведомо больше размера буфера W5500):

$address = "172.16.100.203";
$port = "23023";
$tcp = New-Object System.Net.Sockets.TcpClient($address,$port);
$tcpStream = $tcp.GetStream();
[System.Text.Encoding] $encoding = [System.Text.Encoding]::ASCII
$writer = New-Object System.IO.StreamWriter($tcpStream,$encoding,3096);
$writer.AutoFlush = $true;
$floodSize = 3000;
$flood = "";
for ($j = 0x00; $j -lt $floodSize; $j++) { 
   $flood += [char](Get-Random -Minimum 0x30 -Maximum 0x7A); 
}
Write-Host $flood
if ($tcp.Connected) {
   $writer.WriteLine($flood) | Out-Null 
}     
$writer.Close()
$tcp.Close()

Wireshark смотрит траффик:

В целом всё обстоит так:

1) Пинг для проверки;
2) На Wiznet уходит 1460 байт (размер окна TCP), чип отвечает, что может принять ещё 588 байт;
3) На Wiznet уходит ещё 588 байт. Итого 2048 байт выслано.
4) Чип отвечает, что места в буфере нет, передачу следует приостановить (сообщение TCP Zero Window), "посылатель" начинает периодически тыркать чип - может тот уже принять данные или ещё нет?
5) Проблема на стороне Wiznet рассасывается (буфер вычитан) и ему досылается остаток - 954 байта

Что такое "TCP Zero Window": 

When a client (or server – but it is usually the client) advertises a zero value for its window size, this indicates that the TCP receive buffer is full and it cannot receive any more data. It may have a stuck processor or be busy with some other task, which can cause the TCP receive buffer to fill. Zero Windows can also be caused by a problem within the application, where the TCP buffer is not being retrieved. A TCP Zero Window from a client will halt the data transmission from the server side, allowing time for the problem station to clear its buffer. When the client begins to digest the data, it will let the server know to resume the data flow by sending a TCP Window Update packet. This will advertise an increased window size and the flow will resume.

Итого:
- данные не теряются, пока сессия не будет закрыта по таймауту;
- чип не просит "прислать поменьше";
- уж точно никаких "ICMP 3 4 из стандартов интернета" не наблюдается.

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