RS232 vai USB + PHP

[Blitz]

Uztaisi konsoles PHP aplikāciju/procesu kas visu laiku darbojas un lasa datus no kontroliera un raksta datubāzē.

 

Rekur pat vari kā windows servisu palaist: http://php.net/manual/en/win32service.examples.php

Edited August 3, 2015 by Blitz

[rpr]

Čalis ar neapskaužamu regularitāti ieposto kaut ko :)

 

Uz linux tie sauksies dēmoni (daemon). Palaid bg, lai darbojas un nekas nav atkarīgs no lietotājiem.

[F3llony]

Raksti visu Scalā. Kā Tu nesaproti!

 

:DD

[codez]

Scala patiesībā ir ļoti pat normāls rīks šādiem uzdevumiem, it sevišķi, ja tev būtu jālasa tas viss no 100k sensoriem uz 50 kastēm un jāreaģē dažu ms laikā, ņemot vērā lielu skaitu lasījumu.

Bet vienkāršā gadījumā tīri labi noderētu arī Pyhton-s vai Node.

 

P.S. Un pa laikam iečekojot, ko labu piedāvā, piemēram, UK - tad PHP, js, python, utml. algas sludinājumos svārstās no 100 - 300 GBP / dienā, kamēr Scalai tās ir no 500 - 800 GBP / dienā.

Edited August 3, 2015 by codez

[F3llony]

[sharps]

Paldies Blitz. Papētīšu sīkāk.

 

 

 

PS

F3llony tā kā es zinātu kas ir scala? Neesmu programmēšanas profesionālis un nezinu visas novitātes. Kontrolierus gan man tīk programmēt. Tur cita specifika.

rpr kāda starpība cik bieži iepostoju? Es pamazām PHP apgūstu pašmācības ceļā un nezinu visus tos smalkumus. Man tuvāka ir elektronika. "Nesenā" laikā radusies interese, kā to visu sajūgt kopā ar WEBu.

Edited August 3, 2015 by sharps

[Wuu]

Sharp, ko tu tur tieši kontrolē? Es savām vajadzībām atradu risinājumus ar TCP/IP, lai nebūtu galva jālauza.

[Леший]

UK labākas algas saņem programmētāji ar SQL zināšanām, tāpēc autoram vajag visu pārrakstīt uz SQL.

[codez]

UK labākas algas saņem programmētāji ar SQL zināšanām, tāpēc autoram vajag visu pārrakstīt uz SQL.

 

Parādi kur.

[codez]

Pamatošu kāpēc Node vai Scala ar Akka un Play freimworkiem ļoti labi iederas (labāk kā PHP) šādu uzdevumu veikšanai. Un kāpēc Scala der labāk par Nodi.

Jāsāk ar to, ka PHP šādā gadījumā sastāvēs no divām daļām: pirmā būs background process, kurā notiks saziņa ar sensoriem, otra web backends. Scalas un Nodes gadījumā, abas šīs lietas atradīsies vienuviet.

Apskatīšu pāris reālas dzīves iespējamās situācijas un kā tas izskatīsies katrā no sistēmām:

 

1)Sensors lasa 100 lasījumus sekundē un vajadzīgs attēlot pēdējās stundas datus.

PHP - web backendam un sensoru lasīšanas daļai ir caur kaut kurieni jākomunicē - visdrīzāk caur kaut kādu db. Tā varētu būt mysql, litesql vai memcached. Visos gadījumos jāraksta db saglabāšanas kods un no db nolasīšanas kods. Mysql un litesql gadījumā tas rada arī ievērojamu slodzi uz sistēmu, bet memcached gadījumā, pie programmas nobrukšanas pazūd pēdējās stundas dati.

 

Node - glabājam js masīvā. Sensoru lasīšanas laika events nolasa datus iepušo masīvā, backend lasa no tā paša masīva. Nav nekāda starp komunikāciju overhead-a. Tomēr pret datu pazušanu programmas nobrukšanas gadījumā, būs jāuzraksta persistances kods (taču izmantojot kaut ko šādu, tas būs īss).

 

Scala - izmantojam Akka, izveidojam Akka actor-u, kurš glabā stāvokli masīvā, sensoru lasīšanas actor-s sūta datus stāvokļa actor-am. Web backend paņem datus no stāvokļa actor-a. Nav nekāda starp komunikāciju overhead-a. Pie tam izmantojot Akka persistence, mēs iegūstam automātisku stāvokļa saglabāšanu un atjaunošanu, nobrukšanas gadījumā.

 

2)Sensoru datu lasīšanas un apstrādes kodā ieviesusies kļūda, piemēram, apstrādājot datus 0.001% gadījumu sanāk dalīšana ar nulli, vai vēl vairāk - grūti novēršama kļūdu kombinācija (piemēram, iespējams pārrāvums komunikācijā ar sensoru mikrokontroleri vai kas tmldz.)

 

PHP - jāorganizē PHP background procesa atjaunošana, vai jāiebūvē globāls kļūdu pārķeršanas mehānisms.

 

Node - viekāršā gadījumā kļūda būs vienā nolasīšanas eventa ciklā un nekas nav jādara, sarežģītākā gadījumā tas pats kas PHP.

 

Scala/Akka - akka actor-i ir konfigurējami dažādiem kļūdu gadījumiem. Vienkāršā situācijā ieliekam, lai kļūdas gadījumā actors tiek pārstartēts. (Tas ir mēs nedaram neko, jo tas notiek defaultā). Kad rodas kļūda, attiecīgais actor-s tiek pārstartēt un visa aplikācija normāli turpina strādāt. Respektīvi Scala/Akka gadījumā pat, ja mums būs grūti notverama, reta un nepamanīta kļūda, visdrīzāk aplikācija turpinās normāli strādāt.

 

3)Memory leaks kodā

 

PHP - jāorganizē background procesa atjaunošana pēc atmiņas pārpildes.

 

Node - tas pats, kas PHP.

 

Scala/Akka - actor-s pārstartējas un viss turpina normāli strādāt defaultā.

 

4)Performance:

PHP - sensoru lasīšanas procesam 1 - threads, bloķējoša porta lasīšana, kas nozīmē, ka var rasties kaudze performances problēmu, vai arī ir jāveido sarežģītāka aplikācijas koda struktūra - respektīvi jāveito globāls cikls, kurā notiks visas programmas darbības.

 

Node - 1 threads, nebloķējoša lasīšana, kas nozīmē, ka mums lasīšanas datus apstrādā atsevišķi callback-i. Vienkāršāka koda struktūra kā  PHP gadījumā.

 

Scala/Akka - multithread vide, bet bez visām multithread programmēšanas problēmām, pateicoties akka actoru vienkāršajai arhitektūrai + nebloķējoša portu lasīšana + automātiski varam dabūt datu apmaiņu starp stāvokļa un porta lasīšanas actoriem starp vairākiem PC, kas ļauj izveidot liela skaita sensoru lasīšanu no vairākiem PC, tikai ar konfigurācijas rindiņas palīdzību (bez papildus koda).

[e-remit]

codez, gan PHP, gan Nodejs gadījumos datus var glabāt Redis, kas ļaus datus apmainīt arī starp vairākiem procesiem, kā arī strādās pietiekami ātri.

Ja es kaut ko tādu taisītu Nodejs, tad izmantotu Cluster, kas ļautu arī vairākus threadus izmantot un sadalīt slodzi starp procesiem. Pie reizes, ja kāds process nobrūk (kas Nodejs ir normāla parādība), tā vietā automātiski tiek startēts cits process.

Bet nu jā - PHP ir diezgan slikta izvēle šādiem uzdevumiem. Un ja tas ir kas biznesa kritisks, arī Nodejs nav labākā izvēle.

[sharps]

Wuu

Jā zinu par TCP/IP risinājumiem. Arduino, Wiznet utml. Es pieķēros RS485 tīklam, to dabūt uz USB/RS232 dabūt nav problēmu.

Nav vēlme pagaidam čakarēties ar TCP/IP mikrokontrolieru risinājumiem. Tāda lēkāšana vien sanāktu no viena produkta pie otra. Esmu jau pietiekami tālu attīstījis RS485 risinājumu. Teorētiski var pat MODBUSā ielīst, bet pašlaik neredzu tam pielietojumu.

Tātad nolasu dažus temperatūras, pH u.c. devējus (līdz 10gab, nav man tūkstoši). Paši "devēji/sensori" ir pēc savas būtības ir mikrokontrolieri ar sensoru, kas apstrādā analogo signālu (ACP) un tālāk nosūta datus pa RS485 tīklu pēc piepasījuma uz galveno mikrokontrolieri, kas uz displeja indicē šo informāciju. Pašreizējā stadija ir tāda, ka vēlos šos datus noglabāt uz PC datubāzes un izvadīt WEBā nepieciešamības gadījumā. Nolasīšana no sensoriem nu reize minūtē vai pusminūte. Sekundē tas būtu mazliet pa šerpu, jo sensoru rādījumu izmaiņas nav tik straujas.  Seriālā konsolē es tos datus pēc atilstošu komandu nosūtīšanas varu saņemt reālā laikā. Kādēļ izvēlējos PHP, nu var arī Javā vai HTML. Šie piederas pie maniem hobijiem un apgūstu PHP mazliem solīšiem. Daudzas līdzīgas kontrolieru programmas bāzētas HTML un sajūdzas ar MS SQL. Savā laikā kaut ko MATLAB vidē taisīju. Bija arī tāds Liberty Basic ar kuru varēja pa tiešo griezties pie portiem. Bet tas bija tik ļoti nograizīts rīks, ka atmetu to domu. Kā mācību līdzeklis labs. Tas tā īsumā.

 

 

e-remit

Ja varbūt tev taisnība, ka neizvlejos pareizo risinājumu pa PHP runājot.

Esmu redzējis rūpnieciskos kontrolierus uz Java risinājumu. Tomēr cik saprotu beidzamā laikā arī no Java sāk atteikties.

PS

Kaut gan skatos šie bliež augšā uz HTML5.

Edited August 5, 2015 by sharps

[l27]

Priekš MODBUS TCP/IP ir php bibliotēka  https://code.google.com/p/phpmodbus/

 

Man liekas, ka pareizāk būtu visu saslēgt ar TCP/IP un no servera kontrolēt izmantojot šo bibliotēku.

Edited August 5, 2015 by l27

[sharps]

Jā būtība jau no tā nemainās izmanojot to vai citu PHP bibliotēku (manā gadījumā tā ir dio_ext.dll). Manā gadījumā RS485 nav kā MODBUS. Es savu adresācijas un datu sūtīšanas/saņemšanas sistēmu izveidoju, kas ir vienkāršota. MODBUS tomēr ir pakāpi sarežģītāks un paplašinātāks. Neērti ir arī tas ka katram RS485 tīklā esošam mazajam kontrolierim jābūt ar MODBUS.

PS

Vieglāk laikam būu iemest skici ar RS485 konfigurāciju, lai saprastu pa ko iet runa. Vēlāk iemetīšu.

Edited August 5, 2015 by sharps

[rpr]

PHP - jāorganizē background procesa atjaunošana pēc atmiņas pārpildes.

 

codez, ko tu tur stāsti muļķības? Kādas atmiņas pārpildes? Pats esmu dēmonus uz php rakstījis, ja neizmanto kaut kādus bezsakarīgus masīvus un dinamiskus mainīgos, tad arī nekāda pārpilde nav iespējama.

 

Vai tad skalai nevajag rakstīt dēmonu? Nezinu kāda ir darba specifika, bet ja tev vajag regulāru monitoringu un saglabāt datus, tad kā tu bez demona iedomājies to uzrakstīt? Tas, ka skala māk smuki ar asinhronu procesu darboties, nenozīmē, ka tai nevajag kaut kādu bg procesu.