Een correcte programma(project) opbouw? (C++, SQL, GUI)

[sayang1991]

Beste tweakers,

Ik heb vanuit mijn werk de mogelijkheid gekregen om een begin te maken aan een project.
Nu heb ik totaal geen ervaring met programmeren en zou ik graag willen weten of de opbouw welke ik wil gaan gebruiken wel geschikt is hiervoor.
Het daadwerkelijke programmeren zal door mijzelf, collega's en bekenden gedaan worden.

Momenteel gebruikt men Labview om een sensor te benaderen, hierbij kan data uitgelezen worden en settings in de sensor veranderd worden.
Sinds kort kunnen wij ook de sensor koppelen aan een Raspberry Pi en hier met behulp van een C programma data loggen naar een bestand wat weggeschreven word op de Pi.
De Pi is hierbij vanuit het intranet te benaderen en zo kan het logbestand dan ook uitgelezen worden.

De gedachte is om de Raspberry Pi veel (als niet alle) functies van Labview over te laten nemen.
Hiervoor moeten verschillende functies mogelijk zijn:

***

Plaatselijk op de Raspberry Pi (monitor direct aangesloten)
Data uitlezen (Momenteel 1 sensor, wie weet ooit 10?)
Data loggen

Een simpele GUI om;
Data te bekijken (Grafiek)
Sensor instellingen veranderen

***

Op een vaste Windows pc (intranet) .exe
Verbinden met de Raspberry Pi

Een simpele GUI
Data bekijken (Log & Grafiek)
Sensor instellingen veranderen

***

Optioneel:
Via webbrowser (intranet, wie weet internet ooit?)
Data bekijken (Log & Grafiek)
Sensor instellingen veranderen

Het idee is om dit allemaal mogelijk te maken door:
- plaatselijk op de Raspberry een C/C++ programma te laten draaien gekoppeld aan een SQL database (Momenteel word in een .log weggeschreven)
- een GUI te maken (C++?) die plaatselijk op de Pi draait en zijn gegevens uit de SQL database haalt
- een GUI te maken voor windows (Visual studio?) die gekoppeld is aan de SQL database op de Pi
- Optioneel: Idem in webbrowser (Html, PHP, SQL)

Mijn vraag is dus of dit de juiste insteek is zodat begonnen kan worden aan een C/C++ programma welke logt in een plaatselijke SQL database. De rest van de onderdelen zal dan na verloop van tijd kunnen volgen zolang de eerste insteek maar juist is.

*Ik weet niet 100% zeker of dit de juiste plaats op dit forum is voor deze vraag, alvast mijn excuses

[farlane]

Ik zou denk ik alle UI's die je nu bedenkt op dezelfde manier toegang laten krijgen tot de data, met een service op de PI die de koppeling is tussen de opslag en de UI verzorgt. ( Je zou daarbij kunnen denken aan een REST service o.i.d om maar eens wat buzzword technieken erbij te halen. ) In feite koppel je zo dus de manier van opslag los van de UI die je gebruikt.

Het is me in jouw opzet niet duidelijk waar de database zou moeten draaien, maar het is aan te raden om deze lokaal op de PI te laten zodat netwerkproblemen niet zorgen voor gaten in je data logging.

[sayang1991]

Momenteel heb ik inderdaad MySQL draaien op de raspberry en ben begonnen aan het C++ stuk welke data weg logt in de database, dit kan ik zover ik het begrijp direct vanuit mijn C++ programma doen?

De UI's op windows/linux of web komen later pas zodra dit begin stuk goed draait

[farlane]

sayang1991 schreef op dinsdag 03 maart 2015 @ 13:07:
Momenteel heb ik inderdaad MySQL draaien op de raspberry en ben begonnen aan het C++ stuk welke data weg logt in de database, dit kan ik zover ik het begrijp direct vanuit mijn C++ programma doen?

Kijk hier maar eens

[Douweegbertje]

Begin gewoon met het begin.

Dat is gewoon zorgen dat je log data in de database komt te staan.

Dan heb je dat klaar. Vervolgens lijkt het me gewoon simpel om één webapplicatie te draaien op je Pi, want dan kun je gewoon overal dat ding benaderen en je informatie in zien. Wil je ruime uitbreidingsmogelijkheden, dan zou ik per definitie er voor zorgen dat je data niet op de Pi staat maar ergens anders. Dan heb je puur je Pi voor het uitlezen van, en plaatsen van de data. Een 'server' waar deze data staat EN serveert. (Ik heb eigenlijk geen ervaring met een Pi, maar als je veel data hebt, en veel connecties dan is een Pi niet geweldig om én gegevens uit te lezen, opslaan in de db, serveren van de data én een service/website)

Hoe je het dan wilt serveren maakt dan in feite geen snars uit. Of je dit nu via een executable gaat doen, of via een webpagina boeit dan natuurlijk niet.

Eventueel kun je, zoals farlane al aangeeft een soort API maken om de gegevens makkelijker uit te lezen. IMO alleen relevant als je het publiekelijk wilt maken, of eventueel meerdere applicaties de data laten aanspreken. Zodoende hoef je de logica maar één keer te maken (in de API) en niet x-keer in elke applicatie die de DB aanspreekt. In feite elimineer je dan het aanroepen van de DB (in jouw programmatuur dan), maar roep je een service aan waar je de data vandaan gaat halen. Handig, scheelt weer tijd en alles is 10x netter ook met eventuele updates.

Overigens wil ik even vermelden dat het mij nogal een prestige projectje gaat lijken voor jou zelf. Daarom wil ik je ook gewoon aanraden om het eens lekker simpel te houden en gewoon eerst wat te gaan kloten. Op het moment dat je eigenlijk (met alle respect) geen idee hebt wat je wilt gaan doen, of beter gezegd "hoe" , dan moet je er vanuit gaan dat je het ook niet goed gaat krijgen de eerste aantal keren. Sowieso menig programmeur zou al relatief gezien moeite hebben om het echt netjes te krijgen wat jij nu precies wilt gaan doen.
Toevallig heb ik nu wel wat ervaringen met services, API's en dat soort meuk en met je huidige insteek gaat het niet echt lekker werken. Zet dus ook eens wat op papier, je bent al begonnen maar je hebt nog geen idee over hoe of wat? Ja, dat is dus al een enorm slecht begin. Je zult het op zijn minst allemaal moeten uitschrijven, vooral als je je data beschikbaar wilt stellen op allerlei manieren.

[johnkeates]

Ik zou zeggen: zorg eerst dat het op de CLI op de PI werkt, en daarna als dat lekker werkt via een GUI zodat je je project in kant-en-klare deliverables kan opsplitsen.

Daarna kan je schalen door alles via een daemon naar een DB te schrijven en de settings terug te lezen (of een trigger opzetten in de DB die een programma triggert die de settings op de sensors weer aanpast via een persistente connectie). Dat is dan nog sequentieel, dat kan weer parallel gedaan worden door threads per sensor aan te maken, of threads per update te spawnen en te laten eindigen zodra de update klaar is.

Dus:

- Simpele directe CLI communicatie
- Web-CLI bridge
- Web-daemon bridge
- Web-XHR-server-db-daemon

Er zit een klein beetje overlap in, en een klein beetje dubbel werk, maar je eindresultaat is een stuk beheersbaarder op te zetten om dat je dan ervaring hebt en data hebt over de voorgaande stappen.

[armageddon_2k1]

Aangezien je met een peper duur stuk software als Labview werkt ga ik er even vanuit dat de sensordata nogal belangrijk is voor jullie bedrijf. Het belangrijkste aan Labview en z'n sensors die je erop aansluit is dat alles geverifieerd, gecalibreerd en gevalideerd is (zeker als het de fabriek uit komt). Als je dan gaat zitten rommelen met een Raspberry Pi erachter, hoe kan je dan garanderen dat alles nog daadwerkelijk is dat je meet?

[sayang1991]

Als eerste bedankt voor de vele reacties mensen!

En het klopt dat dit een zwaar eerste project is vandaar dat ik ook ondersteuning van collega's krijg hierbij. Voordeel hierbij is dat ik ook een gedeelte in eigen tijd wil gaan doen aangezien dit mij een zeer goede vaardigheid lijkt om op zijn minst kennis mee te maken.

Het begin is trouwens al gemaakt door collega's (het C log programma), mijn taak was als eerste inderdaad uitzoeken hoe de volledige structuur van het project moet gaan uitzien en hierna volgt het stapsgewijs opvullen van de programma's die dit realiseren.

Als ik het nu dus goed begrijp is de eerste stap sowieso eerst eens zelf een beetje kloten met hoe de de sensor uitgelezen word en data gelogt kan worden naar de database. Hier was ik dan momenteel ook mee bezig, direct ook een Pi besteld om thuis wat mee te gaan kloten. Hierbij direct ook wat onderzoek doen naar de informatie wat jullie mij hier hebben gegeven.

De volgende stap is dan duidelijk op papier krijgen hoe ik de opbouw wil maken naar mijn GUI toe, als ik het goed begrijp is het beter de PI dan alleen te gebruiken als opslag voor de ruwe data en alle eventuele bewerkingen niet op de PI zelf te doen?

Maar ik zie dat ik nog een lange weg te gaan al had ik hier wel rekening mee gehouden, toch alvast bedankt!

[farlane]

Je bent volgens mij op dit moment op de goede weg, aangezien je vraagt hoe je je pruttel in de database krijgt. Als dat werk ga je kijken hoe je het er weer uit kunt halen en hoe je het kunt presenteren. Success

[P_de_B]

Kijk in ieder geval eens bij https://github.com/msopentech/connectthedots

Wel een andere technologiestack, maar wie weet kun je er iets mee. Er is ook voorbeeldsoftware voor op de PI

[Douweegbertje]

sayang1991 schreef op dinsdag 03 maart 2015 @ 23:14:
, als ik het goed begrijp is het beter de PI dan alleen te gebruiken als opslag voor de ruwe data en alle eventuele bewerkingen niet op de PI zelf te doen?

Maar ik zie dat ik nog een lange weg te gaan al had ik hier wel rekening mee gehouden, toch alvast bedankt!

Een Pi is niet slecht, maar het is geen rekenwonder. Grote kans dat hij al staat te loeien op het moment dat hij de gegevens moet uitlezen/verwerken. Als ie dan ook nog een DB moet beheren, en daar wordt nogal tegen aangesproken? Mja, dan zal het mij niet verbazen als alles in de soep loopt omdat hij dan niets meer trekt.
Punt is echter dat het afhankelijk is wat je er nu precies mee gaat doen, en hoe intensief dat is. Een Pi is geweldig, maar het is maar ~35$ waard en je CPU is iets van 700MHz.. Je zit dus redelijk snel op het maximale van je Pi.

[EddoH]

Douweegbertje schreef op woensdag 04 maart 2015 @ 09:25:
[...]


Een Pi is niet slecht, maar het is geen rekenwonder. Grote kans dat hij al staat te loeien op het moment dat hij de gegevens moet uitlezen/verwerken. Als ie dan ook nog een DB moet beheren, en daar wordt nogal tegen aangesproken? Mja, dan zal het mij niet verbazen als alles in de soep loopt omdat hij dan niets meer trekt.
Punt is echter dat het afhankelijk is wat je er nu precies mee gaat doen, en hoe intensief dat is. Een Pi is geweldig, maar het is maar ~35$ waard en je CPU is iets van 700MHz.. Je zit dus redelijk snel op het maximale van je Pi.

Zonder context beetje onzin. Een Pi is prima om als loggertje voor een sensorwaarde te gebruiken. Ook is een 'DB' niet een of ander magisch, groot, log stuk software dat je hele CPU leegtrekt. Kies voor een goede db server, bijvoorbeeld sqlite, en je kan er alle kanten mee op. Wat denk je dat er op je telefoon draait?
Bij ons in het bedrijf doen we niet anders dan apparaten maken die (een stuk) minder krachtig zijn dan een Pi en juist voor logging en meten gebruikt worden.

[ Voor 7% gewijzigd door EddoH op 04-03-2015 09:48 ]

[Soultaker]

Ik heb twee opmerkingen:

1. MySQL is overkill als je maar met één applicatie naar de database schrijft (en hoeveel geheugen vreet MySQL wel niet?). Gebruik liever een lightweight database zoals SQLite; die is ontworpen voor dit soort embedded gebruik.
2. Denk eraan dat goedkope hardware als een Raspberry Pi niet per se heel betrouwbaar is. Vooral de SD-kaart wil het nog wel eens begeven, zeker als je er veel naar schrijft (zoals een database natuurlijk doet). Zorg dus voor een backup-plan zodat je niet al je gegevens kwijt bent als de SD-kaart het opeens begeeft.

Douweegbertje schreef op woensdag 04 maart 2015 @ 09:25:
Een Pi is geweldig, maar het is maar ~35$ waard en je CPU is iets van 700MHz.. Je zit dus redelijk snel op het maximale van je Pi.

Een Raspberry Pi 2 (nu te koop voor $35!) heeft een quad-core 900 MHz Cortex-A7 CPU. Voor mensen die het Pentium-tijdperk bewust meegemaakt hebben zijn dat behoorlijk fatsoenlijke specs. Het lijkt me sterk dat je met het uitlezen van een sensor de CPU maximaal kunt belasten.

[Dido]

Soultaker schreef op woensdag 04 maart 2015 @ 09:49:
Voor mensen die het Pentium-tijdperk bewust meegemaakt hebben zijn dat behoorlijk fatsoenlijke specs.

offtopic:
Dank je wel... ik moet nog wennen aan het idee dat mensen die het Pentium-tijdperk niet bewust hebben meegemaakt al uit de luiers kunnen zijn. Kan j evertellen dat je een 8088 wel kunt overbelasten met een paar sensortje... Ik voel me nu echt oud

[Douweegbertje]

EddoH schreef op woensdag 04 maart 2015 @ 09:47:
[...]


Zonder context beetje onzin. Een Pi is prima om als loggertje voor een sensorwaarde te gebruiken. Ook is een 'DB' niet een of ander magisch, groot, log stuk software dat je hele CPU leegtrekt. Kies voor een goede db server, bijvoorbeeld sqlite, en je kan er alle kanten mee op. Wat denk je dat er op je telefoon draait?
Bij ons in het bedrijf doen we niet anders dan apparaten maken die (een stuk) minder krachtig zijn dan een Pi en juist voor logging en meten gebruikt worden.

Eh wat zeg ik dan nou precies. Ik zeg toch juist

Punt is echter dat het afhankelijk is wat je er nu precies mee gaat doen, en hoe intensief dat is.

Als ie dan ook nog een DB moet beheren, en daar wordt nogal tegen aangesproken?

Het is geen onzin en er is gewoon context.

Gewoon logging is geen probleem, maar als je dan daarnaast veel requests gaat doen op de DB en je hebt veel data.. meh dan heb je misschien niet een ideale situatie. En verder prima hoor, maar een Pi is geen goede basis voor een 'databaseserver'. Voornamelijk als je gaat loggen krijg je enorm veel data, je hebt indexen nodig en dan loop je al vrij snel tegen allerlei limitaties aan.
Tenzij je database 50Mb groot is, maar dat kan ik mij niet voorstellen als je 24/7 zit te loggen.

Ik zit hier niet de Pi af te kraken want hij kan namelijk enorm veel, en ja ook een database kan je erop zetten. Echter voor dit doel? Kijk even naar zijn functie eisen, dan gemiddeld wat je allemaal voor data krijgt met logging.. meh wees dan reëel dat je ook even verder moet kijken als dat ding één jaar heeft gedraaid.

[EddoH]

Ik reageerde op:

Douweegbertje schreef op woensdag 04 maart 2015 @ 09:25:
[...]

Grote kans dat hij al staat te loeien op het moment dat hij de gegevens moet uitlezen/verwerken. Als ie dan ook nog een DB moet beheren, en daar wordt nogal tegen aangesproken? Mja, dan zal het mij niet verbazen als alles in de soep loopt omdat hij dan niets meer trekt.

Hoewel ik je zin waarin je zegt dat het context afhankelijk is eerlijk gezegd over het hoofd zag. Maar daarmee zeg je eigenlijk ook dat je er geen uitspraken over kan doen. Je spreekt je zelf dus een beetje tegen.
In 50mb kan je daarnaast behoorlijk wat samples kwijt, het ligt er maar op welke (tijds)resolutie je wilt loggen en hoe lang je gegevens wilt bewaren: oftewel, loze uitspraken zonder specifieke details.

Om nog wat nuttigs bij te dragen voor de TS: zet even op een rijtje welke data je wilt kunnen loggen, welke eisen daar aan zitten, hoe lang je wilt kunnen loggen, etc, en pas daar je platform en structuur op aan.
Een voor de hand liggende oplossing is bijvoorbeeld om de Pi als buffer te gebruiken, en al naar gelang je wensen de data daarna naar een server te pushen, waar vervolgens uitgebreide analyse en presentatie kan plaatsvinden.

[Douweegbertje]

Probeer eens te relativeren wat iemand zou bedoelen, simpele opmerkingen zoals 'om wat nuttigs bij te dragen' alsof de rest niet nuttig is gaat nergens over.
Ik geef een valide punt aan; dat TS moet kijken of de Pi wel geschikt is voor alles wat hij wilt doen. Nergens geef ik iets anders aan. Het is echter wel van belang om vooraf te checken wat je wilt.

In feite je 2e alinea verteld precies het zelfde wat ik al heel de tijd aangeef... en ik spreek mezelf nergens tegen zoals je weer beweert. Ik gooi gewoon even wat dingen op die TS zelf moet beoordelen. Echter komt het nu wel tenminste ten sprake wat heel het doel is.

[EddoH]

Douweegbertje schreef op woensdag 04 maart 2015 @ 12:21:
Probeer eens te relativeren wat iemand zou bedoelen, simpele opmerkingen zoals 'om wat nuttigs bij te dragen' alsof de rest niet nuttig is gaat nergens over.

Daarmee bedoelde ik dat ik in mijn eigen post nog wat nuttigs voor de TS wilde zetten, in plaats van alleen hier met jou te gaan discussieren.
Ik val vooral over de toon warmee je het hele plan van de TS eigenlijk een beetje onderuit haalt, zonder dat daar tot nu toe concrete reden toe is.

Ik kan heel goed indenken wat de TS wil bereiken, en daar zou een embedded bordje als logger helemaal geen slechte keus zijn. Het enige wat jij roept is dat het mogelijk niet kan, dat de Pi 'waarschlijnk flink staat te loeien' en als ik er wat van zeg roep je dat het helemaal context afhankelijk is. Wat voeg je dan nog toe?
Anyway, laten we hier niet het topic verder mee vervuilen en anders PM je me maar.

[ajakkes]

Ik zou de sensor direct naar een Amazon server laten schrijven want die schaalt mee met de behoeftes.

Zoals altijd zal je na verloop van tijd tegen de grenzen van je apparatuur aan lopen. Als het iets kan moet het daarna altijd meer kunnen.

Maar beginnen met data uit een sensor uit lezen en lokaal in database op slaan ipv in logbestand is een stap vooruit.

De logbestanden zijn niet oneindig groot en de database zal dat ook niet zijn.

En deze database is veel eenvoudiger in GUI te verwerken dan logbestanden.