rotary valve reken vraag

[Swets]

Dat denk ik ook. Die knik waar Ruud t over had is wss het punt dat materiaal in de silo niet snel genoeg in de sluis valt. En wat met de hoogte in de silo? Zal ongetwijfeld invloed hebben dus niet teveel waarde hechten aan de getallen. Doseren doe je op een andere manier (is ook niet gezegd dat t daarvoor is)

nee het is niet voor doseren, ze wilde gewoon dat getal in het scherm zien.... en ik zag eigenlijk later dat die rotary valve steeds minder ging doen, naar mate hij sneller draaide....

maar ik vind het ook prima zo....

Kun je echt alleen de rpm opvragen niet bv het aantal pulsen per seconde ofzo?
Nu heb je minder dan 5 bits aan informatie dat is vrij weinig.

iets van een puls op die rotary valve? heeft toch geen zin, ik weet hoe hard hij draait, dat heb ik in me freq.Drive.... tis alleen als hij harder draait, neem hij minder product mee....
waar wil jij dan pulsje aan hangen? en wat bdoel je met 5 bits informatie?

[Kjelt]

iets van een puls op die rotary valve? heeft toch geen zin, ik weet hoe hard hij draait, dat heb ik in me freq.Drive....
tis alleen als hij harder draait, neem hij minder product mee....
waar wil jij dan pulsje aan hangen? en wat bdoel je met 5 bits informatie?

Als je inderdaad de valve aanstuurt in rpm's en geen feedback hebt van de valve dmv een sensor dan was dat het.
Als je wel een sensor op je valve had zitten met bv 500 ppr dan heb je meer en nauwkeurigere informatie.

bv je 5rpm en 6rpm zijn 2500 en 3000 pulsen per minuut oftewel 42 en 50 pulsen per seconde.
Dan kun je een betere curvefit maken.

Met 5 bits informatie bedoel ik dat je tabel die je hebt gemaakt maar 24 waardes heeft en dat kun je in 5 bits zetten (0..32).
Dat is dan een software afwijking, voor mij betekent dat je een vrij onnauwkeurige lookup tabel hebt waar je een curve fit van wilt maken.
Maar als er niet meer informatie nodig is dan kan het voldoende zijn. Als een gebruiker echt realistische m3/hr waardes wilt die niet verspringen zul je je tabel willen uitbreiden met meer metingen.
Voorbeeldje je hebt nu 1 = 33 en 5 = 164, als je dat lineair interpoleert krijg je 2 = 66, 3=99 etc.
Dat hoeft natuurlijk helemaal niet te kloppen dat kan ook een niet lineaire lijn zijn dus wil je eigenlijk de tussenliggende informatie ook hebben.
Om meer meetwaardes te creeren wil je dus ook de resolutie verhogen en dan kom je weer uit bij het bovenstaande punt van het aantal pulsen per tijdseenheid.

[hugo stoutjesdijk]

Nou, die 5 bits bij 0-32 toeren ben ik wel gedeeltelijk met je eens. Maar alleen als de toeren informatie 'hele' getallen zijn, en het ding draait tussen de 1 en 24 toeren.
Dan heb je maximaal 24 stappen terug koppeling.
Maar met curve fitten kun je rustig het volume bij 11.83 toeren uitrekenen.
Dat is juist het mooie van die curve fit, je maakt een tabel met 5 of 10 waarden, legt daar een curve door heen, vervolgens kun je op elk willekeurig tussen punt de waarde van de curve bepalen.
Die curve is nl. niet leneair, maar een functie met verschillende machten waarmee je bepaald dat de kromme netjes door de gemeten punten gaat, in de praktijk betekend dat dat de tussenliggende waarden dan wel kloppen.
Jij gaat uit van een lookup tabel, maar als je een formule kunt gebruiken heb je een oneindig grote lookup tabel.
Maar ook de lookup tabel kun je middels je excel grafiekje veel groter maken door 10x zoveel tussen punten in je tabel te zetten.

Maar de motor zal wel 0-1400 toeren draaien, met een vertraging er achter, dus is er opeens een info van meer dan 1000 punten.

[Kjelt]

Dat is juist het mooie van die curve fit, je maakt een tabel met 5 of 10 waarden, legt daar een curve door heen, vervolgens kun je op elk willekeurig tussen punt de waarde van de curve bepalen.
Die curve is nl. niet leneair, maar een functie met verschillende machten waarmee je bepaald dat de kromme netjes door de gemeten punten gaat, in de praktijk betekend dat dat de tussenliggende waarden dan wel kloppen.

Ik snap wat je doet dat doe ik ook vaak bij software waar ik een ADC uitlees die overeen komt met een fysieke grootheid.
Dat is op zich een hele mooie manier van interpoleren en benaderen echter mijn punt is het staat en valt met de hoeveelheid input.
Wat hij minstens zal willen doen is alle 24 rpm waardes bepalen dan heb je 24 punten en kan de curve er alweer heel anders uitzien in ieder geval heb je meer nauwkeurigheid op de tussenliggende stukken.

[DaBit]

Met 'bits' heeft dit niks te maken, da's ook maar een specifiek gevalletje van resolutie weergeven dat hier niet echt van toepassing is. En resolutie zegt verder nog helemaal niks over de nauwkeurigheid. Zelfde als met een digitale schuifmaat; de resolutie is 0,01mm, de nauwkeurigheid is lager dan dat.

Waarschijnlijk als je met 5 significante cijfers het toerental weet dat je nog niet nauwkeuriger het debiet kunt voorspellen dan met anderhalf cijfer. Ik zou de RPM waarde in een van de hierboven gegeven formules stoppen en het debiet wat eruit rolt op het HMI-schermpje zetten. Blijkt dat onvoldoende accuraat, dan eens kijken hoe je dat accurater kunt krijgen. En waarschijnlijk heb je dan wel meer aanpassingen in het hele systeem nodig dan enkel nauwkeuriger het toerental van de klep bepalen.

[Swets]

iets van een puls op die rotary valve? heeft toch geen zin, ik weet hoe hard hij draait, dat heb ik in me freq.Drive....
tis alleen als hij harder draait, neem hij minder product mee....
waar wil jij dan pulsje aan hangen? en wat bdoel je met 5 bits informatie?

Als je inderdaad de valve aanstuurt in rpm's en geen feedback hebt van de valve dmv een sensor dan was dat het.
Als je wel een sensor op je valve had zitten met bv 500 ppr dan heb je meer en nauwkeurigere informatie.

bv je 5rpm en 6rpm zijn 2500 en 3000 pulsen per minuut oftewel 42 en 50 pulsen per seconde.
Dan kun je een betere curvefit maken.

Met 5 bits informatie bedoel ik dat je tabel die je hebt gemaakt maar 24 waardes heeft en dat kun je in 5 bits zetten (0..32).
Dat is dan een software afwijking, voor mij betekent dat je een vrij onnauwkeurige lookup tabel hebt waar je een curve fit van wilt maken.
Maar als er niet meer informatie nodig is dan kan het voldoende zijn. Als een gebruiker echt realistische m3/hr waardes wilt die niet verspringen zul je je tabel willen uitbreiden met meer metingen.
Voorbeeldje je hebt nu 1 = 33 en 5 = 164, als je dat lineair interpoleert krijg je 2 = 66, 3=99 etc.
Dat hoeft natuurlijk helemaal niet te kloppen dat kan ook een niet lineaire lijn zijn dus wil je eigenlijk de tussenliggende informatie ook hebben.
Om meer meetwaardes te creeren wil je dus ook de resolutie verhogen en dan kom je weer uit bij het bovenstaande punt van het aantal pulsen per tijdseenheid.

aha... maar ja , dat lijstje is alles wat ik heb...
ik had ook eerst helemaal niet gezien dat het niet lineaire was....
ik krijg uit me freq.Drive -1500 /+1500 bij 50 hz..... dus ik had het eerst gewoon lineaire verschaald.... maar ja toen klopt er dus niet veel van.... ( ja alleen bij 0Hz en 50Hz :-) )
het hoeft ook niet zo heel erg super precies..... het gaat er om dat de operator ongeveer kan doen hoeveel m3/hr hij doet.....
want het blijft theorie.... in theorie doet de rotary valve dan zoveel..... of de cement dan ook echt zo hard door dat ding gaat?!?

[Swets]

ik heb net nog even op me gemakkie al de linkjes bekeken....

en ff met de getallen zitten spelen....

zijn wel handige tooltjes.... ik heb wel eens meer zoiets.... normaal zat ik dan net zolang met getallen te rommelen totdat het ergens op leek....

ik had hier is geprobeerd 1 rpm = 33 en dat liniear zo door gerekende.... (dus 24x33=792) toen gekeken wat ik aan het eind teveel had tov me lijstje...(dus 792-599=233) toen een 2de getal gemaakt welke ook weer aan de rpm hing, maar dan van 0 tot het max verschil liep, en deze weer van de eerste afgetroken.... maar dit is toch wel makkelijker....

alleen wat ik nog niet snap, die link van floppy geeft m3=-0.5028494816 x (rpmXrpm)+35.57470319 x rpm - 3.324862023
en daar heb ik net getallen in zitten vullen... en dat klopt....


maar tis een hele andere formule als die eerste? M3 = (23,292+(7,958/16*(24-toerental))*toerental

dat snap ik nog niet helemaal.... dit heb ik nooit gehad op de LTS?

oja, ik had nog een 12 getal, 26= 580... was ik ff vergeten in me lijstje te zetten, omdat de rpm niet hoger gaan als 25....

[Swets]

nog zomaar een vraag.... er komen een hoop slimme mensen hier...

Ik weet wel het heeft niets met CNC te maken....


maar ik wil in mijn plc een random getal genereren.....
maar er zit dus geen functie in mijn plc...

hoe kan ik dat het beste doen?

ik heb trouwens wel een realtime klok erin zitten.... misschien kan ik daar iets mee?

[Kjelt]

Ah ja random nummers heb ik tien jaar geleden behoorlijk wat tijd aan besteed.
Ik neem aan dat jouw random nummer niet heel erg hoog secure hoeft te zijn dus dan wordt het heel makkelijk.

Je hebt twee dingen nodig:
1) entropie, dat is de seed voor je RNG (random nummer generator) simple gezegd is dit de echte random ruis input, data die niet voorspelbaar is en ook niet gemanipuleerd kan worden. In jouw geval is de real time klok een mooie bron van deze data. Kun je de milisecondes gebruiken of heb je alleen de datum en tijd in uren minuten en secondes ? Op zich al genoeg, die data stop je binair in je (P)RNG 2)

2) (P)RNG een pseudo random number generator die heb je in alle soorten en maten eigenlijk grofweg twee: een true random nummer generator (die is onvoorspelbaar en wordt gebruikt voor encryptie en security) en een pseudo random nummer generator die wel voorspelbaar is maar voor jouw toepassing meer dan volstaat denk ik.
Dus het wordt een PRNG en de makkelijkste is een lineair shift register met feedback.
https://en.wikipedia.org/wiki/Linear-fe ... t_register

Dus je voedt 2) eenmalig met 1) bij het opstarten van het programma en dan kun je iets van honderdduizend pseudo random nummers uit 2) trekken

Ik weet niet in welke taal je dit wilt programmeren, in C heb ik het wel ergens op de plank liggen en anders kan ik je er wel mee helpen.

[Swets]

Ah ja random nummers heb ik tien jaar geleden behoorlijk wat tijd aan besteed.
Ik neem aan dat jouw random nummer niet heel erg hoog secure hoeft te zijn dus dan wordt het heel makkelijk.

Je hebt twee dingen nodig:
1) entropie, dat is de seed voor je RNG (random nummer generator) simple gezegd is dit de echte random ruis input, data die niet voorspelbaar is en ook niet gemanipuleerd kan worden. In jouw geval is de real time klok een mooie bron van deze data. Kun je de milisecondes gebruiken of heb je alleen de datum en tijd in uren minuten en secondes ? Op zich al genoeg, die data stop je binair in je (P)RNG 2)

2) (P)RNG een pseudo random number generator die heb je in alle soorten en maten eigenlijk grofweg twee: een true random nummer generator (die is onvoorspelbaar en wordt gebruikt voor encryptie en security) en een pseudo random nummer generator die wel voorspelbaar is maar voor jouw toepassing meer dan volstaat denk ik.
Dus het wordt een PRNG en de makkelijkste is een lineair shift register met feedback.
https://en.wikipedia.org/wiki/Linear-fe ... t_register

Dus je voedt 2) eenmalig met 1) bij het opstarten van het programma en dan kun je iets van honderdduizend pseudo random nummers uit 2) trekken

Ik weet niet in welke taal je dit wilt programmeren, in C heb ik het wel ergens op de plank liggen en anders kan ik je er wel mee helpen.

Ik programmeer in structed text, is een soort basic variant....

ik heb uren, minuten , seconde.... maar ik heb ook een systeem woord, wat elke mSec wordt opgehoog, en eentje die elke 100ms wordt opgehoog...

ik ga ff je link bekijken... kijken of ik daar iets mee kan...
alvast bedankt!

[Swets]

ik heb nu dit, en werkt vrij aardig:

Code: Selecteer alles

(* moeilijk verhaaltje om een random getal te genereren 					*)
(* Dit getal word zichtbaar gemaakt op het scherm als het PASSWORD ID				*)

(* genereerd een random getal tussen de 0 en 99999999 						*)
random (a := 1909, b := 221571, N := 99999999,random := udintTmpRandom);


(* %sw18 is een continue teller in de PLC, deze begint te tellen zodra de PLC  aan is		*)
(* %sw50 zijn de seconde uit de klok   ss00							*)
(* %sw51 uren/minuten uit de klok  uumm								*)

udintTmpRandom:=(udintTmpRandom * int_to_udint(%sw18)/int_To_Udint(%sw50))*int_to_Udint(%sw51);

dintTmpRandom:=udint_to_dint(udintTmpRandom);

(*getal omzetten naar een string *)
strRandtmp := DINT_TO_STRING (IN := dintTmpRandom);

(* het goede stuk uit de string knippen*)


lengte:=len_int(strRandtmp);

aantalKarakters:=6;
VanafKarakter:=lengte-3;

strActRandom := MID_INT (IN := strRandtmp,N := aantalKarakters,P := (lengte+1)-VanafKarakter); 

dintActRandom:=String_To_Dint(strActRandom);

en in die Functie zit:

Code: Selecteer alles

random:=(a*random+b) MOD N;

dus dit is een vrij random getal..... en ook omdat de klok er in zit krijg ik niet steeds als ik de plc opnieuw in run zet de zelfde getallen (dat had ik eerst)

dus ik maak genereer een vrij groot random getal, en dan maak ik er een string van, en dan knip ik 6 karakters uit die string....



maar ik geloof wel dat dit volstaat....


Ik maak nu ook contineu die random 6 karakters lang variabele, en pak hem alleen op een bepaald moment.... dus ja ik geloof niet dat je nu van te voren weet wat het getal word....



ik ga het gebruiken om een soort van ehhh hoe zeg je dat....

Ik schrijf dus PLC software... met vrij veel settings erin... (tijdjes, drukken enz enz) nu hebben we een aantal settings , die zijn alleen voor ons... die zitten wel achter een password...
maar het gebeurt regelmatig , dat we toch willen dat een klant, (in bangladesh of China of of of ) zo'n setting veranderd... en ja om er dan naar toe te gaan, en ja dan geef je dus het password, maar dan weten ze gelijk het password voor altijd.... en dat willen we eigenlijk niet....

Dus ik ben nu een verhaaltje aan het verzinnen.... de PLC genereerd een random getal, dat staat ergens in het HMI scherm, als PassWordIDnumber....
op dit getal laat ik ook weer een rekensommetje los.... in me test had ik * 2019 en dan knip ik er ook weer 6 karakters uit vanaf plek 3 ....

dat rekensommetje weten alleen wij, en de PLC....


dus een klant belt.... we vragen het PassWordIDnumber.... doen het rekensommetje, en weten het password op dat moment.... ze kunnen een setting wijzigen.... na het wijzigen, wordt er gelijk weer een nieuw random getal gekozen..... ik denk dat dit aardig waterdicht is?

[Kjelt]

Moet ik eerlijk zijn ? Nee dat is zeker niet waterdicht maar afhankelijk van de klant of ze het willen hacken en hoeveel keer ze mogen bellen is het wel aardig.
Maar dat zeg ik dan als voormalig security engineer, dus…
Wat je hier doet is een vorm van challenge response mechanisme.
Daarvoor zijn er sterke cryptografische algoritmes die meestal toegepast worden zoals public key cryptografie waarbij de fabrikant een geheime sleutel heeft en een publieke sleutel.
Ieder apparaat krijgt af fabriek de publieke sleutel mee in zijn programma en daarmee kan een bericht van de fabrikant verifieren, hij kan dan zien dat een bericht wel of niet door de fabrikant is gemaakt (dus encrypted met de geheime sleutel van de fabrikant).
Waarschijnlijk overkill voor je ?

Kun je informatie verbergen in je PLC, dus een stukje geheugen gebruiken waar de klant nooit bij kan alleen de machine zelf ? Ik weet niet hoe je nu je password opslaat maar ik neem aan dat die niet ergens in de clear in het geheugen staat?

Als je een stukje geheim geheugen hebt dan is het simpelste eigenlijk om daar een redelijk one time pad tabel in te zetten (liefst per machine verschillend) en dan de PLC als de klant toegang wil een keuze te maken uit die OTP tabel (index) met machinenr en daar een rekensom over los te laten.

[Swets]

ja ze kunnen het maar 1 keer proberen.... bij een fout antwoord... maak ik eerst weer een nieuw random getal.....

dus ja voor je dan weet dat het maal 2019 moet, en dan dat je 6 karakters moet pakken vanaf plek 2... ofzo... ik denk niet dat ze daar snel achter komen...

beter dan nu, als ze 1 keer het password weten, weten ze het voor altijd....

ken ook nog maken, als ze het 3 x fout doet , alles in elkaar loopt... :-)

[Kjelt]

In ieder geval wel even het rekensommetje veranderen want het staat nu al open en bloot op het internet

Alles in elkaar laten lopen zou ik nooit doen, dan ben je aansprakelijk want je hebt iets gemaakt wat express kapot kan gaan (ook al heeft de gebruiker het tig keer geprobeerd).
Bij brute force wachtwoorden raden adviseer ik gewoon steeds 2x langer te wachten voor er weer een poging ondernomen mag worden, en dan wel de laatste wachttijd onthouden (anders zetten ze het uit en aan en gaan weer verder).
Dan stoppen ze er snel genoeg vanzelf mee.