[PHP/GD] Specifieke grafiekdata ophalen uit txt-file

[Pizza_Boom]

Hoi allemaal,

ik hoop dat ik hier goed zit met deze vraag, ik heb de headers gelezen, normaal woon ik in EL en van PHP heb ik weinig kaas gegeten. Belangrijk is, vind ik, om meteen te vermelden dat alles wat ik hier ga vragen, moet draaien op een RPi B+. Ik ben bezig met een meet en regelsysteem. Er wordt e.e.a. geregeld aan de hand van bepaalde metingen. Een soort mini domotica, maar toch net anders. De hele RPi moet uiteindelijk "bediend" worden vanuit een webpagina. Dat lukt an sich wel, een knopje maken in HTML en daar een actie aan verbinden kan zelfs ik.

Ik heb GD gevonden en geïnstalleerd, mooie library om grafiekjes mee te maken. Deze pagina bood een hele mooie basis, aan de hand daarvan heb ik een grafiekje doorgebouwd. Op dit moment genereer ik data aan de hand van een random formule met gedempte output. Levert voor de bühne een leuke grafiek op, maar zegt nog helemaal niets.

In een ander deel van de programmatuur lees ik met behulp van een C routine data van een I2C connectie uit naar een txt file. Dat gaat goed, ik krijg een waarde van 0 tot 255 terug (1 byte data per sending) en die schrijf ik, voor nu, direct naar het txt file. Gewoon mooi keurig 1 byte per regel, na iedere schrijfactie start ik dus weer op een nieuwe regel. Eventueel kan ik daar nog een index getal voor zetten, dat is 2 seconde schrijfwerk. Ik verwacht dat het makkelijker is om de conversie naar bruikbare data te doen in het C bestandje dan in het PHP scriptje, omdat het PHP scriptje al relatief veel uit moet voeren en eigenlijk snel klaar moet zijn, dus dat laat ik even ter zijde. Die conversie maken gaat mij nog wel lukken.

Nou wil ik natuurlijk die data weer uitlezen. Eenieder die wel eens een grafiekje met GD gemaakt heeft, weet dat je daarvoor een aantal samples nodig hebt. En daar zit mijn vraag. Ik wil graag die samples uitlezen uit het txt filetje. En daarin blijken zoveel mogelijkheden te zijn, dat ik met mijn beperkte PHP kennis door de bomen het bos niet meer zie.

Volgens mij zou het script in de basis zo moeten werken, maar ik wil meer, dat heb ik alvast in comments in de code gezet.

PHP:

$f = fopen("file.txt", "r");

#count samples;
#while(current sampe < total samples){
#use specific column data
echo fgets($f); 
#$ypoint = echoed data
}
fclose($f);

Ik wil niet meer samples lezen dan dat er opgeslagen zijn. dus overal waar geen waarde is, hoeft ook geen grafiek getekend te worden. De vertalingsslag van waarde uit mijn I2C communicatie naar waarde die de GD library zal kunnen gebruiken, is zo gedaan. Eigenlijk wil ik nog een extra kolom met daadwerkelijke waarde (niet de waarde die de grafiek nodig heeft), dus zal ik ook de juiste kolom moeten selecteren.

Voor een deel heb ik dan ook wel wat aan deze en deze HTML lessons, maar niet voldoende. Vandaar mijn vraag hier. Van Google word ik ook niet wijzer, heel veel is in perl of juist het opslaan van data ofzo, maar niets geeft echt antwoord op mijn specifieke situatie of draagt het lastige deel bij. Combineren van oplossingen zou kunnen, maar de juiste combinatie heb ik nog niet gevonden.

Alvast bedankt voor jullie hulp.

[Matis]

Je geeft aan dat de webserver icm PHP op een RPi moet komen te draaien.
GD is een vrij zwaar en log pakket, waar je RPi een behoorlijke kluif aan zal hebben.

Mijn tip is om het tekenen van de grafieken client side te laten doen. Er zijn genoeg JS libraries te vinden die grafieken kunnen tekenen.
Domoticz, dat ik ook op mijn RPi draai, rendert de grafieken ook client side.

Bijkomend voordeel is dat, indien je de data asynchroon opvraagt, de site snel laadt en nog responsive blijft ook.

[xleeuwx]

Vanwege censuur op Tweakers is deze reactie komen te vervalen.

[ Voor 102% gewijzigd door xleeuwx op 01-12-2015 13:09 ]

[RobIII]

xleeuwx schreef op maandag 30 november 2015 @ 23:36:
Even snel een opzetje gemaakt met PHP / JS:

en wat commentaar bij gezet zoals sources die wat meer uitleg geven over de functies / methodes die ik heb gebruikt.

https://github.com/xleeuwx/php_graph

Heb ik jou niet al eens vaker verteld:

Give a man a fish and feed him for a day. Teach a man how to fish and feed him for a lifetime.

Update: Excuus, mea culpa, ik vergis me; dat was iemand anders (zover ik kan zien/vinden zo snel). Maar volgend geldt daardoor niet onverminderd ook voor jou

Je bedoeling is goed maar de/een oplossing kant-en-klaar aandragen gaat de TS op de lange(re) termijn écht niet helpen. Je kunt TS veel beter naar de benodigde functies en libraries verwijzen en wat tips in de juiste richting geven. Los daarvan: als je nu besluit over een paar dagen/weken/jaren deze github repo (of je hele account) op te doeken is het topic niet meer bruikbaar; waarom niet gewoon code (lees: niet dé (hele!) code) posten in code tags hier in dit topic? Je beperken tot een paar snippets / handje vol regels code zou voldoende moeten zijn om TS op gang te helpen.
Anyway, lang verhaal kort: ik zou 't op prijs stellen als je volgende keer wat minder voorkauwt

(Los daarvan: je code is nu GPLv2, 381 legalese-regels lang in al zijn glorie, meer dan de code zélf. Afhankelijk van de situatie van de TS is daarmee je oplossing mogelijk compleet onbruikbaar als hij/zij in een schuitje zit waar het gebruik van GPL'ed code, om wat voor reden / company-policy dan ook, uitgesloten is. Je legt nogal wat verplichtingen op met GPL2 )

xleeuwx schreef op maandag 30 november 2015 @ 23:36:
ps. ben structureel tegen cross site scripting maar voor test doeleinde zoals dit is het ok.

Waar is de "cross site scripting" dan Je gebruikt een CDN voor een library maar dat maakt 't nog geen "cross site scripting" (je bedoelt overigens same origin policy waarschijnlijk, cross site scripting is een bepaalde vulnerability Maar de SOP is hier helemaal niet van toepassing ).

xleeuwx schreef op maandag 30 november 2015 @ 23:36:
en wat commentaar bij gezet zoals sources die wat meer uitleg geven over de functies / methodes die ik heb gebruikt.

With all due respect, en ik wil nu écht niet klinken of ik de pik op je heb want dat is niet zo : als ik even de comments afga:

1. Voegt 0,0 toe
2. Enigszins (kleine) toevoeging
3. Onwaar; er wordt daar helemaal niets ge'processed' maar gewoon aan een array toegevoegd
4. Geen comment maar dead code
5. Geen comment maar dead code
6. No shit sherlock; dat staat in de volgende regel ook; m.a.w.: voegt niets toe (Don't write what code is doing (dat staat er namelijk letterlijk in code...), write WHY it's doing it (the way it does))
7. Enigszins van toegevoegde waarde
8. Handig, maar waarom staat die niet hier?
9. WTF? Waarom niet "to the horse's mouth" verwijzen?
10. WTF? Het daar geaccepteerde antwoord is bout en het antwoord met 9 votes is pas van toepassing; maar ook hier weer: Waarom niet "to the horse's mouth" verwijzen?

Zie (heel) deze post als opbouwende en goedbedoelde kritiek; ook ik probeer jou nu te leren vissen

[ Voor 82% gewijzigd door RobIII op 01-12-2015 00:59 ]

[Pizza_Boom]

Matis schreef op maandag 30 november 2015 @ 22:58:
Je geeft aan dat de webserver icm PHP op een RPi moet komen te draaien.
GD is een vrij zwaar en log pakket, waar je RPi een behoorlijke kluif aan zal hebben.

Mijn tip is om het tekenen van de grafieken client side te laten doen. Er zijn genoeg JS libraries te vinden die grafieken kunnen tekenen.
Domoticz, dat ik ook op mijn RPi draai, rendert de grafieken ook client side.

Bijkomend voordeel is dat, indien je de data asynchroon opvraagt, de site snel laadt en nog responsive blijft ook.

Excuus, ik was blijkbaar niet helemaal duidelijk. Ik draai echt op de RPi. Daaraan hangt een scherm in kiosk-mode. Vandaar ook mijn opmerking: "Een soort mini domotica, maar toch net anders." Dus cliënt side of hostside maakt in dit geval niet uit, het is een en hetzelfde apparaat dat het zal moeten oplossen. Ik denk nog steeds dat qua belasting een redelijk formaat domoticasysteem de beste vergelijking geeft.

Overigens lees ik nu dat ik nog een belangrijk punt vergeet te melden in de OP: De kans dat er een upgrade zal komen naar Pi 2B is nagenoeg 100%. Geeft wat lucht in de prestaties van het apparaat.

xleeuwx schreef op maandag 30 november 2015 @ 23:36:
Even snel een opzetje gemaakt met PHP / JS:

Behalve het complete gebrek aan kennis van javascript/AJAX, terwijl ik van PHP de eerste stapjes begin te begrijpen (ik ben geschoold in werktuigbouw en elektrotechniek, dus programmeren van uCtjes is iets wat ik nog wel gedaan heb, bijvoorbeeld in C, maar daarna houdt wel op. HTML moet ik veel voor googlen.), denk ik (maar daar kan ik de plank compleet mis slaan) dat ik nog een voordeel heb aan de GD lib: Ik draai deze in een 100% losse pagina, die ik vervolgens integreer in een andere pagina. Die mogelijkheid haal ik nog niet direct uit je geposte code.

Er zit op dit moment wat javascript in de desbetreffende pagina's, maar ik heb zelf juist het gevoel dat deze scripts nogal een grote belasting leggen op de RPi. Sinds deze scripts draaien, lijkt de CPU usage van de pi behoorlijk hoger. Kan an sich wel kloppen, want die scripts zorgen voor een continue uitlezen van enkele pinnen en koppelen dit redelijk direct terug.

RobIII schreef op dinsdag 01 december 2015 @ 00:11:
niet meer bruikbaar

Dit beschrijft wel heel goed de hits van een aantal problemen die ik gegoogled heb de afgelopen weken.

(Los daarvan: je code is nu GPLv2, 381 legalese-regels lang in al zijn glorie, meer dan de code zélf. Afhankelijk van de situatie van de TS is daarmee je oplossing mogelijk compleet onbruikbaar als hij/zij in een schuitje zit waar het gebruik van GPL'ed code, om wat voor reden / company-policy dan ook, uitgesloten is. Je legt nogal wat verplichtingen op met GPL2 )

Alhoewel men bij mij redelijk makkelijk is met open source, denk ik dat het in dit geval, zeker met her-distributie eisen, niet geheel op prijs gesteld gaat worden.

Thanks voor de antwoorden, maar ik ben nog niet overtuigd om over te gaan op de javascript versie.

[Gomez12]

RobIII schreef op dinsdag 01 december 2015 @ 00:11:
[...]

• No shit sherlock; dat staat in de volgende regel ook; m.a.w.: voegt niets toe (Don't write what code is doing (dat staat er namelijk letterlijk in code...), write WHY it's doing it (the way it does))

Deze wil ik toch wel even uitzonderen, want deze kan ik wel van toegevoegde waarde vinden mits je een strikte code-richtlijn hanteert (welke is niet zo relevant).

Ik vind het namelijk wel makkelijk om snel mijn error-messages te kunnen vinden zodat ik snel wat algemene condities naderhand af kan gaan om te kijken of ik wel alles gepakt heb. En dat gaat niet zo makkelijk met zoeken op random echo-messages. Dus iets in de trant van :

PHP:

// Error-condition : File could not be opened

En in "reguliere" programmeertalen heb ik het niet nodig, want die ondersteunen wel try-catches wat voor mij hetzelfde doel dient, alleen php kent intern weer niet standaard exceptions

Dus met een beetje meer structuur zou ik deze nog wel verdedigbaar vinden.

[Gomez12]

Pizza_Boom schreef op dinsdag 01 december 2015 @ 01:02:
[...]
Excuus, ik was blijkbaar niet helemaal duidelijk. Ik draai echt op de RPi. Daaraan hangt een scherm in kiosk-mode.

Eigenlijk maar 1 vraag : Waarom? Waarom niet gewoon scheiden?

GD-lib is redelijk zwaar, maar dat is browser/JS ook. Grafisch iets doen op web is gewoon "zwaar".
Ga je dat op 1 RPI doen dan heb je kans dat je gewoon cycles gaat missen.

Imho heb je gewoon 2 perfect gescheiden dingen, 1 meetstation / regelstation en 1 (of meer) kiosk-viewer(s).

Scheid dit dan ook gewoon in de hardware en laat je meetstation meten en metingen wegschrijven naar een txt-file. En laat je kiosk-viewer het displayen via JS, dan kan je er ook meerdere viewers aanhangen.

Waarom ik zou kiezen voor een js-oplossing is vrij simpel : Je kan met de data spelen en de display past zich wel aan, waar je dat met GD-lib allemaal van te voren moet definiëren / opslaan / uitrekenen.
Wil je vandaag zien dan verander je je data-selectie in JS en je display volgt, wil gister zien hetzelfde, wil je het afgelopen uur zien, hetzelfde, wil je 5 minuten terug kijken idem. Dit is allemaal standaard functionaliteit in JS-frameworks (omdat die voornamelijk met data-punten werken en niet met vaste plaatjes) terwijl wat ik net noem al in GD-lib betekent x plaatjes genereren.

Je kan uiteraard ook voor een combo gaan als je externe pagina echt images wenst, dan kan je met een js-library als d3 oid daarnaast luxere grafieken tonen op basis van andere dingen.

[naam]

Gomez12 schreef op dinsdag 01 december 2015 @ 01:59:
[...]

Deze wil ik toch wel even uitzonderen, want deze kan ik wel van toegevoegde waarde vinden mits je een strikte code-richtlijn hanteert (welke is niet zo relevant).

Ik vind het namelijk wel makkelijk om snel mijn error-messages te kunnen vinden zodat ik snel wat algemene condities naderhand af kan gaan om te kijken of ik wel alles gepakt heb. En dat gaat niet zo makkelijk met zoeken op random echo-messages. Dus iets in de trant van :

PHP:

// Error-condition : File could not be opened

En in "reguliere" programmeertalen heb ik het niet nodig, want die ondersteunen wel try-catches wat voor mij hetzelfde doel dient, alleen php kent intern weer niet standaard exceptions

Dus met een beetje meer structuur zou ik deze nog wel verdedigbaar vinden.

Php kent gewoon try catch hoor

[Pizza_Boom]

Gomez12 schreef op dinsdag 01 december 2015 @ 02:12:
Eigenlijk maar 1 vraag : Waarom? Waarom niet gewoon scheiden?

GD-lib is redelijk zwaar, maar dat is browser/JS ook. Grafisch iets doen op web is gewoon "zwaar".
Ga je dat op 1 RPI doen dan heb je kans dat je gewoon cycles gaat missen.

Imho heb je gewoon 2 perfect gescheiden dingen, 1 meetstation / regelstation en 1 (of meer) kiosk-viewer(s).

Scheid dit dan ook gewoon in de hardware en laat je meetstation meten en metingen wegschrijven naar een txt-file. En laat je kiosk-viewer het displayen via JS, dan kan je er ook meerdere viewers aanhangen.

Omdat het hele zooitje ook zonder netwerkverbinding moet kunnen werken. De meeste gemeten data is bovendien helemaal niet boeiend. Daarbij zijn meerdere viewers helemaal niet interessant, want alleen op bepaalde momenten wil ik een meting daadwerkelijk weten. De rest van de tijd vinden wij de metingen niet belangrijk en zullen daar ook geen aandacht aan besteden (aard van het systeem).

Waarom ik zou kiezen voor een js-oplossing is vrij simpel : Je kan met de data spelen en de display past zich wel aan, waar je dat met GD-lib allemaal van te voren moet definiëren / opslaan / uitrekenen.
Wil je vandaag zien dan verander je je data-selectie in JS en je display volgt, wil gister zien hetzelfde, wil je het afgelopen uur zien, hetzelfde, wil je 5 minuten terug kijken idem. Dit is allemaal standaard functionaliteit in JS-frameworks (omdat die voornamelijk met data-punten werken en niet met vaste plaatjes) terwijl wat ik net noem al in GD-lib betekent x plaatjes genereren.

Dit is eigenlijk het eerste waarvan ik: daar zou meerwaarde kunnen zitten in het gebruik van javascript boven GD: als je meting onverhoopt langer duurt, dat je de schaal van je grafiek eenvoudig kan aanpassen. Maar javascript genereert geen echte afbeeldingen, toch? Dat is dan weer heel erg jammer, want die zijn wel gewenst (lees: het is een harde eis).

[Gomez12]

naam schreef op dinsdag 01 december 2015 @ 07:46:
[...]


Php kent gewoon try catch hoor

PHP kent het op zijn eigen "PHPese" manier.

As in : Ja, het is er later een beetje ingehacked. Waardoor het kan werken voor je eigen code.
Alleen by default ondersteunen de basisfuncties het niet, dit valt wel weer aan te zetten maar werkt dit dan voor elke extensie 100% of zoals gewoonlijk slechts voor het merendeel van de extensies en mag je zelf de uitzonderingen ondervinden?

Pizza_Boom schreef op dinsdag 01 december 2015 @ 09:30:
[...]
Dit is eigenlijk het eerste waarvan ik: daar zou meerwaarde kunnen zitten in het gebruik van javascript boven GD: als je meting onverhoopt langer duurt, dat je de schaal van je grafiek eenvoudig kan aanpassen. Maar javascript genereert geen echte afbeeldingen, toch? Dat is dan weer heel erg jammer, want die zijn wel gewenst (lees: het is een harde eis).

Je kan met een heleboel "geklooi" / omwegen wel een plaatje met js genereren (zie bijv : http://d3export.housegordon.org) maar in principe en zeker op een low powered device zou ik het idd afraden en als onmogelijk bestempelen.

[Pizza_Boom]

Dus is GD waarschijnlijk nog steeds de (voor mij) makkelijkste oplossing?

[EricBruggema]

Nee GD is waarschijnlijk de meeste logge oplossing. Heb onlangs met een RPi & GD een motion detect script geschreven, kon niet meer dan 2 beelden per seconde scannen. RPI heeft daarvoor A. te weinig geheugen en B. te weinig CPU kracht..

Ik raad je echt aan om iets met JS te gaan doen!!

[Martindo]

Bij mijn vorige werkgever heb ik eerder gebruik gemaakt van c3.js. Dit is een abstractielaag over d3.js waarmee je gemakkelijk grafiekjes kunt maken.

Ik zou het afraden om afbeeldingen te genereren, het is zwaarder om via GD een afbeelding te genereren dan dat je een JSON blobje naar de client stuurt waar JavaScript wat mee doet en dat vervolgens toont aan de gebruiker.

[ Voor 17% gewijzigd door Martindo op 01-12-2015 10:52 ]

[RobIII]

xleeuwx schreef op maandag 30 november 2015 @ 23:36:
https://github.com/xleeuwx/php_graph

RobIII schreef op dinsdag 01 december 2015 @ 00:11:
Los daarvan: als je nu besluit over een paar dagen/weken/jaren deze github repo (of je hele account) op te doeken is het topic niet meer bruikbaar

Little did I know dat het binnen <24 uur al zover zou zijn...

[ Voor 18% gewijzigd door RobIII op 01-12-2015 12:53 ]

[Spinal]

Pizza_Boom schreef op dinsdag 01 december 2015 @ 09:30:
Maar javascript genereert geen echte afbeeldingen, toch? Dat is dan weer heel erg jammer, want die zijn wel gewenst (lees: het is een harde eis).

Wat bedoel je met "echte afbeelding"? Als je met canvas een plaatje maakt dan kun je die opslaan als PNG bijvoorbeeld. Is dat echt genoeg?

[xleeuwx]

Pizza_Boom schreef op dinsdag 01 december 2015 @ 10:34:
Dus is GD waarschijnlijk nog steeds de (voor mij) makkelijkste oplossing?

Makkelijkste misschien omdat je hier al een voorbeeld van hebt. Verder zou ik toch aanbevelen om JavaScript te gebruiken voor de frontend, hier bestaan namelijk al allemaal lib's voor zoals ChartJS.

Daarnaast wordt de Javascript (frontend) uitgevoerd op de client wat tegoeden komt van je CPU / Mem van je PI (tenzij je dit ook de client is).

Tevens is het verboden afgeraden om een kant en klaar voorbeeld te laten zien, dus dit zal ik dan ook in het vervolg ook zeker laten

[Pizza_Boom]

Spinal schreef op dinsdag 01 december 2015 @ 13:09:
[...]

Wat bedoel je met "echte afbeelding"? Als je met canvas een plaatje maakt dan kun je die opslaan als PNG bijvoorbeeld. Is dat echt genoeg?

Dat zou kunnen werken, maar ik heb PHP en GD al draaien en daar wil ik graag mee door. Voordeel van javascript op een RPi systeem dat zowel host als client is, is imho niet te vinden. Nadelen voor mij des te meer.

Zonder arrogant of ondankbaar te zijn: Ondertussen is er 14x gereageerd en niet 1x is er een antwoord gegeven dat überhaupt over PHP gaat en waar ik iets mee kan zonder een compleet nieuwe taal aan te leren. Alles gaat over javascript. Ik waardeer dat men wil helpen, maar hiermee ben ik niet geholpen. Ik heb al een grafiek, daarmee kan ik wat ik moet doen, ik wil alleen de data op een bepaalde manier inlezen. Niet de hele grafiek opnieuw bouwen en daarmee terug naar de start.

Daarnaast heb ik volgens mij al een aantal keer gemotiveerd waarom JS voor mij geen optie is: Geen kennis, geen aparte cliënt dus geen performancewinst op de RPi, harde eis wat betreft plaatjes.

[Gomez12]

Wat is de exacte eis van plaatjes genereren?

Want als het om plaatjes in bijv een periodieke rapportage gaat (dus echt hard een moment in de tijd vastzetten) die via word / pdf gemaakt moet worden dan zou ik idd voor gd gaan.
Maar gaat het om plaatjes die moeten kunnen veranderen naar gelang de tijd dan zou ik voor js gaan en gewoon eens kijken wat de exacte wens voor plaatjes inhoud, wensen ze daar echte keiharde plaatjes of is het voor het gemak maar zo genoemd?

---

Ok, qua originele vraag dan : Maak een model aan in php (dit kan ook best enkel een array zijn) en lees daarin de data uit het bestand, dan kan je met die array alle trucjes doen die je wilt.

Waar je momenteel de fout lijkt in te gaan is dat je een while <total samples wilt doen terwijl je nog helemaal geen idee hebt hoeveel samples er zijn, want die ga je daarna pas inlezen.
Oftewel eerst alle samples inlezen in geheugen / array / weet ik veel wat en dan kan je je loopjes etc op je geheugen laten lopen.

[HuHu]

Ik heb niet alles gelezen, maar, is deze functie wellicht nuttig voor je: http://php.net/fgetcsv ?

Als je je data opslaat in een CSV formaat (komma-gescheiden waarden), dan kun je die hiermee inlezen. Meerdere kolommen worden automatisch omgezet in een array.

Het example op die pagina geeft al voldoende informatie: open een bestand met fopen(), loop er doorheen met fgetcsv (in jouw geval "total samples" keer of totdat fgetcsv() === FALSE) en sluit het weer netjes af met fclose().

[Pizza_Boom]

Iedere voor ons interessante periode moet worden geregistreerd en dat wordt uiteindelijk zowel PDF/Word/Excel en hardcopy opgeslagen. De in een lijngrafiek gezette meetgegevens zijn zo'n beetje het hoofddoel van de gehele machineontwikkeling.

Uiteindelijk zullen de plaatjes bij voorkeur moeten kunnen veranderen tijdens de interessante periode. Dat is echter een wens, geen harde eis. Op dit moment wordt de uiteindelijke grafiek ook pas gemaakt als daartoe commando wordt gegeven.

Ik heb even voor mijzelf e.e.a. op een rijtje gezet m.b.t. je laatste vraag, in feite wil ik 3 dingen doen met de gemeten waardes:
- De huidige meetwaarde live weergeven (harde eis)
- De meetwaardes opslaan in een voor mensen leesbaar document (wens)
- Een grafiek met de gegevens van de laatste voor ons interessante periode (harde eis)

Omdat de grafiek natuurlijk maar een beperkt aantal punten zou kunnen weergeven, had ik net bedacht dat het wellicht handig is om eerst de laatste regel uit te lezen (ik begrijp dat PHP die mogelijkheid biedt) als je in je bestand ook een indexer zet, zodat je weet hoeveel data je in je array gaat stoppen, maar ook hoe groot je filter op de data moet zijn (bijv. 1 op 4) om daarna alles uit te lezen.

De live data hoeft niet zo moeilijk te zijn, dat is telkens end of line uitlezen. De voor mensen begrijpelijke data is een kwestie van eerst een vertaalslag maken voordat je het op gaat slaan.

Voor de grafiek dacht ik aan zoiets:

PHP:

$file = "file.txt";
$functie = fopen($file, "r");

while (!feof($functie)){
echo fgets($functie);
#schrijf hier uitgelezen waarde naar array 
}
$close($functie);

[xleeuwx]

Als eerste zou ik dan beginnen om de data in een array te zetten inplaats van het direct te echo
http://php.net/manual/en/function.var-dump.php

PHP:

$file = "file.txt";
$data = array(); // of $data = [];
$functie = fopen($file, "r");

while (!feof($functie)){
// Data wegschrijven naar een array 
$data[] = fgets($functie);

}
$close($functie);

// Data op het scherm laten zien:
var_dump($data);

En om het laatste element te laten zien gebruik je de end functie:
http://php.net/manual/en/function.end.php

PHP:

// Laatste element laten zien:
$element = end($data);
echo $element;

Belangrijkste is om even te begrijpen wat een array is:
http://php.net/manual/en/language.types.array.php

[ Voor 31% gewijzigd door xleeuwx op 01-12-2015 14:29 ]

[Pizza_Boom]

Thanks!
Ik dacht dat ik altijd alles moest echoën om het op te halen, vandaar dat ik dat wilde doen. Maar ik begrijp dus dat je daarmee eigenlijk gewoon direct je data print op je scherm, wat jij doet met var_dump.

Voor het vinden van de laatste regel had ik juist deze gevonden: http://php.net/manual/en/function.feof.php

Ik ga er weer eens mee stoeien.

[xleeuwx]

Pizza_Boom schreef op dinsdag 01 december 2015 @ 14:55:
Thanks!
Ik dacht dat ik altijd alles moest echoën om het op te halen, vandaar dat ik dat wilde doen. Maar ik begrijp dus dat je daarmee eigenlijk gewoon direct je data print op je scherm, wat jij doet met var_dump.

Voor het vinden van de laatste regel had ik juist deze gevonden: http://php.net/manual/en/function.feof.php

Ik ga er weer eens mee stoeien.

Dat kan zeker ook, echter je gebruikt niet je array die je dan zojuist hebt aangemaakt.

Overigens zou dit dan ook kunnen.

PHP:

$variable = null;

while(conditie) {
 $variable = $value;
}

echo $variable;

Dan overschrijf je elke keer de variabel $variable, en deze heeft op het laatste dan de laatste waarde.

[NMe]

Gomez12 schreef op dinsdag 01 december 2015 @ 10:31:
[...]

PHP kent het op zijn eigen "PHPese" manier.

As in : Ja, het is er later een beetje ingehacked. Waardoor het kan werken voor je eigen code.
Alleen by default ondersteunen de basisfuncties het niet, dit valt wel weer aan te zetten maar werkt dit dan voor elke extensie 100% of zoals gewoonlijk slechts voor het merendeel van de extensies en mag je zelf de uitzonderingen ondervinden?

offtopic:
Om dit iets te verduidelijken: try/catch heeft alleen effect op exceptions, niet op errors. Doe je dus iets dat een fatal error veroorzaakt in PHP, dan heb je geen bal aan je try/catch, je programma klapt er gewoon uit. Daar zijn per situatie overigens wel oplossingen voor.

[Spinal]

Pizza_Boom schreef op dinsdag 01 december 2015 @ 13:39:
[...]
Zonder arrogant of ondankbaar te zijn: Ondertussen is er 14x gereageerd en niet 1x is er een antwoord gegeven dat überhaupt over PHP gaat en waar ik iets mee kan zonder een compleet nieuwe taal aan te leren. Alles gaat over javascript. Ik waardeer dat men wil helpen, maar hiermee ben ik niet geholpen. Ik heb al een grafiek, daarmee kan ik wat ik moet doen, ik wil alleen de data op een bepaalde manier inlezen. Niet de hele grafiek opnieuw bouwen en daarmee terug naar de start.

Als het maken van de grafiek niet het probleem is, waarom begin je dan überhaupt over GD? Als het je puur gaat om het inlezen van bestanden, dan is het hele GD-verhaal toch niet relevant?

NMe schreef op dinsdag 01 december 2015 @ 15:01:
[...]

offtopic:
Om dit iets te verduidelijken: try/catch heeft alleen effect op exceptions, niet op errors. Doe je dus iets dat een fatal error veroorzaakt in PHP, dan heb je geen bal aan je try/catch, je programma klapt er gewoon uit. Daar zijn per situatie overigens wel oplossingen voor.

Nog even geduld :)

[Pizza_Boom]

Spinal schreef op dinsdag 01 december 2015 @ 15:27:
[...]

Als het maken van de grafiek niet het probleem is, waarom begin je dan überhaupt over GD? Als het je puur gaat om het inlezen van bestanden, dan is het hele GD-verhaal toch niet relevant?

Omdat ik zo volledig mogelijk wil zijn. Ik wil bestanden inlezen die ik gebruik in mijn GD grafiek. Ik weet niet of het van, al dan niet significant, belang kan zijn.

[xleeuwx]

Pizza_Boom schreef op dinsdag 01 december 2015 @ 15:43:
[...]
Omdat ik zo volledig mogelijk wil zijn. Ik wil bestanden inlezen die ik gebruik in mijn GD grafiek. Ik weet niet of het van, al dan niet significant, belang kan zijn.

Waar loop je nu dan nog op vast en wat heb je nog nodig ?

zover ik nu weet kan je bestand uitlezen en deze tonen op het scherm.

vervolgens moet je alleen nog een plaatje maken met GD ?

[Pizza_Boom]

xleeuwx schreef op dinsdag 01 december 2015 @ 16:43:
[...]


Waar loop je nu dan nog op vast en wat heb je nog nodig ?

zover ik nu weet kan je bestand uitlezen en deze tonen op het scherm.

vervolgens moet je alleen nog een plaatje maken met GD ?

Dat is correct. Na wat typotjes eruit gehaald te hebben (een S vervangen door $ ) krijg ik inderdaad een mooie berg data. Eigenlijk zou ik die nog even mooi moeten kunnen sorteren, nu gooit ie alles achter elkaar.
Nu nog even proberen die data daadwerkelijk in de grafiek te krijgen. Hij vindt hem nog niet lief en levert constant errors als ik de grafiek open. Expects paramater to be long, array given

[xleeuwx]

Pizza_Boom schreef op dinsdag 01 december 2015 @ 17:06:
[...]
Dat is correct. Na wat typotjes eruit gehaald te hebben (een S vervangen door $ ) krijg ik inderdaad een mooie berg data. Eigenlijk zou ik die nog even mooi moeten kunnen sorteren, nu gooit ie alles achter elkaar.
Nu nog even proberen die data daadwerkelijk in de grafiek te krijgen. Hij vindt hem nog niet lief en levert constant errors als ik de grafiek open. Expects paramater to be long, array given

De laatste fout is omdat je direct de array wilt gebruiken in een functie die een int / string verwacht (php is niet zo nauwkeurig maar direct een array er in stoppen gaat te ver )

Kan je de code hiervan laten zien ?

[ Voor 3% gewijzigd door xleeuwx op 01-12-2015 17:17 ]

[Pizza_Boom]

xleeuwx schreef op dinsdag 01 december 2015 @ 17:17:
[...]


De laatste fout is omdat je direct de array wilt gebruiken in een functie die een int / string verwacht (php is niet zo nauwkeurig maar direct een array er in stoppen gaat te ver )

Kan je de code hiervan laten zien ?

Eerst vul ik het array vanuit het txt file op deze manier:

PHP:

$file = "test.txt";
$data = array();
$functie = fopen($file,  "r");

while (!feof($functie))
{
$data[] = fgets($functie);
}
fclose($functie);

Vervolgens kom ik in een for loopje dat met een hulpinteger nu 150x loopt.

PHP:

for($i = 0; $i <= 150; $i++)
{
$xPoint = $xPoint+$xinterval;
$y2Point = $data;
imageline( $Image, $xPoint, $y1Point, $xPoint, $xPoint + $interval, $y2Point, $colRed );
}

Ik heb verschillende vormen geprobeerd. Ik heb ook $y2Point = $data[] e.d. geprobeerd, maar dat vond ie allemaal niet leuk en dat leidde dus tot errors. Dit draait ie relatief gezien zonder errors.

edit:
Laat ik dan ook meteen maar proberen uit te vogelen hoe je meerdere bytes bruikbaar uit een array haalt. Ik ga namelijk ook meerdere sensoren uitlezen en die wil ik eigenlijk in 1 en hetzelfde grafiekje verwerken.

Uit C ben ik gewend dat je voor iedere hulpvariabele aan geeft wat voor type het is, maar dat hoef je in PHP weer niet te doen, geloof ik. Verder ben ik uit C gewend dat je een bepaalde hulpvariabele kunt invullen vanuit een matrix door "HulpVariabele1 = array[xy];" te doen, waarbij je voor xy iedere positie kan invullen die je wilt. Uiteraard heb ik dat ook geprobeerd, maar ook dat vond ie niet zo leuk. En als je hem in een forloopje gooit, in geval van C, dan kan je die i functie ook gebruiken in je matrix. Dat deed ik voor I2C strings die ik binnen kreeg op m'n pic16F1459

[ Voor 6% gewijzigd door Pizza_Boom op 02-12-2015 00:56 ]

[HuHu]

Euh... $data[$i] op regel 4?

Misschien is het handig als je eerste een online programmeercursus en/of tutorial over PHP volgt. Wat dit zijn wel een beetje basis-dingen. Bijvoorbeeld: http://www.w3schools.com/php/ , waar je ook uitleg vindt over array's (bij jou is dat $data): http://www.w3schools.com/php/php_arrays.asp

[ Voor 84% gewijzigd door HuHu op 02-12-2015 08:29 ]

[Pizza_Boom]

HuHu schreef op woensdag 02 december 2015 @ 08:27:
Euh... $data[$i] op regel 4?

In het testprogramma doet dat het perfect. Kan ik hem keurig uitlezen, ook met een nummertje, maar hier? Haal ik regel 5 naar de comments, dan krijg ik, mits ik mijn forloopje net zo lang maak als het aantal bytes data die ik heb uitgelezen, dan krijg ik de melding dat ie geen afbeelding kan maken. Fair enough, ik heb immers een line weggehaald. Doe ik er meer, dan heeft ie ongeldige data. Kan ook kloppen, de file is immers verder leeg.

Gooi ik die regel 5 wel erin, dan ontstaat de volgende melding: A non well formed numeric value encountered in. Zoekactie daarop in google levert mij allemaal paginas op met problemen met een tijdsvariabele, eigenlijk iets waar ik niets mee te maken heb. Ik dacht nog, print ie toevallig een string mee, maar een printf("%d<BR>", $y2Point) regel levert mij alleen een rijtje met getallen op, zonder andere data erbij.

[Pizza_Boom]

Even een update. Ik ben er, uiteindelijk, met wat hulp uitgekomen. Waarschijnlijk ging er iets fout in de conversie van I2C naar txt data. Bij het geforceerd lezen als numerieke data van $data[] kreeg ik de melding dat er geen afbeelding kon worden getoond i.v.m. fouten. Een stukje script dat de data leest en alle niet numerieke tekens eruit haalt en alle niet numeriek gevulde plaatsen voor het einde van het array vult met 0 zorgde uiteindelijk voor een werkend grafiekje.