programmeervraagje Datums

[hugo stoutjesdijk]

Maar als de startdatum gewoon vast in een parameter staat, weet je in principe hoe lang dat geleden is.
En met die rekentruc kun je ook niet vastleggen dat het b.v. een half jaar stil heeft gestaan.
Kun je dan niet beter een dagen tellertje er in zetten, elke keer als er de datum anders is als de opgeslagen datum, 1 erbij en huidige datum op slaan.
Dan heb je 2 gegevens, datum inbedrijfstelling en aantal dagen gedraaid.

[Erik]

Kun je de schrikkeljaren niet in een if/else gieten?

if(year == 2024 or year == 2028 or year == 2032){
februaridays = 29;
}
else{
februaridays = 28;
}
Zoiets... Denk niet dat die PLC het jaar 2100 gaat halen.

Net ff van Google; jaartal is deelbaar door 4 maar niet deelbaar door 100. Kun je ook iets mee.

[pgroot]

Maar als de startdatum gewoon vast in een parameter staat, weet je in principe hoe lang dat geleden is.
En met die rekentruc kun je ook niet vastleggen dat het b.v. een half jaar stil heeft gestaan.
Kun je dan niet beter een dagen tellertje er in zetten, elke keer als er de datum anders is als de opgeslagen datum, 1 erbij en huidige datum op slaan.
Dan heb je 2 gegevens, datum inbedrijfstelling en aantal dagen gedraaid.

zeker als de installatie regelmatig stil/uit staat geeft de berekende dagenteller geen goed beeld meer van de situatie.
niet voor niets zeggen ze bv in je auto distributie vervangen om de x-kilometer of 5 jaar (whatever comes first)

Ofwel 2 datums met elkaar vergelijken of een urenteller is denk ik betrouwbaarder dan het berekenen van de waarde.
Wel even rekening mee houden wat voor waarde je wilt hebben, dagen sinds installatie of gedraaide dagen sinds installatie.
In geval van het laatste zul je zoals door Hugo omschreven aan de hand van de laatste bekende draaidatum moeten optellen. die opgeslagen datum schrijf je gewoon weg nadat je de datum vergeleken hebt dan is deze altijd actueel.

het nadeel van het vergelijken van dagen is als de installatie beperkt per dag draait er wel een scheef beeld ontstaat. in dat geval zou ik persoonlijk kiezen voor het tellen van uren

[Swets]

Maar als de startdatum gewoon vast in een parameter staat, weet je in principe hoe lang dat geleden is.
En met die rekentruc kun je ook niet vastleggen dat het b.v. een half jaar stil heeft gestaan.
Kun je dan niet beter een dagen tellertje er in zetten, elke keer als er de datum anders is als de opgeslagen datum, 1 erbij en huidige datum op slaan.
Dan heb je 2 gegevens, datum inbedrijfstelling en aantal dagen gedraaid.

zal je wel niet begrijpen, want hoe weet ik dat dan?

Kun je de schrikkeljaren niet in een if/else gieten?

if(year == 2024 or year == 2028 or year == 2032){
februaridays = 29;
}
else{
februaridays = 28;
}
Zoiets... Denk niet dat die PLC het jaar 2100 gaat halen.

Net ff van Google; jaartal is deelbaar door 4 maar niet deelbaar door 100. Kun je ook iets mee.

ja dat delen door 4 wist ik.... maar meer hoe ik dat het makkelijkste toe gaat passen.... wat dan moet ik dus gaan kijken naar het jaar, en als je nu de begine en de eind datum 9 jaar uit elkaar zit.... dan is het natuurlijk een gedoe.... en nogmaals ... eerst worden natuurlijk de jaren van elkaar afgetrokken, en maal 365.25 gedaan.... dus daar zit die .25 als in.... en het gekke is dus, als ik mijn verhaaltje met de web pagina vergelijkt, krijg ik steeds hetzelfde antwoord.... dus of ze doen het op die pagina ook niet goed.... of we hebben het beide goed... :-)

Maar als de startdatum gewoon vast in een parameter staat, weet je in principe hoe lang dat geleden is.
En met die rekentruc kun je ook niet vastleggen dat het b.v. een half jaar stil heeft gestaan.
Kun je dan niet beter een dagen tellertje er in zetten, elke keer als er de datum anders is als de opgeslagen datum, 1 erbij en huidige datum op slaan.
Dan heb je 2 gegevens, datum inbedrijfstelling en aantal dagen gedraaid.

zeker als de installatie regelmatig stil/uit staat geeft de berekende dagenteller geen goed beeld meer van de situatie.
niet voor niets zeggen ze bv in je auto distributie vervangen om de x-kilometer of 5 jaar (whatever comes first)

Ofwel 2 datums met elkaar vergelijken of een urenteller is denk ik betrouwbaarder dan het berekenen van de waarde.
Wel even rekening mee houden wat voor waarde je wilt hebben, dagen sinds installatie of gedraaide dagen sinds installatie.
In geval van het laatste zul je zoals door Hugo omschreven aan de hand van de laatste bekende draaidatum moeten optellen. die opgeslagen datum schrijf je gewoon weg nadat je de datum vergeleken hebt dan is deze altijd actueel.

het nadeel van het vergelijken van dagen is als de installatie beperkt per dag draait er wel een scheef beeld ontstaat. in dat geval zou ik persoonlijk kiezen voor het tellen van uren

ja de installatie gaat regelmatig uit.... dus elke dag tellen in een variable gaat ook niet, want als hij een maand uitgestaan heb, hoe weet ik dat? dan moet ik toch ook naar de clock-chip kijken... dus ja dan kan ik beter gelijk maar iets maken op de clockchip?


maar ik ga morgen nog eens goed testen.... maar ik geloof wat ik nu heb, dat dat werkt.....
maar dat is wel tegenwoordig, er komen steeds meer toeters en bellen bij.... trending, password met verschillen level en operators... heb er al een aantal installties bij, ook met password voor verschillende operators, maar ook ergens op de achtergrond word gelijk bij gehouden hoeveel de verschillende operators doen... :-)

vroeger hadden we instalttie, met 6 prestotaten, waar iedereen aan kon draaien, en het systeem werkte altijd....

nu doe we het zelfde met 1 analog input, met 6 setpoints..... en nu zit dat helemaal dicht getimmed... password,operators, waardens begrenzen... verschillende setpoint tov elkaar begrenzen.... enz enz...

ik vind het allemaal best... vind het zelfs leuk het te maken.... maar of het nu echt de weg is?

gelukkig kunnen we tegenwoordig veel via internet.... anders zat ik het hele jaar in het buitenland... :-)

[pgroot]

maar dat is wel tegenwoordig, er komen steeds meer toeters en bellen bij.... trending, password met verschillen level en operators... heb er al een aantal installties bij, ook met password voor verschillende operators, maar ook ergens op de achtergrond word gelijk bij gehouden hoeveel de verschillende operators doen... :-)

vroeger hadden we instalttie, met 6 prestotaten, waar iedereen aan kon draaien, en het systeem werkte altijd....

nu doe we het zelfde met 1 analog input, met 6 setpoints..... en nu zit dat helemaal dicht getimmed... password,operators, waardens begrenzen... verschillende setpoint tov elkaar begrenzen.... enz enz...

ik vind het allemaal best... vind het zelfs leuk het te maken.... maar of het nu echt de weg is?

op zich niks tegen het bijhouden van data, alleen is het toch altijd de discussie wat je er uit op kunt maken. in mijn ervaring begint het al met weten wat je leest en wat voor factoren er nog meer meegespeeld hebben. uit data blijkt bv dat de operator/machine een rendement heeft van 60% per uur, maar wellicht heeft die operator in de tijd dat hij staat te wachten ook een samen met een andere operator een 2e en 3e machine bediend. hoe reeel is die 60% dan nog. maar vooral dat laatste is een scenario wat niet eenvoudig is om te loggen.

maar even terug on topic, in jouw geval lijkt het tellen van bedrijfsuren meer zinvol als het aantal dagen. eventueel zou je die counter ook kunnen gebruiken om bv een onderhoudsinterval en inspectieinterval aan te geven etc.

[Swets]

maar dat is wel tegenwoordig, er komen steeds meer toeters en bellen bij.... trending, password met verschillen level en operators... heb er al een aantal installties bij, ook met password voor verschillende operators, maar ook ergens op de achtergrond word gelijk bij gehouden hoeveel de verschillende operators doen... :-)

vroeger hadden we instalttie, met 6 prestotaten, waar iedereen aan kon draaien, en het systeem werkte altijd....

nu doe we het zelfde met 1 analog input, met 6 setpoints..... en nu zit dat helemaal dicht getimmed... password,operators, waardens begrenzen... verschillende setpoint tov elkaar begrenzen.... enz enz...

ik vind het allemaal best... vind het zelfs leuk het te maken.... maar of het nu echt de weg is?

op zich niks tegen het bijhouden van data, alleen is het toch altijd de discussie wat je er uit op kunt maken. in mijn ervaring begint het al met weten wat je leest en wat voor factoren er nog meer meegespeeld hebben. uit data blijkt bv dat de operator/machine een rendement heeft van 60% per uur, maar wellicht heeft die operator in de tijd dat hij staat te wachten ook een samen met een andere operator een 2e en 3e machine bediend. hoe reeel is die 60% dan nog. maar vooral dat laatste is een scenario wat niet eenvoudig is om te loggen.

maar even terug on topic, in jouw geval lijkt het tellen van bedrijfsuren meer zinvol als het aantal dagen. eventueel zou je die counter ook kunnen gebruiken om bv een onderhoudsinterval en inspectieinterval aan te geven etc.

Daar is het ook voor... mijn klant wil dat het systeem zoveel dagen na het inbedrijfnamen bepaalde meldingen op het hmi scherm hebben....
Dus vandaar dat ik nu eerst een soort van functie blok aan het maken, waar dus het aantal dagen dat het systeem draait bijhoud..

[hugo stoutjesdijk]

Die 365.25 kan hooguit 1 dag fout zitten, en dat maakt toch niemand wat uit lijkt me.
Als je van 1-1-2020 tot 1-1-2021 doet komt er waarschijnlijk 365 uit omdat 365.25 naar beneden afgerond wordt.
1-1-2021 tot 1-1-2024 is 3x365.25 dus komt er 1095.75 geeft correct afgerond 1096 dagen, dat is 1 dag teveel.
Als het echt op de dag nauwkeurig moet, zou ik met 365 rekenen, en daarnaast kijken hoeveel schrikkeldagen er nog in zitten.

Maar je moet die managers die al die dingen willen weten ook vragen of ze nu eigenlijk een urenteller of het aantal verstreken dagen sinds in bedrijfstelling willen weten. Dat laatste zou ik wel erg dom vinden, ik zie de discussie al voor me tijdens een management vergadering: Hoe lang hebben we die installatie? geen idee, moeten we de operator in de plc laten kijken. Die heeft geen zin en is iets slimmer en antwoord: volgende week precies 9 jaar want ik weet nog dat m'n zoontje toen geboren is, of tewel mijn boekhouder weet altijd precies hoe oud alle investeringsgoederen zijn maar niet hoeveel uur ze gedraaid hebben.

Daar gaat het natuurlijk niet om, jij bent weer met een uitdagend puzzeltje bezig.
Heeft een plc niet al standaard een soort van ingebouwde urenteller?

[Swets]

Die 365.25 kan hooguit 1 dag fout zitten, en dat maakt toch niemand wat uit lijkt me.
Als je van 1-1-2020 tot 1-1-2021 doet komt er waarschijnlijk 365 uit omdat 365.25 naar beneden afgerond wordt.
1-1-2021 tot 1-1-2024 is 3x365.25 dus komt er 1095.75 geeft correct afgerond 1096 dagen, dat is 1 dag teveel.
Als het echt op de dag nauwkeurig moet, zou ik met 365 rekenen, en daarnaast kijken hoeveel schrikkeldagen er nog in zitten.

Maar je moet die managers die al die dingen willen weten ook vragen of ze nu eigenlijk een urenteller of het aantal verstreken dagen sinds in bedrijfstelling willen weten. Dat laatste zou ik wel erg dom vinden, ik zie de discussie al voor me tijdens een management vergadering: Hoe lang hebben we die installatie? geen idee, moeten we de operator in de plc laten kijken. Die heeft geen zin en is iets slimmer en antwoord: volgende week precies 9 jaar want ik weet nog dat m'n zoontje toen geboren is, of tewel mijn boekhouder weet altijd precies hoe oud alle investeringsgoederen zijn maar niet hoeveel uur ze gedraaid hebben.

Daar gaat het natuurlijk niet om, jij bent weer met een uitdagend puzzeltje bezig.
Heeft een plc niet al standaard een soort van ingebouwde urenteller?

Ja had ik me ook al bedacht, misschien 1 dag er naast..maar dat vond ik eigenlijk wel best.... maar net wat ik zei, dan zit dat ook zo op de internet pagina... want ik heb heel veel datums geprobeerd, en mij verhaaltje, en de webpagina gaven steeds het zelfde....

en het is best wel lastig.... want je kan natuurlijk wel uitzoeken hoeveel schrikkeljaren er tussen zit ... maar dan moet je ook weer iets gaan maken, kijken of februari er wel tussen valt....

[hugo stoutjesdijk]

Ik zou er niet teveel tijd aan besteden, kans dat iemand door heeft dat je er 1 dag naast zit is nihil. Als ze er al ooit serieus naar kijken.

Degene die de vraag gesteld heeft zit hier ergens aan tafel.


Link