CNC voedingssnelheid meetinstrument gemaakt van schroot - Ajarnpa

2024 Auteur: John Day | [email protected]. Laatst gewijzigd: 2024-01-30 11:18

Heeft iemand ooit de werkelijke voedingssnelheid op een CNC-machine willen meten? Waarschijnlijk niet, totdat de freesbits intact zijn na een CNC-klus… maar als ze regelmatig beginnen te breken, is het misschien tijd om het te onderzoeken. In deze instructable kun je een zoektocht volgen bij het bepalen van de werkelijke voedingssnelheid van een CNC-machine. Het zal betrekking hebben op het reverse-engineeringgedeelte van een printer, arduino-firmware, pc-software en de resultaten die ik heb gekregen met de hulp van mijn collega's, en een prullenbak die in een schat is veranderd.

Stap 1: Materialen, gereedschappen, apparaten die worden gebruikt om het project te laten draaien

Toen ik hieraan begon te werken, bedacht ik een korte lijst van de dingen die we nodig hebben:

• gedemonteerd printerwagenmechanisme
• handgereedschap om dat aan te passen
• soldeerbout, soldeer, draden
• multimeter
• oscilloscoop of logische analysator - dit is niet absoluut noodzakelijk
• stroomvoorziening
• microscoop
• Arduino nano + pinout
• PC met Arduino IDE, Visual Studio 2008 Express + MS Charting-tools geïnstalleerd
• (MPU6050 - Ik heb dit uiteindelijk niet gebruikt)
• bereid om te bladeren naar alles wat je niet weet hoe te doen

In het begin dacht ik dat ik met een MPU6050-bord de voedingssnelheid op alle drie de assen tegelijk zou kunnen meten. Met de versnellingsmeter erin, was ik er zeker van dat het optellen van versnellingsmetergegevens me de gewenste waarde zou geven - de snelheid op elke as. Na het downloaden en wijzigen van een Arduino-fragment dat onbewerkte gegevens op de seriële monitor weergaf, schreef ik een klein pc-programma in Visual Studio dat de gegevens verwerkte en het in een grafiek uitzette voor eenvoudigere interpretatie. Hiervoor moest ik zowel Visual Studio C# Express 2008 als de grafiekentools downloaden.

Na een tijdje coderen en het opzoeken van alle dingen die ik nodig had voor seriële communicatie, eindigde ik met de uitgezette waarden, maar wat ik ook deed, het was niet bruikbaar. Kleine maar plotselinge bewegingen zouden resulteren in enorme pieken, terwijl langere reizen niet eens in de hitlijsten zouden verschijnen. Na twee dagen hameren op de MPU6050, gaf ik het uiteindelijk op en wendde ik me tot iets anders: een gedemonteerd printerpositiefeedbackmechanisme.

Stap 2: Hardware-dingen die gedaan moesten worden

Reverse engineering

Natuurlijk had het printermechanisme geen onderdeelnummer dat ik had kunnen gebruiken om de exacte eigenschappen te bepalen, er was een beetje reverse-engineering nodig om te komen waar we wilden. Na het mechanisme en de elektronica nauwkeurig te hebben onderzocht, besloot ik dat als eerste de identificatie van de optische sensorpinnen moest zijn. Dit moest worden gedaan om het hele ding aan de Arduino te koppelen. Ik heb het zwarte plastic onderdeel gedemonteerd, de printplaat eruit gehaald en de sensor onderzocht: er stond ROHM RPI-2150 op geschreven. Daar werd ik blij van, de hoop was groot dat ik een datasheet zou vinden. Helaas is dit een oud of een aangepast onderdeel - er was nergens op internet een datasheet te vinden. Dit betekende dat ik het heft in eigen handen moest nemen: wetende dat deze sensoren meestal een infrarood-LED en twee fototransistoren aan de binnenkant hebben, pakte ik een multimeter, zette deze in de diode-meetmodus en begon tussen de pinnen te meten.

De stroompinnen zijn meestal gemakkelijk te vinden - er zijn condensatoren over en ze zijn meestal verbonden met brede sporen op de PCB's. Grondsporen zijn vaak verbonden met meerdere pads voor een betere ruisonderdrukking.

De invoer- en uitvoerpinnen zijn echter niet zo triviaal. Bij het meten over een diode zal de meter zijn voorwaartse spanning in de ene richting tonen en overbelasting (oneindig) in de andere. Ik kon vier diodes tussen de pinnen identificeren, ik concludeerde dat de vierde diode een soort zener- of TVS-diode moest zijn, omdat deze precies tussen de voedingspinnen van het onderdeel zat. Het lokaliseren van de infraroodzender was eenvoudig, er was een 89R-weerstand in serie mee. Ik kreeg twee diodemetingen op de resterende twee pinnen, dat moesten de twee ontvangers zijn.

Let op: Deze sensoren hebben twee ontvangers om naast de positiebepaling door het tellen van de pulsen ook de bewegingsrichting te kunnen bepalen. Deze twee uitgangsgolfvormen zijn 90° uit fase, dit wordt gebruikt om een optel- of aftelpuls te produceren. Door het aantal van deze pulsen te volgen, kan de exacte positie van de printkop worden bepaald.

Toen de zender en de twee ontvangers waren gelokaliseerd, heb ik draden op hun pinnen gesoldeerd, zodat ik de sensor met de Arduino kan verbinden. Voordat ik dat deed, voorzag ik de sensor van 3,3V, trok de strip een paar keer tussen de sensor en observeerde de blokgolf op de uitgangen. De frequentie van de blokgolf varieerde met de bewegingssnelheid en ik concludeerde dat het meetsysteem nu klaar is om op de Arduino te worden aangesloten.

De Arduino aansluiten

Het aansluiten van deze nieuwe 'sensor' is heel eenvoudig. Sluit gewoon de sensoruitgangen aan op D2 en D3 (pinnen met onderbrekingsmogelijkheid!) en de voedingskabels en het coderen kan beginnen.

Stap 3: Arduino-codering

De Arduino-code is vrij eenvoudig. Ik heb een functie toegewezen die wordt uitgevoerd elke keer dat D2 een stijgende flank ziet, dit is de verstrijkingsfunctie van de Arduino-code die ik heb bijgevoegd. Als je naar de signalen van een kwadratische encoder kijkt, zie je dit:

• in één richting is fase A logisch hoog op elke fase B stijgende flank
• in de andere richting is fase A logisch laag op elke fase B stijgende flank

Dit was de eigenschap van de encoder die ik heb geprofiteerd: aangezien de elapse-functie elke keer wordt uitgevoerd als D2 een stijgende flank heeft, heb ik zojuist een if geschreven die een teller verhoogt wanneer D3 hoog is en deze verlaagt wanneer D3 laag is. Dit werkte bij de eerste poging, ik stuurde de tellerwaarde naar de seriële monitor en zag deze toenemen / afnemen toen ik de printerkop op de as bewoog.

Om een lang verhaal kort te maken, de firmware doet het volgende in de loop-functie:

1. controleert de seriële ontvangstbuffer op binnenkomende gegevens
2. als er inkomende gegevens zijn, controleer dan of het een '1' is of niet
3. als het een '1' is, betekent dit dat de pc-software om de tellerwaarde vraagt
4. stuur de tellerwaarde via serieel naar de pc
5. opnieuw beginnen bij 1.

Hiermee ligt de bal nu bij de pc-software. Laten we daar op ingaan!

Stap 4: Visual Studio C#-software

Het doel van het VS C#-programma was om de rekenlast van de Arduino naar de pc te verplaatsen. Deze software ontvangt de gegevens die de Arduino levert, berekent en geeft de snelheid weer in de vorm van een grafiek.

Wat ik eerst deed was googlen hoe seriële communicatie in C# te doen. Ik vond veel goede informatie op MSDN.com, samen met een goed voorbeeld, en ik gooide gewoon weg wat ik niet nodig had - eigenlijk alles behalve het leesgedeelte. Ik heb de COM-poort en de snelheid ingesteld om overeen te komen met die van de Arduino, heb het toen een paar keer geprobeerd en alles wat op de seriële poort kwam gedumpt in een tekstvak met meerdere regels.

Nadat de waarden waren gelezen, kon ik gewoon de readto & split-functies gebruiken om één metingen van elkaar en van scheidingstekens te isoleren. Deze werden uitgezet op een kaartbesturing en de waarden begonnen op het scherm te verschijnen.

Als u het diagrambesturingselement niet in uw VS-toolbox kunt zien, kunt u het probleem googlen en de oplossing hier vinden (zoek naar antwoord #1): link

Het meetprincipe:

Om het verband te vinden tussen het aantal tellingen en de afstand die de kop aflegt, hebben we de telling op nul gezet, de printerkop met de hand 100 mm verplaatst en de verandering in tellingen waargenomen. Uiteindelijk kwamen we op de volgende verhouding: 1 count = 0.17094mm.

Omdat we de afstand kunnen opvragen en de tijd tussen de monsters kunnen meten, kunnen we de snelheid berekenen waarmee de positieverschuiving plaatsvindt - we kunnen de snelheid berekenen!

Er is een ruwe softwaretiming van 50 ms dankzij TMR0, maar we hebben vastgesteld dat deze timings niet al te nauwkeurig waren. Na wat softwaresnelheidsmetingen ontdekten we zelfs dat de getimede 50 ms helemaal geen 50 ms is. Dit betekende dat de monsters niet met een vast interval werden genomen, dus de snelheidsberekening kon ook geen vaste tijdbasis gebruiken. Toen we dit probleem eenmaal hadden gevonden, was het gemakkelijk om verder te gaan: we namen het verschil in afstand en het verschil in tijd en berekenden de snelheid als D_distance/D_time (in plaats van D-distance/50ms).

Omdat onze vergelijking de snelheid zou retourneren in eenheden van mm/50 ms, moeten we dit ook vermenigvuldigen met 1200 om de afstand te krijgen die het hoofd in één minuut zou afleggen, in [mm/minuut].

Opmerking: de Mach 3 CNC-freesbesturingssoftware definieert de voedingssnelheden in eenheden van [mm/minuut]

Filteren

Vanaf dit punt leken de metingen redelijk nauwkeurig te zijn, maar er was wat ruis op het gemeten signaal. We vermoedden dat dit te wijten was aan mechanische inconsistenties in de as, askoppeling, enz., dus besloten het eruit te filteren, om een mooie gemiddelde waarde te krijgen van wat wordt gemeten.

Fijne aanpassingen aan de software

Om de samplefrequentie en filtersnelheid tijdens runtime te wijzigen, werden schuifbalken toegevoegd - één voor elk. Ook werd de mogelijkheid om de percelen te verbergen geïntroduceerd.

Stap 5: Resultaten

Nadat de hardware- en softwareonderdelen klaar waren, hebben we drie sets metingen uitgevoerd met mach 3 + my software, u kunt de resultaten zien op de bijgevoegde foto's. Latere experimenten toonden een betere nauwkeurigheid, met zowel filter- als samplefrequenties. De grafieken tonen de gemeten snelheid met effen rood, en het gemiddelde met gestippelde blauwe streepjes.

Dat gezegd hebbende, het lijkt erop dat Mach 3 deze snelheidsinstellingen vrij nauwkeurig afhandelt, maar nu weten we het zeker:)

Ik hoop dat je genoten hebt van deze korte instructie over reverse-engineering en het veranderen van water in wijn!

Proost!