RS232 vai USB + PHP

[F3llony]

Codez nejēdz kodēt. Tas arī viss.

 

PHP var forkot cik vien ienāk prātā, un tas starp citu ir nu ļoti vienkārši izdarāms, līdzīgā manierē kā ar Node subprocesiem, līdzīgā manierē kā Java tredi, līdzīgā manierē kā to dara Skalas aktori, tikai ar nelielu sintactic sugar ar mazāku kontroli pār internals.

 

Also, tava tizlā "sensoru lasīšana" mani nedaudz kaitina. Sensorus nelasa, sensori paziņo. Ja sensors nejēdz ziņot, tad dotais sensors ir stulbs sensors. 

 

Also, sampling. 

[sharps]

F3llony tieši sensorus ir jālasa.

Iedomājies kas par bardaku būs ja vairāki slave sensori pēkšņi izdomās RS485 tīklā sūtīt datus. Tam ir domāta viena Master ierīce, kas secīgi apvaicā visus sensorus pēc to adresēm. Manā gadījumā vienlaikus nevar runāt divas ierīces. Sensors ir digitalizēts, t.i. tīri fizikāls sensora elements temperatūras devējs, kā rezistīvs PT100 vai kāda cita tipa devējs. Tad ACP, kas šo signālu nociparo un tālāk pa I2C vai SPI tiek sūtīti dati uz kontrolieri, kas šo Bināro kodu pārveido decimālā formātā un apstrādā saprotamā formātā ierakstot noteiktā reģistrā. Visas šīs darbības notiek onlainā. Teiksim sekundē tiek veikti daži simti mērījumi un tad izvilkta vidējā vērtība uz laika vienību. To tālāk pieprasa Master ierīce. Iedomājies, kas notiks ja to visu Slave ierīces sāks nonstopa grūst vados iekšā. Sākumā masteram ir jāpieprasa viena slave adrese, tad tā atbild. Viss ok. Tālāk tiek apvaicāta otra slave adrese utt. Elektronikā tikai šādi tā saziņa notiek.

Principā no elektronikas puses to var organizēt dažādi. Ir daudz gatavi (ne lēti) risinājumi ar Master kontrolieri un IO moduļiem (tie savā starpā sazinās pa specifiskiem protokoliem), kas pa tiešo nolasa analogo signālu un tad nociparo. Tur ir teiksim viena ACP 16bitu ieeja kuru multipleksē uz vairākiem sensoriem. Tā ka arī šeit sensors nu nekādi nevar runāt īpaši jau rezistīvs elements.

[codez]

PHP var forkot cik vien ienāk prātā, un tas starp citu ir nu ļoti vienkārši izdarāms, līdzīgā manierē kā ar Node subprocesiem, līdzīgā manierē kā Java tredi, līdzīgā manierē kā to dara Skalas aktori, tikai ar nelielu sintactic sugar ar mazāku kontroli pār internals.

Lai uzrakstītu pareizu multithread kodu, kur vairāki thread-i strādā ar datiem vairākās datu struktūrās, ir jāiegulda pamatīgs darbs un vajadzīgas precīzas zināšanas par visām niansēm. Ir jāievieš lock-i un sinhronizācija, jāievēro ļoti strikta (arī ierobežojoša) koda struktūra, lai netiktu likti lock-i uz ilgstošiem procesiem, netiktu likti tie paši lock-i funkcionalitātē, kura viena otru izsauc, jāievēro lock-u likšanas kārtība, pareizi jāapstrādā lifelock-i un deadlock-i, vispārīgā gadījumā, lai viss strādātu pareizi, ir jāievieš rollback-i.

Varu saderēt, ka Felonijs nespētu pat korekti uzrakstīt multithread programmu, kura paralēli procesi izmanto, piemēram, Map-u, nerunājot par sarežģītākām datu struktūrām.

 

Actor-u modelis tieši tāpēc arī tika izveidots, jo tas ļauj ātri, ērti, ar mazāku iespējamo kļūdu daudzumu, uzrakstīt paralēli darbojošos programmu, kura spēj izmantot visus pieejamos resurus un kura spēj jau defaultā kļūdu gadījumā pašatjaunot savu darbību ar pēc iespējas mazākiem "zaudējumiem".

Bez tam Scala Akka actor-u modeļa paralēlums nebalstās uz multithreading-u, kurš ir lēns dēļ konteksta pārslēgšanās, bet ir event based risinājums, kurš māk darboties vairākos thread-os un izmantot visus CPU kodolus, tātad krietni ātrāks par tīru mutithreaded risinājumu.

[codez]

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.

 

Ko darīt, ja nu tomēr vajag izmanot masīvus un ne 1D, bet 3D un gadās pielaists memory leaku, kurš izpaužas 0,01% gadījumu? Programma palaista produkcijā un ik palaikam sāk neizprotami nokārties. Zaudēts dārgais laiks un klienti.

 

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.

Scalā tu raksti uz JVM palaižamu programmu. Nav nozīmes, vai tu to palaid kā dēmonu, vai palaid caur konsoli un kontrolē caur user interfeisu. Ja tu izmanto Akka bibliotēku, tad programmas komponentes darbojas diezgan neatkarīgi un tava programma vienlaikus var saturēt kā kontrolieri, kurš atbild uz http requestu, tā websocket handlerus, tā actor-u, kurš tiek izsaukts, piemēram, reizi sekundē vai reaģē uz citu actor-u sūtītām ziņām.

Piemērā par sensoru lasīšanu tas varētu izskatīties šādi, ir MVC kontroleris, kurš pieprasa datus stāvokļa actor-am un aizsūta to klientam, ir sensora lasīšanas actor-s, kurš ar atbilstošu regularitāti lasa sensora datus un aizsūta tos stāvokļa actor-am. Ja datiem ir jāveic pietiekami sarežģīta apstrāde, var izveidot apstrādes actor-us, kurus palaižot var palaist, piemēram, caur actor-u routeri, kas ļauj šiem apstrādes actor-iem sūtīt apstrādājamo informāciju paralēla manierē, tādā veidā samazinot response laiku. Tas viss notiek vienas programmas ietvaros. Taču es varu šo programmu palaist uz vairākām fiziskām kastēm un sakonfigurēt, ka, piemēram, sensoru actori atrodas vienās kastēs, apstrādes actori citās un to savstarpējā komunikācija automātiski pāries no programmas slāņa uz TCP slāni.

[sharps]

Drusku jau aizgāja pa sarežgītu desmit sensoru nolasīšanā. Principā ir pieejami maksas risinājumi konkrētiem kontrolieriem un izpaužas kā web serveris uz html. Tā pati Niagara, shneiderim bija kaut kas utml ražotājiem. Tas arī datus nolasa un iegrūž SQL datu bāzē. Man tīri zinātniska interese tīri par PHP. Vēl neesmu pieķēries klāt Blitz ieteiktajam variantam laika trūkuma dēļ.

 

PS

iemetu blokshēmu tam visam.

 

Edited August 6, 2015 by sharps

[F3llony]

F3llony tieši sensorus ir jālasa.

Iedomājies kas par bardaku būs ja vairāki slave sensori pēkšņi izdomās RS485 tīklā sūtīt datus. Tam ir domāta viena Master ierīce, kas secīgi apvaicā visus sensorus pēc to adresēm. Manā gadījumā vienlaikus nevar runāt divas ierīces. Sensors ir digitalizēts, t.i. tīri fizikāls sensora elements temperatūras devējs, kā rezistīvs PT100 vai kāda cita tipa devējs. Tad ACP, kas šo signālu nociparo un tālāk pa I2C vai SPI tiek sūtīti dati uz kontrolieri, kas šo Bināro kodu pārveido decimālā formātā un apstrādā saprotamā formātā ierakstot noteiktā reģistrā. Visas šīs darbības notiek onlainā. Teiksim sekundē tiek veikti daži simti mērījumi un tad izvilkta vidējā vērtība uz laika vienību. To tālāk pieprasa Master ierīce. Iedomājies, kas notiks ja to visu Slave ierīces sāks nonstopa grūst vados iekšā. Sākumā masteram ir jāpieprasa viena slave adrese, tad tā atbild. Viss ok. Tālāk tiek apvaicāta otra slave adrese utt. Elektronikā tikai šādi tā saziņa notiek.

Principā no elektronikas puses to var organizēt dažādi. Ir daudz gatavi (ne lēti) risinājumi ar Master kontrolieri un IO moduļiem (tie savā starpā sazinās pa specifiskiem protokoliem), kas pa tiešo nolasa analogo signālu un tad nociparo. Tur ir teiksim viena ACP 16bitu ieeja kuru multipleksē uz vairākiem sensoriem. Tā ka arī šeit sensors nu nekādi nevar runāt īpaši jau rezistīvs elements.

 

Nu ne gluži. Ne velti es pieminēju semplošanu. Tavai arhitektūra nebūs īpaši efektīva, ne pat īsti stabila. 

 

Ar tavu RS485 M/S arhitektūru:

 

Tev ir master, kas ik X msec pieprasa sleivam statusu un to reģistrē. Sleivs reportē statusu. Tu glabā katru (vai ja nedaudz pieķēpā loģiku - katras izmaiņās) stāvokli. Tu saņem atjauninājumus no sensoriem noteiktos intervālos un vari palaist garām anomālijas kas var notikt šo intervālu starplaikā. Jo vairāk sensoru - jo lielāks starplaiks.

 

Ar manu ne-RS485/jebkuru inverse multicast:

 

Tev ir master. Sensors ir gudrs (lasi - slave, digitalizēts un stand-alone, praktiski PnP). Sensors ik pēc X (m)sec ziņo, ka ir dzīvs (ping). Sensors paziņo masteram aktuālo lasījumu brīdī, kad tas mainās salīdzinot ar sākuma stāvokli (0).

 

Rezultāts: tu vienmēr zini, ka sensors ir dzīvs neapstrādājot liekus datus, un tu saņem info par sensora stāvokļa maiņu lai nepiesātinātu ne tīklu, ne datubāzi ar lieku informāciju.

 

Abām arhitektūrām ir plusi un mīnusi - pirmā ir relatīvi vienkārša, low level, un darbosies labi vienkāršākajos gadījumos. Otrā ir ievērojami dārgāka un sarežģītāka implementācijā, taču labi skeilojas un ir pamatā diezgan stabila. Ja pievieno inverse broadcast, arī spof noturīga.

 

 

Varu saderēt, ka Felonijs nespētu pat korekti uzrakstīt multithread programmu, kura paralēli procesi izmanto, piemēram, Map-u, nerunājot par sarežģītākām datu struktūrām.

 

Pirmkārt, bezdēt gribēju uz taviem monolītiskajiem, inter-tredu piebāztajiem monstriem. Otrkārt, tu man vispirms parādi kādu kaut cik populāru keisu, kur darbs ar dajebkādām datu struktūrām atmiņā starp vairākiem trediem ārpus datubāzēm un datastorēm ir vajadzīgs, un tad parunāsim.

[Kasspars]

^ tu vairāk laika būtu veltījis programēšanai nevis visādu gifu meklēšanai

[F3llony]

^ tu vairāk laika būtu veltījis programēšanai nevis visādu gifu meklēšanai

Es programmēju 9-12 stundas dienā. Es domāju, pietiks... 

[codez]

Pēc felony komentāra var 100% droši spriest, ka viņam nekad nav bijusi saskare ar šādu sistēmu izstrādi. Davai, fellony, interneta veikala linku uz reālu tavu "gudro" temperatūras sensoru (ar cenu).

 

Otrkārt, tu man vispirms parādi kādu kaut cik populāru keisu, kur darbs ar dajebkādām datu struktūrām atmiņā starp vairākiem trediem ārpus datubāzēm un datastorēm ir vajadzīgs, un tad parunāsim.

Piemērs - Massive multiplayer realtime spēle, kur katrs spēlētājs var izmainīt pasaules stāvokli + paralēli pasaules stāvoklis jāmodelē neatkarīgi no spēlētājiem. Bet nav brīnums, ka tu ar tādiem gadījumiem neesi sastapies, jo ņemies ar kaut kādiem vizītkaršu līmeņa projektiņiem.

[F3llony]

Pēc felony komentāra var 100% droši spriest, ka viņam nekad nav bijusi saskare ar šādu sistēmu izstrādi. Davai, fellony, interneta veikala linku uz reālu tavu "gudro" temperatūras sensoru (ar cenu).

 

Piemērs - Massive multiplayer realtime spēle, kur katrs spēlētājs var izmainīt pasaules stāvokli + paralēli pasaules stāvoklis jāmodelē neatkarīgi no spēlētājiem. Bet nav brīnums, ka tu ar tādiem gadījumiem neesi sastapies, jo ņemies ar kaut kādiem vizītkaršu līmeņa projektiņiem.

Galīgi nojūdzies esi? Tu gribi teikt, ka autonomi sensori (aļa advanced metering infrastructure) un sensoru tīkli neeksistē? :D Interesanti, kā tad implementētas gāzes un ūdens apgādes autonomās sistēmas un citi sensoru tīkli (aļa smart grid), un kam tad diez eksistē tādi protokoli kā OSGP, M-Bus utt. utjp. Atkal tu lien ar savu gudrību tur, kur tev nav nekādas sajēgas. 

 

Cenas un veikalus tev meklēt netaisos, ir man labākas nodarbes kur laiku tērēt. Bet ja dikti gribi es tev varu nopārdot savu arduino - sākumpunktam, tā teikt. Lai gan raspberijs ar cylon varētu būt elegantāks.

 

Un tavs piemērs par MMORPG ir no sēžamā izvilkts - patiesībā, ir tieši pretēji: massively scaled realtime sistēmas pat sapņos nerādās nodarboties ar tādām perversijām, tāpēc ka cilvēki, kuriem pieredze ir praktiska nevis no uz wikipēdiju bāzēta saprot, ka arī konkrētās izmaiņas ir elementāri implementējamas kā rolling mutation model - izvairoties no visa tā overheada ko tu tagad centies tur iebāzt. Vari pameklēt kaut vai EVE online arhitekturas blogpostus un papers kā tas notiek realitātē nevis tavā neloģiskajā prātiņā. 

 

 

Un par to tavu piezīmi par vizītkaršu projektiņiem - tev vispār ir kaut kāda nojausma ar ko es realitātē nodarbojos? Vai arī tu vienkārši gvelz lai dzesētu muti. Cita starpā, mēs jau kuro gadu gaidam kaut vienu tavu produkcijas projektu redzēt. Būtu tā kā laiks atrādīt.

Edited August 6, 2015 by F3llony

[ieleja]

"kas mīlējas, tas ķīvējas",

(sens latviešu sakāmvārds)

[codez]

Ko tu domāji ar "rolling mutation model"? Izskatās, ka terminus izzīd no pirksta.

https://www.google.lv/search?q=rolling+mutation+model

 

Bez tam tavi mēģinājumi iestāstīt, ka pasaulē nekur produkcijā neizmanto starp thread-iem šārētus stāvokļus, par tevi neko labu neliecina.

Skat, SO ir 22k jautājumi ar atslēgas vārdu mutex: http://stackoverflow.com/search?q=mutex

Tak jebkuras multithreaded programmas cache būs thread-safe datu struktūra. Jebkurā programmā, kur 2 threadiem kaut kādā veidā vajadzēs sazināties, apakšā būs thread-safe datu struktūra. Tas, ka, piemēram, Scala/Akka gadījumā man nav jāuztraucas par thread-u drošību, kad actor-i sazinās viens ar otru, ir konkrētā framework-a risinājums, kuru zem pārsega nodrošina thread-u drošas datu struktūras.

 

P.S. Visi tavi minētie autonomie sensori tiek lasīti, pieprasot lasījumu. Bez tam tas, ko tu sauc par gudro sensoru, patiesībā ir mikroprocesors vai mikrokontroleris + sensors. Un sava autonomā sensora gadījumā, tu nolasi datus no mikrokontrolera, nevis no sensora. Savukārt mikrokontroleris nolasa no sensora. Pat tavā pieminētajā OSGP protokola, tu sūti pieprasījumu nolasīt datus un tad tie tiek atgriezti, nevis sensors konstanti sūta savus datus, kā tu te apgalvo.

[F3llony]

 

"Rolling mutation model is a lockless subject manipulation methodology, mostly implemented in distributed systems programming. It is usually implemented as mutable state subject and single-pipe, in memory or semi-persistant queuing system that accepts broadcasted changes to the state and redistributes given state changes back to observers while also mutating the subject itself, in a similar way how a observer pattern is implemented, but with a distinct traits of a) having a single-pipe queue b) distributing mutations, instead of state. Rolling mutation models are best used when mutation from state X to state Y requires a known, relativistic mutation, e.g. is deterministic and past state is immutable. This approach is useful when processing large amount of mutational data in highly concurrent systems, in both near-realtime systems and offline processing, as it only allows for single manager to manipulate state, hence, does not require locking." © basics of near-stateless system design, by a guy writing code that somehow manages to process millions of mutations every. damn. minute.

 

a = 0; +1; -1; +5; -2; +4; a?=7

 

Un es nevienā brīdī neesmu teicis, ka locki netiek izmantoti nevienā vietā vai lietā, bet tie ir specifiski gadījumi ar noteiktu mērķi un pamatojumu, piemēram, tranzakciju apstrādei kas nav vērtību mutācija. SO ir arī 6k jautājumu pie lock free, lai gan ko tas izsaka es toč nesaprotu. Ko tu centies ar to pateikt? Ka eksistē lokošana? Okei. Ko tālāk?

 

 

 

Bez tam tas, ko tu sauc par gudro sensoru, patiesībā ir mikroprocesors vai mikrokontroleris + sensors

Un kāpēc tu domā to sauc par gudro sensoru, m? Tāpēc, ka šamam ir hobijs - pankūkas cept? Par gudrajiem sensoriem dēvē tieši to un ne tikai to - tas var būt sensors + mikrokontroliers līdz pilnīgs standalone sensors + mikrokontroliers + tīkla interfeiss + lokāla DB.

 

OSGP sensor bus specenes pirmā versija nosaka, ka slave var iniciēt reģistrāciju, taču palasot tālāk par to vienu doku un pirmajām 3 rindkopām tu noskaidrosi, ka tā pat, kā M-Bus, arī OSGP var darboties inversi.

 

Un zinu to es tāpēc, ka man mājās ir 3 M-Bus sensori, kas pie izmaiņas pie noteikta thresholda or ik pēc X laika sūta datus aggregatoram čerez tcpip. Ir dažādi risinājumi dažādās valstīs dažādiem provaideriem, dažādu iemeslu dēļ. Ir sensori kas atgriež vērtības pēc pieprasījuma, ir sensori kas atgriež vērtības konstanti ar praktiski nekādu intervālu un ir tādi, kas paši reportē. 

 

Diskusiju neturpināšu kamēr neredzēšu kaut vienu produkcijas projektu ar lockiem. Vai vispār kaut vienu produkcijas projektu. Vēlams ar vismaz vienu lietotāju, kas neesi tu.

[codez]

Ha, ha, tas, kam tu iedevi nosaukumu "Rolling mutation model" un ko nav nekādu referenču internetā un šādu nosaukumu Google nepazīst, bet spriežot pēc tava apraksta, ir vienkārša stāvokļa mainīšana viena threada ietvaros.

 

 

as it only allows for single manager to manipulate state

 

Jautājums, kā viņš (single manager) saņems ziņas no vairākiem citos thread-os atrodošiem procesiem? Tikai caur kaut kādu viņa messega queue, kura tik un tā kaut kādā līmenī saturēs multi thread drošu queue datu struktūru. Tas ir principā tas, kas notiek Scalā/Akkā. Actoram ir messega queue, kuru viņš apstrādā pēc kārtas un par savu stāvokli atbild pats, tāpēc tev nav jāuztraucas par mutithread drošumu, jo apakšā jau ir droša multi thread datu struktūra (šajā gadījumā - message queue).

 

Un jā, pēdējo reizi multi thread aplikāciju ar paša nodrošinošu datu lokošanu taisīju gadus 8 atpakaļ. Tagad sen jau to nedaru, jo tā pati Akka to nodrošina vienu abstrakcijas līmeni zemāk un man tas nav jādara. Bet, ja nu gadījumā ir vajadzīgs nolaisties arī zemāk, tad ir kaudze jau gatavu un pārbaudītu thread-safe datu struktūru (mapi, seti, listi, utt.)

[jurchiks]

Still going on with the same stupid & pointless arguing...