Dynamische berekening in macro's

Schoolvraag?

Daar is een aparte rubriek voor.

Ziet eruit als een wiskundevraag en geen electronicavraag.
Of je moet de formules omzetten in volts, ohms, amperes en dergelijke.

Geen schoolvraag.

Als het hier ongepast is, gooi er maar een slotje op.

Ongepast is het niet maar het is beter als dingen in de juiste rubriek staan.
Moderatoren kunnen dit topic eventueel naar de juiste rubriek verplaatsen.

Een slotje doen de moderatoren als ze het niet goed vinden, of ermee klaar zijn om een of andere reden.

Dus wees gerust.

[Bericht gewijzigd door vergeten op maandag 4 november 2024 23:02:16 (19%)]

Zet je vraag even op een wiskunde of natuurkunde forum inderdaad. Of op helpmij, daar staan allerlei technische vragen op.

Je vraag bevat veel voor jou waarschijnlijk duidelijk jargon of termen, misschien kan je het iets anders uitleggen.

Ik begrijp het zo:

En machine maakt een product doorgaans in 30 seconden, dit is het doel.

Dan is er iets met een ploegendienst en wat gepland onderhoud, respectievelijk 8 uur en bijvoorbeeld een half uur.

Dan wil je tonen: 7,5 uur maal 120 producten = 900 geschatte productie

Alleen als er wat gerommel is met de machine dan zit je misschien een keer op 40 seconden = 90 producten per uur is 675 geschatte productie..

Ik zou zeggen tel je gemaakte producten(cycli) deel het aantal gedraaide minuten door het aantal producten en vermenigvuldig dat met hoeveel minuten je nog hebt.

Tijdgedraaid/producten_gereed = 10 minuten / 20 producten = 0,5 min/product
(werkdag - (tijdgedraaid + geplandonderhoud))
(480 - (10 + 30))= 440 minuten

20 producten al gemaakt
880 producten nog verwacht (440/0,5)
900 totaal verwacht productie.

Is er in de eerste 10 minuten wat gerommel dan zak je misschien wel naar 1 producte per minuut en sta je heel negatief met 450 verwacht op de teller, maar dit zal zich vanzelf aanpassen naarmate de tijd vordert.

Als dit te negatief gaat worden / onrealistisch dan kan je de formule complexer maken door bijvoorbeeld te beginnen met historische/statistische of virtuele 100 minuten / 200 producten = 0,5 min per product toe te voegen. Na 10 'langzame' start minuten heb je dan:

(statistisch_gedraaid+echt_gedraaide tijd)/(statistisch_gereed+producten echt_gereed) = 110/210 = 0,52 min/product

10 al gemaakt
846.2 nog verwacht (440/0,52)
856.2 totaal verwacht productie.

Je kan naar smaak 'afregelen' dus ook met 2010/4010 of 100010/200010, daarbij ga je dus uit van 100.000 minuten gedraait en doorgaans 200.000 producten geproduceerd, als er dan 10 'langzame' minuten zijn dan heeft dat bijna geen effect.

Navigatiesystemen hebben hetzelfde probleem, je moet 100km snelweg met 100km/u rijden.. Ga je dan na 1km file van een uur tonen dat je over 99 uur aankomt of blijf je uit gaan van de normale snelheid of kies je iets ertussen in.

Feitelijk wil je dus in plaats van Geplande stilstand, Draaiuren sinds start ploeg, en Maximale draaiuren een tabel van intervallen met bijbehorende Normtijden.

Mocht dit werkelijk een doorlopend proces zijn, dan zou ik dus de aantallen berkenen bij iedere wijziging in de normtijd. Vervolgens bereken je niet draaiuren, maar resterende tijd, of zelfs de delte sinds laatste wijziging van de normtijd. Zie dat Geplande stilstand hierin platgeslagen kan worden als draaiuren met een normtijd van oneindig (ofwel een productiesnelheid van 0).

Daarnaast, begin met alle tijden in dezelfde eenheid te zetten, dat scheelt je een hoop hoofbrekens.

Ohja, en wat is "macro"? Ik verwachtte C macros, maar daar lijken deze niet op. Dus mijn gok is Excel, maar ik mis teveel context om daar iets over te zeggen.

tijd (min) |   0 | 400 | 450 | 480 | 930 
-----------+-----+-----+-----+-----+-----
prod / min |   2 |   1 |   0 |   2 |  0

T_d0 = T₁ - T₀
V₀ = T_d0 * P₀
V = ΣV_n

Hey, bedankt voor de antwoorden!

Ik moet de reacties van roadrunner84 en K7Jz even goed doorlezen vanavond maar ik zal hier proberen het iets duidelijker uit te leggen:

Een machine draait in een 5-ploegensysteem, elke ploeg maximaal 8 uur.
Op deze machine kan er een geplande stilstand ingegeven worden.

Stilstanden variëren van omstellen, geplande stop, onderhoud enz.
De lengte van stilstand kan dus per dag en per ploeg verschillen. Ook kan het zijn dat er midden in een ploeg ineens een geplande stilstand toegevoegd wordt.

Het kan ook zijn dat er helemaal geen geplande stilstand is, afhankelijk van het product en moet de machine dus gewoon 8 uur draaien.

Nu de technische kant:

De verstreken draai"uren" worden bijgehouden door een LOGO die in de machine zit. Deze heeft op een ingang de automaat status van de machine en zodra deze hoog is, begint de minutenteller te tellen.

Maximaal kun je dus 480 minuten draaien per ploeg, want na 8 uur wordt deze tijd gereset.

De LOGO wordt op zijn beurt uitgelezen door een Weintek HMI waarin een macro draait. Het is dus een Weintek macro.

De Weintek vergelijkt de geplande stilstand met het vaste gegeven 480 minuten.

int Automaat_tijd         //Minutenteller LOGO
int Geplande_Stilstand    //Stilstand in minuten ingegeven in HMI

Getdata(Automaat_tijd...
Getdata(Geplande_Stilstand...

    if Automaat_tijd >= (480 - Geplande_Stilstand) then
       doe iets
    else
       doe iets anders
    end if

Wat ik ook doe in de macro, is het verwachte aantal producten berekenen:

float Normcyclus           //Bijvoorbeeld 30,00 sec
float ProductenPerMinuut   //Aantal producten per minuut 

int VerwachtAantal

ProductenPerMinuut = (60/Normcyclus) = 2 per minuut

VerwachtAantal = (ProductenPerMinuut * 60) * 8 // 120 * 8 = 960 stuks

Als die normcyclus gelijk blijft voor de hele 8 uur, klopt de berekening van verwachte aantallen dus prima.
Maar ik hou geen rekening met geplande stilstand. Dat heb ik zo opgelost:

float Normcyclus           //Bijvoorbeeld 30,00 sec
float ProductenPerMinuut   //Aantal producten per minuut 

int VerwachtAantal
int CorrectieAantal        //Bevat aantal producten in geplande stilstand
int Geplande_Stilstand     //bijvoorbeeld 30 minuten

ProductenPerMinuut = (60/Normcyclus) = 2 per minuut

CorrectieAantal = ProductenPerMinuut * Geplande Stilstand // 2 * 30 = 60 stuks

VerwachtAantal = (ProductenPerMinuut * 60) * 8 - CorrectieAantal // 120 * 8 - 60 = 900 stuks 

Stel, de ploeg is 4,5 uur bezig en je hebt 4 uur in automaat gedraaid. (volgens de normsnelheid)
Het verwachte aantal producten staat nog steeds op 900 en als je zo doorgaat, haal je dat ook.

Nu komt er een wijziging in de normcyclustijd, voor wat voor reden dan ook.
Je moet nu ineens nog 3,5 uur produceren met een normtijd van 40 seconden.

De macro "weet" niet dat we al 4 uur geproduceerd hebben en al 450 producten gemaakt hebben dus die maakt ineens van het verwachte aantal:

VerwachtAantal = (ProductenPerMinuut * 60) * 8 - CorrectieAantal // 90 * 8 - 45 = 675 stuks

Daar klopt dus niks meer van, want ik heb er al 450 gemaakt en in de resterende tijd zou ik er volgens de nieuwe norm nog (1,5 per minuut * 210 minuten resterende tijd) = 315 stuks maken.

450 + 315 = 765 dus kom ik zelfs ruim boven de verwachting uit.

De macro berekent dus over de hele 8 uur.
Net wat K7Jz aangeeft, ik moet i.p.v. met het vaste gegeven 480 minuten, gaan rekenen met de resterende tijd.

Het verwachte aantal is dan dus ReedsGeproduceerd + (AantalPerMinuut * Resterende minuten).

Zit ik alleen nog met de factor geplande stilstand die mee veranderd als je de norm wijzigt, of ik moet de geplande stilstand altijd vanaf start ploeg rekenen. Het maakt immers niet uit wanneer de stilstand komt, het gaat om de aantallen die in de automaat tijd gehaald moeten worden.

Denk ik niet veel te moeilijk?

Eigenlijk zijn dit geen taken voor een Weintek. Normaal zou ik het in de PLC doen. Als het goedkoop moet vervang je die LOGO! voor een Koyo Click, die kan heel behoorlijk rekenen. Dan heb je die Weintek alleen nodig voor weergave, instellingen, teller resets enz. en eventuele uitlezingen op afstand met EasyAcces.

Dank voor je reactie GJ_

Ik moet wel zeggen dat ik de cMT X Advanced HMI heb met quad-core processor.

Er draaien nu meerdere macro's tegelijk en de CPU komt niet boven de 25% uit.
Rapportage per ploeg en per 24 uur worden al netjes gemaild en het ding draait al sinds December vorig jaar, zonder problemen.

De LOGO heb ik enkel in de machine gebouwd om data vast te houden. Cycluspulsen tellen die hardwarematig verbonden zijn, niet via Ethernet. En ook de urentellers en dergelijke zitten allemaal in LOGO.

Als de Weintek dan tijdelijk uitvalt, komen de juiste aantallen gewoon weer zodra het ding weer opstart. (gebeurt eigenlijk nooit)
De data die ik in de macro's gebruik, komen dan ook uit LOGO. Behalve de normtijden, die komen uit een database.

Goedkoop is het zeker niet, maar het is tot nu toe nog wel een testproject. Dus als een Koyo Click "beter" is in dit geval, kan ik daar zeker naar kijken.

Op zich houdt het rekenen na dit onderstaande verhaal ook wel op hoor, veel gekker gaat het niet worden.

Maar ik denk niet dat die Click met databases overweg kan, of wel?

E: Easyacces wordt hier al volop gebruikt, werkt heel mooi.
Vooral op afstand programmeren is geweldig.

Op woensdag 6 november 2024 20:02:53 schreef R-Tronic:
[...]
De verstreken draai"uren" worden bijgehouden door een LOGO die in de machine zit. Deze heeft op een ingang de automaat status van de machine en zodra deze hoog is, begint de minutenteller te tellen.

Maximaal kun je dus 480 minuten draaien per ploeg, want na 8 uur wordt deze tijd gereset.

De LOGO wordt op zijn beurt uitgelezen door een Weintek HMI waarin een macro draait. Het is dus een Weintek macro.
[...]

Het zal wel komen omdat ik niet met PLCs werk (maar met microcontrollers), maar volgensmij heeft je systeem te weinig informatie om het door jou beoogde resultaat te kunnen halen.

Zoals ik je begrijp heb je dus een minuten teller in je systeem, deze wordt gepauzeerd bij een stilstand (bijvoorbeeld door een materiaalwissel). Wat ik je niet hoor zeggen is dat je een constant doorlopende teller hebt en de normtijd hoor ik alleen bij implicatie. Ik ga er dan van uit dat de normtijd na iedere stilstand handmatig wordt ingevoerd in je systeem.

Wat je dus niet hebt is kennis van hoe lang de pauze duurde. En het doel is me ook niet helemaal duidelijk, maar ik denk dat je een indicatie wilt geven op een scherm van hoeveel producten er aan het eind van een ploeg dienst geproduceerd zouden moeten zijn.

Met al deze onduidelijkheden blijft mijn verhaal nog steeds staan: je zult per tijdvak een snelheid (inverse van de normtijd) moeten bepalen, zodat je de som van alle "snelheid * duur" kunt nemen.

Je kunt de pauze tijd wel los behandelen, maar waarom zou je? Het is namelijk identiek aan een procutiesnelheid van 0, met als voordeel dat je niet los de pauze en actief tijd hoeft te gaan uitsleutelen.

Dus. Om weer terug te komen op mijn tabelletje. Je begint dus altijd met een vaste tijd van 8 uur waarvan 30 minuten pauze. Dat is dan

tijd (min) |   0 | 450
-----------+-----+-----
prod / min |   2 |   0

En je berekening wordt dan
VerwachtAantal = (450 - 0) * 2 + (480 - 450) * 0

Wordt er nu na 2 uur een 10 minuten pauze ingelast waarna de snelheid naar 3 producten per minuut gaat, dan verandert je tabel naar

tijd (min) |   0 | 120 | 130 | 450
-----------+-----+-----+-----+-----
prod / min |   2 |   0 |   3 |   0

En je berekent dan
VerwachtAantal = (120 - 0) * 2 + (130 - 120) * 0 + (450 - 130) * 3 + (480 - 450) * 0

Observeer dat er dus telkens de lengte van het tijdvak vermenigvuldigd met de snelheid opgeteld wordt. De formule blijft dus altijd hetzelfde, alleen het aantal rijen in de tabel dat doorlopen moet worden is variabel.

Databases zijn PLC's in het algemeen niet zo sterk in. Maar de data kan wel in hapklare brokken aan je Weintek worden aangeleverd natuurlijk.
Data binnenhalen van je sensoren en de rest van de berekeningen uitvoeren gaat gemakkelijk. In een Click kun je de data ook bij spanningsuitval gewoon vasthouden.
De enige data die van de HMI naar de PLC zou moeten is de normsnelheid.
Voordeel is als die de berekeningen uitvoert het erg eenvoudig te debuggen is omdat je iedere stap van de berekening gewoon real time zichtbaar kunt maken.
Een Click kun je net als de Logo op afstand programmeren via de HMI.

Een goed advies is lastig in dit geval, ik ben erg benieuwd naar het eindresultaat.

@ roadrunner84,

Ik begrijp wat je zegt, ik zit nu alleen even te denken hoe ik dat in de HMI netjes ga oplossen.

Het doel van dit verhaal is om juiste data aan te leveren.
Het complexe hieraan is dat het real-time moet. Ik kan de tijdsvakken die je aangeeft wel loggen en achteraf vanuit de database verder gaan uitrekenen, maar het moet direct zichtbaar zijn wat een verandering doet.

Verwachte aantallen aanleveren is 1, maar dan wordt het lastig.

En hoe hou je rekening met een variabele geplande stilstand, die op elk moment in tijd kan veranderen?

Er moet dus inderdaad een constant doorlopende teller komen die verstreken tijd weergeeft.
I.p.v. rekenen met de "hele" 480 minuten, ga je dan het verwachte aantal berekenen met resterende looptijd.

Dan kun je niet mis toch?

ReedsGeproduceerd + (AantalPerMinuut * Resterende minuten).

ReedsGeproduceerd is het aantal producten wat al gemaakt is. (Shotcounter)

AantalPerMinuut is een variabele die elk moment kan wijzigen, gebaseerd op de normcyclus.

Resterende minuten is 480 - Automaaturen.

Je krijgt dan bijvoorbeeld:


Gegeven: 
Normcyclus = 30,0 seconden
Maximale automaattijd = 480 minuten
Verstreken tijd = 100 minuten
ReedsGeproduceerd = 200 (komt van cyclusteller in LOGO)

VerwachtAantal = ReedsGeproduceerd + (AantalPerMinuut * Resterende minuten).
AantalPerMinuut = 3600 / 30,0 / 60 = 2
ResterendeMinuten = 480 - 100 = 380

VerwachtAantal = 200 + ( 2 * 380) = 960 stuks te produceren.

Die 200 stuks heb je gemaakt in 100 minuten want je draait met 2 stuks per minuut. 

Als je er nu 400 hebt gemaakt, dan zullen er dus 200 minuten verstreken zijn:

VerwachtAantal = 400 + (2 * 280) = 960 stuks. 

Tot zover klopt het dus, want we komen op hetzelfde aantal uit.

Nu verandert bij 400 minuten ineens de norm van 30,0 naar 35,0:

AantalPerMinuut = 3600 / 35,0 = 1,7 producten.
VerwachtAantal = 400 + (1,7 * 280) = 876 stuks

Die 400 stuks liggen dus vast en het resterende mogelijke aantal wordt daar bij opgeteld.

Omdat de verstreken tijd dus met elke minuut minder wordt, zal het dan altijd kloppen, ook al zou je de norm tig keer veranderen.

Om het dan nog wat moeilijker te maken, moet ik nog rekening houden met de geplande stilstand.
Nu is het wel zo dat er natuurlijk een planning is en dat wissels niet ad hoc besloten worden. Ergo, "Geplande Stilstand".

Maar het kan voorkomen dat bij een calamiteit toch ineens gewisseld moet worden.
Normaliter gaan we echter uit van 30 minuten "standaard" stilstand.

In de LOGO zit een extra teller die geïnverteerd is aan de automaatteller.
Die telt dus de tijd dat de machine niet in automaat heeft gestaan.

Dit lijkt misschien overbodig, maar die heeft ergens anders mee te maken.
Dat laat ik om het overzichtelijk te houden hier even achterwege.

De geplande stilstand zal ik dus ook continu moeten vergelijken met de "niet in automaat" tijd.

Hier krijg je dan een x aantal minuten uit die ik kan invoegen in de formule:

ResterendeStilstand = Geplande Stilstand - Gemeten Stilstand. (Mag niet minder dan 0 zijn)

AantalGeplandeStilstand = AantalPerMinuut * ResterendeStilstand //1,7 * 30 = 51 stuks 

AantalPerMinuut = 3600 / 35,0 = 1,7 producten.
VerwachtAantal = 400 + (1,7 * 280) - 51 = 825 stuks

De hele formule zou dus moeten zijn:

VerwachtAantal = ReedsGeproduceerd + (AantalPerMinuut * ResterendeTijd) - AantalGeplandeStilstand

Volgens mij heb ik hem zo, toch?

Ik ga dit sowieso in een macro stoppen om het te testen.
Daarna komt nog een uitdaging: Wat als de geplande stilstand over meerdere ploegen loopt?

Maar 1 ding tegelijk...

Voor diegene die het interesseert:

De formule werkt en de macro berekent nu continu het verwachte aantal producten op basis van meerdere factoren waarvan er veel dynamisch zijn en kunnen veranderen.

Het enige wat ik nog moet doen is hetzelfde voor het geplande aantal producten.
En de formule uitbreiden met verloop over meerdere ploegen.

Bedankt voor de inzichten!