Hallo CO'ers
Ik ben op zoek naar een component die het volgende doet en waarbij Ti in milliseconden is in te stellen:
____ ________ ______
In: ______| |_____| |_| |______________
| |
| ____ ________ ______
Out:_____________| |_____| |_| |_______
| | | |
| Ti | | Ti |
|<---->| |<---->|
En deze component moet op een din-railtje in een besturingskast gemonteerd kunnen worden, of als in-line compnent gemonteerd kunnen worden.
Hopelijk heeft iemand van jullie een idee?
Ik verzin wat uit mijn hoofd:
Het originele signaal in een monostabiele multivib met periode t1.
Het geinverteerde signaal ook in een mono, met periode t2.
De uitgang van de t1 mono gaat naar de set van een flipflop.
De uitgang van de t2 mono gaat naar de reset van die flipflop.
De Q uitgang van de flipflop is je signaal, met opgaande flanken t1 vertraagd en de neergaande met t2 vertraagd.
Zie ik wat over het hoofd? Anders werkt dit zoals je wilt.
e: Ja dus, probleem: dit werkt alleen als het signaal niet sneller wisselt dan t1 of t2.
Terug naar de tekentafel..
Of anders een rolletje kabel met aftakkingen om de 300 kilometer, eentje per milliseconde. 
[Bericht gewijzigd door Frederick E. Terman op (11%)]
Niet helemaal zoals ik het bedoel maar het zal ongetwijfeld werken.
Vraag me alleen af hoe ik bijvoorbeeld 60(ms)*300km kabel in een klein doosje ga krijgen, zonder dat ik te veel vermogensverlies heb en mijn 24V signaal kwijt ben.
Maar waar ik eigenlijk naar op zoek ben is dus iets dat een signaal 'opneemt' en met een vertraging van bijvoorbeeld 60ms weer 'afspeelt'. En dan het liefst industrieel toepasbaar...
SparkyGSX
Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
Wat wil je hier precies mee bereiken? Wat is de maximale frequentie van het signaal, oftewel de minimale tijd dat het signaal hoog of laag kan zijn? Wat is de gewenste resolutie; met andere woorden, hoe groot mag de fout is de vertraging worden?
Je zou dit in een micro-PLC kunnen stoppen, die bijvoorbeeld elke milliseconde de status van een ingang opslaat, daar een buffer van bijhoudt, en ook elke milliseconde de waarde die aan het eind van het buffer staat, naar een uitgang stuurt. Om een resolutie van 1ms te halen moet je dan wel met timers en directe in- en uitgangen gaan werken, want de meeste PLCs hebben een cyclustijd die veel langer is dan 1ms (meestal 20-50ms). Om 60 samples op te slaan heb je een buffer van 60 bits nodig, als je het efficiënt programmeert, of 60 bytes als je meerdere in- en uitgangen op die manier wilt bewerken (met gelijke vertraging), of het eenvoudig wilt houden, en toch voldoende geheugen hebt.
En een relais met een opkom EN afvalvertraging? (het huidige signaal is afkomstig van een relais, dat aangesloten is op een prox) Bestaat dat met de mogelijkheid? (laten we het qua instelling op een resolutie van 10ms houden)
Ik heb het al geprobeerd met een logo-plc'tje maar die pikte het niet inderdaad.
Arco
Special Member
Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Als je met een vaste 10mS genoegen neemt, is een extra relais al voldoende.
Meeste 10A printrelais hebben 10mS aantrek en afvaltijd...
SparkyGSX
Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
Waar komt dat signaal nou vandaan (wat is een prox? een proximity detector?), en waarom wil je dat vertraagd hebben? Je komt hier met een halve oplossing, die "alleen" nog even geïmplementeerd moet worden. Wat is nu je fundamentele probleem?
Ik ken de Logo nauwelijks, maar ik kan me voorstellen dat je daar ook een soort schuifregister in kunt maken. Waarschijnlijk zul je ook daar iets bijzonders moeten doen om de timing goed te krijgen en houden, zodat die niet afhankelijk is van de cyclustijd.
@Arco: de TS heeft het over een vertraging van 60ms, met een signaal dat afkomstig is van een relais, maar tekent tegelijk een signaal dan pulsen kan bevatten van zo'n 15ms. Dat impliceert dat er signalen kunnen zijn die wel doorgegeven moeten worden, waarvan de pulslengte minder is dan de gewenste vertraging.
[Bericht gewijzigd door SparkyGSX op (24%)]
Net als bij mijn wilde gedachte, kan een relais dat ook niet.
Je gaat langzaam denken aan sampelen en in een buffer stoppen, met een ingangs- en een uitgangspointer met het gewenste verschil.
Op 17 november 2011 15:58:43 schreef Verbatim:
En deze component moet op een din-railtje in een besturingskast gemonteerd kunnen worden, of als in-line compnent gemonteerd kunnen worden.
Phoenix Contact heeft handige din-rail behuizingen:
depeet
Depeet
Op onderstaande link vind je regelbare delaylines, eventuele problemen die kunnen optreden zijn wellicht de te gebruiken spanning en/of stroomtoevoer. Wellicht zijn deze op te lossen door torren of drivers.
SparkyGSX
Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
Op 17 november 2011 17:27:11 schreef Frederick E. Terman:
Je gaat langzaam denken aan sampelen en in een buffer stoppen, met een ingangs- en een uitgangspointer met het gewenste verschil.
Dat is toch precies wat ik in mijn eerste berichtje schetste?
De TS heeft nog steeds niet vertelt wat het fundamentele probleem nu eigenlijk is. Meestal blijkt, wanneer dat uiteindelijk wel wordt gedaan, dat de TS probeert het verkeerde probleem op te lossen. Dat is ook precies wat ik al eerder probeerde duidelijk te maken: kom niet met een halve oplossing, maar met een heel probleem, zodat we een beetje overzicht kunnen krijgen, in plaats van een idioot ingewikkelde oplossing te verzinnen voor een probleem dat waarschijnlijk alleen in het hoofd van de TS bestaat.
Bedankt voor de reacties, ik zal even mijn probleem nader toelichten met een situatieschets.
Bij het bedrijf waar ik werk heb ik een vision systeem geinstalleerd. De huidige situatie is als volgt:
De prox (proximity sensor) meet de puls van het product. de producten liggen 150mm uit elkaar. de band loopt met 50m/min (0,833mm/ms) en dat geeft ongeveer 180ms tussen de producten en dus de puls.
het vision systeem heeft een cyclustijd van minimaal 50ms. En de positie van de vision camera maakt het noodzakelijk dat er 120ms aan wachttijd nodig is om een product loodrecht onder de camera te hebben. De marge van 10ms is te klein om te garanderen dat er altijd een volledige cyclus gedraaid kan worden, omdat de cyclustijd van het vision systeem (wanneer er een fout product gedetecteerd wordt en er dus gelogd moet worden) met 40ms kan toenemen.
Daar komt bij dat de producten te klein zijn om met een andere proximity sensor te meten. (kunststof, 1x1x0,1mm x 20 naast elkaar)
Er zijn echter een aantal eisen: het mag alleen electrisch verbeterd worden omdat de band alleen bij defect aan de machine wordt stopgezet.
ik hoop dat dit de situatie duidelijker maakt waarom ik graag een (zoals de naam van het topic inmiddels veranderd is) pulsvertrager zoek.
Wouter van Ooijen
Wouter van Ooijen: VOTI webwinkel, docent HvU (Technische Informatica); C++ on mictrocontrollers blog
Als er binnen die Ti tijd veel dingen kunnen gebeuren (meerdere keren hoog/laag, zoals je schets suggereert) en je ook nog een behoorlijk resolutie wilt hebben dan praat je over een systeem met een behoorlijke hoeveelheid geheugen! Is de lengte van de uitgaande puls trouwens van belang (moet die gelijk zijn aan de ingaande puls, of mag die vast zijn?), of alleen de opgaande flank? Ik denk dat je het probleem nog wat nauwkeuriger moet beperken om een redelijke oplossing mogelijk te maken.
Ik moet toegeven dat de puls niet zo netjes getekend is van mij. de pulslengtes verschillen niet ZO veel in lengte en bij een verschuiving van 60ms en een 'afstand' van 180ms zullen de in- en uitgaande puls elkaar niet overlappen. wat ik wil bereiken is simpelweg dat het signaal dat IN komt, er 60ms later pas uit komt. is het niet zoiets als de propagation delay van een IC?
Wouter van Ooijen
Wouter van Ooijen: VOTI webwinkel, docent HvU (Technische Informatica); C++ on mictrocontrollers blog
Op 18 november 2011 12:02:35 schreef Verbatim:
wat ik wil bereiken is simpelweg dat het signaal dat IN komt, er 60ms later pas uit komt. is het niet zoiets als de propagation delay van een IC?
Als je zegt het "het signaal wat er in gaat er weer uit moet komen" dan vraag je om iets behoorlijk ingewikkelds. Veel eenvoudiger is bv. "x ms na een opgaande flank in moet er een opgaande flank uit komen, pulsbreedte 50 ms", met de aantekening dat er "pas na het afhandelen van een puls (inclusief uitgangspuls) weer een nieuwe ingangspuls zal aankomen". Dan kan je het met 2 555 chips afhandelen.
Nu ik het zo bekijk is het inderdaad misschien niet eens nodig dat exact dezelfde puls er uit komt... sorry voor deze omslag van het topic. belangrijk is dat de vertraging er in zit, en dat er inderdaad bij de opgaande flank na een vertraging van 60ms wederom een flank is met een bepaalde tijd. dat zal wel mogelijk zijn met een (opto?) relais. het enige probleem bij een optorelais is weer dat ik het daarmee geprobeerd heb maar dan de uitgang blijkbaar constant hoog blijft omdat er een miniscuul stroompje kan lopen.
EDIT: Die 555's zijn niet echt industrieel toepasbaar... liever iets dat zo op een din-rail geklikt kan worden.
Wouter van Ooijen
Wouter van Ooijen: VOTI webwinkel, docent HvU (Technische Informatica); C++ on mictrocontrollers blog
Ik heb geen verstand van DIN rail spul, maar met deze wat "versimpelde" omschrijving kan iemand anders misschien wat vinden.
"constant hoog door een miniscuul stroompje" lijkt me op te lossen door er een belasting (weerstandje) aan te hangen?
De hebt trouwens niet aangegeven over wat voor pulsen je het hebt. 0-5V? 0-24V? stroom kring? (en als spanning: hoeveel stroom moet er geleverd worden?)
SparkyGSX
Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
Zo'n vertraging zou je prima in een (micro) PLC moeten kunnen implementeren. In de gegeven situatie zou ik er echter niet voor kiezen om een constante tijd te wachten, maar een bepaalde afgelegde afstand, want dat is uiteindelijk wat je wilt bereiken. Je zou dat kunnen doen met een pulsgever op de band, of met een uitgang van een frequentieregelaar o.i.d.
Ook als je het alleen elektrisch wilt aanpassen, zul je het proces voor een bepaalde tijd stil moeten leggen, dus dat lijkt me niet echt een steekhoudend argument.
Op 18 november 2011 00:34:07 schreef SparkyGSX:
[...]
Dat is toch precies wat ik in mijn eerste berichtje schetste?
Dat had ik even moeten 'beamen'. Maar bovendien bedoel ik eigenlijk iets anders.
Bij een schuifregister denk ik aan een lange rij cellen waarbij de databitjes steeds naar de volgende verplaatst worden. De vertraging in klokpulsen is dan de lengte van het register (die is vast).
Wat ik bedoel is een buffer waarin de databits gewoon blijven staan, maar waarbij de leeswijzer steeds opgehoogd wordt, en de schrijfwijzer natuurlijk ook. Je hoeft dus niet steeds iedere klokpuls alle bits van de data te verplaatsen; je hoogt alleen de pointers op.
Pas als je 'rond' bent, begin je weer bij het begin te schrijven (en even later te lezen), en dan pas ga je over de oude data heen.
De vertraging is dan de afstand tussen lees- en schrijfpointer (die kun je kiezen).
Hoe dan ook, als er meer dingen binnen de vertragingstijd kunnen gebeuren, dan heb je dus inderdaad geheugen nodig (@WvO) om dat te onthouden voordat ze weer doorgegeven kunnen owrden.
Maar misschien ligt dat dus nu weer iets anders. Ik lees nog even mee.
Op 17 november 2011 16:06:11 schreef Frederick E. Terman:
Of anders een rolletje kabel met aftakkingen om de 300 kilometer, eentje per milliseconde.
Doe maar 200km per aftakking (losse pols)
Hé, en ik had nog wel in ge-edit: (maal verkortingsfactor).
Op die computer (niet deze) moet ik er goed op letten dat ik F5 gebruik bij het editten.
Maar mischien kan ik beter beweren dat ik natuurlijk wide-spaced open luchtlijn bedoelde. 
Op 18 november 2011 15:00:56 schreef JoWi:
[...]Doe maar 200km per aftakking (losse pols)
nee dan past het wel 
Treft mij het geluk dat vandaag de lijn toevallig stil stond. Ik heb de camera kunnen verplaatsen in de lijn en we wachten af tot maandag voor wat het gaat worden met de nieuwe positie.
De oplossing van alex278 komt vooralsnog het meest in de richting, ware het niet dat het niet in een din-rail verpakkinkje zit. maar met de huisjes van Henry S. lukt het misschien ook wel dan.
Ik moet in de komende weken op nog een andere productielijn een zelfde systeem inbouwen, dus daar kan hetzelfde probleem optreden. DE oplossing is nog steeds gewenst.
Op 18 november 2011 13:17:32 schreef SparkyGSX:
Ook als je het alleen elektrisch wilt aanpassen, zul je het proces voor een bepaalde tijd stil moeten leggen, dus dat lijkt me niet echt een steekhoudend argument.
Voor een kleine elektrische aanpassing hoeft de lijn niet stil omdat het vision systeem een eigen decentrale voeding heeft. uitschakelen van deze voeding is dus voldoende.
Het gaat uiteindelijk om een 24V circuit. De delay dient ingebouwd te worden in het trigger signaal. uit het vision systeem komt een constante 24V en deze wordt door het relais van de proximity sensor in stukjes gehakt en tot pulsjes voorgekauwd.
Over het optocouple wat ik eerst gebruikt heb, zou ik eventueel inderdaad een pull-down weerstandje kunnen zetten... dat ik daar nog niet aan gedacht heb. maar dan heb ik de delay er nog steeds niet in zitten. ik denk wel dat ik het optocouple terug ga schroeven.
In de beschrijving van de visioncontroller kan ik niet direct vinden hoeveel stroom er naar de ingang mag lopen. er staat alleen dat het een digitale ingang betreft (24v).
SparkyGSX
Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken
@FET: een circulair buffer met bewegende lees- en schrijfbuffers is natuurlijk weinig anders dan een schuifregister met optimalisaties voor implementatie in software. Je kunt de lengte van een schuifregister aanpassen door te kiezen waar je de "uitgang" plaatst, op dezelfde manier dat je de afstand tussen de lees- en schrijfpointers kunt kiezen.
Nu lijkt het er echter op dat er, tijdens de vertraging, geen nieuwe events meer kunnen plaatsvinden, en dat maar 1 van de 2 flanken relevant is.
Ik heb dergelijke problemen (sorteerlijnen e.d.) in het verleden prima met micro-PLCs op kunnen lossen, maar daar moet ik wel de kanttekening bij plaatsen dat de producten en tussenruimtes daarbij veel groter waren, en de band veel langzamer liep. Daar werden de producten gedetecteerd, waarbij de huidige tellerstand van een pulsgever werd opgeslagen. Zodra het product op de gewenste bestemming was aangekomen (een bepaalde afstand, en dus aantal pulsen verder, afhankelijk van het product), werd de juiste uitstoter bediend. Met een slimme implementatie moet hetzelfde concept hier ook wel kunnen werken.
free_electron
Silicon Member
Professioneel ElectronenTemmer - siliconvalleygarage.com - De voltooid verleden tijd van 'halfgeleider' is 'zand' ... US 8,032,693 / US 7,714,746 / US 7,355,303 / US 7,098,557 / US 6,762,632 / EP 1804159 - Real programmers write Hex into ROM
gewoon een schuifregister pakken... met de clocksnelheid te regelen stel je de vertraging in.
een 555 , een potmeter en een tros 74164 kunnen het werk doen...
al dat gedoe met plc's , microprocessors , 300km lange delay lines ...
[Bericht gewijzigd door free_electron op (24%)]