Graveren van nummers Heidehain TNC155

[alexbrem]

bij deze
je moet alleen FMAX veranderen in F9999
en de programma naam veranderen in cijfers

[M Theunissen]

Superrr Alex.
Hier kan ik mee werken, hartelijk dank!
Rob65 gaat in het weekend als hij de tijd ervoor vindt nog even knutselen om een software programma te schrijven voor het omzetten van ISO --> Klartekst. Dit zal niet alleen mij maar ook andere mensen enorm veel handelingen en tijd kunnen schelen.

Groetjes Mark

[Rob65]

En het gaat mij ook een hoop tijd schelen want ik heb zelf ook wat tools die alleen G code genereren.
Het wordt dan ook vooral een tool om het meeste werk uit handen te nemen (het vertalen van G1/2/3 en T en M codes) om de basis functies van de machine te kunnen gebruiken.

Is ook meteen een vingeroefening na een jaartje geen Qt meer geprogrammeerd te hebben

[Rob65]

Nee,

ik ben het niet vergeten
Afgelopen weekend ben ik heel even aan het programmeren geslagen en het begin is er: het programma leest G-code bestanden en vertaalt deze (deels) in KlarTekst. Maar er gaan nog wat gekke dingen mis zodra er een onbekende G-code of een vreemd formaat in de file staat.
Nog heel even geduld dus ...

[M Theunissen]

Fijn om te horen dat je er al aan geklust hebt, ik wacht met geduld in spanning af.
Wanneer je weer verder bent dan hoor ik het graag.

Groet Mark

[Rob65]

Het knutselen is bijna aan z'n eind gekomen.
Ik heb hier nu een heel simpele editor waarin ik G-code in kan lezen en met één druk op de knop KT van kan bakken.
Wel nog met flink wat beperkingen: er zitten nu nog geen M-codes in, de G-code parser laat maar 1 M code of G code per regel toe en er zit maar weinig controle op juiste code. Ook kijk ik niet naar dingen als G90/G91, G21 en noem maar op. Ik ga er van uit dat er alleen gefreesd wordt in het XY vlak (G17) met de Z as als spindel-as, dat coordinaten absoluut zijn (G90) en dat de afmetingen altijd in millimeters zijn (G21).

Voor de code die Mark stuurde die hij met Engrave gemaakt had geen probleem.
Maar er is nog wel een probleempje: Als in de ISO code in EdingCNC open ziet alles er perfect uit, maar op mijn TNC426 zitten er plots wat vreemde cirkels in:


Zo te zien begint dit ergens halverwege de laatste letter. Zie hier de plek waar het fout gaat:


Ik heb de ISO code langs de G-code gelegd en het lijkt alsof de coordinaten gelijk zijn. Daar moet ik morgen dus nog eens even in duiken. Misschien komt het wel gewoon omdat ik geen R.. op heb gegeven en ik ook geen tool heb gezelecteerd - dat is een stukje functionaliteit wat er nog bij moet.

Ik laat in ieder geval wel alle niet ondersteunde G/M etc. codes als commentaar in het programma staan, dan kan je zelf beslissen wat je er mee doet.

Het is nu dus nog wel heel basic en er mist ook nog het een en ander aan foutmeldingen of waarschuwingen.
Ik heb er al wel twee "BLK FORM" regels in staan met een berekende werkstuk-afmeting (Zmax = 0, alle andere waarden worden berekend) zodat de code met een grafische afbeelding te controleren is.

Ik moet dus nog even sleutelen om de boel redelijk hufterproof te krijgen en wat meer commando's in te bouwen. Daarna mag Mark er zijn tanden ook eens inzetten voordat ik de rest van het forum met mijn bugs ga pesten

Voor wie wil zien hoe de code vertaald wordt als bijlage zowel de ISO (.i) als de Klartekst (.h) bestanden in een zip bestand. Het is eigenlijk heel simpel: G0 wordt L .... FMAX, G1 wordt L ... F..., G2 is CC IX... IY.... met C DR- en G3 idem maar dan met DR+

[hugo stoutjesdijk]

Ik zie wat regels waar deltaX en deltaY beide nul zijn ( tussen regel 1045 en 1046 b.v.) daar zijn besturingen al niet blij mee ( kun je n.l. geen richtingsvector bepalen, dus gaat de radiuscomp op tilt. Dat is hier gelukkig geen probleem )
Net als die 1e 3 Z-regels.
Maar als je zo'n regel met een Cirkel doet, heb je dikke kans dat ie zegt begin eindpunt gelijk, dat is een cirkel van 360 graden.
Eigenlijk een slechte PP dus.( die het orgineel gemaakt heeft ) Volgens mij kun je in CamBam ook opgeven dat ie bewegingen kleiner dan ... uitfiltert, Dat zou hier ook moeten gebeuren.
Ik zou ook niet met 4 cijfers achter de komma gaan werken.
( nog sterker, dit soort werk doe ik altijd met slechts 2 cijfers achter de komma, voor een TNC355 met beperkt geheugen telt elke byte )

Beter is niet 1:1 vertalen, maar NC regels inlezen, en volgens jouw regels opnieuw uitvoeren, in jouw gewenste formaat, dan is zo'n nul weglengte regel er zo tussen uit.

[Rob65]

Hugo

bedankt, daar had ik zelf nog helemaal niet naar gekeken.
Het gebruik van minder decimalen staat op het lijstje, net als het uitfilteren van 0 lengte bewegingen.

Volledige cirkels is ook een goede tip, daar kunnen niet alle besturingen mee overweg. Daar zou ik op z'n minst een waarschuwing voor willen geven.
vanmiddag in de trein maar weer eens even wat dingen aanpassen en dan vanavond nog eens aan de machine hangen.
Ja, ik heb ondertussen ook iTNC op de laptop staan, dan hoef ik niet steeds naar de werkplaats te lopen om iets te bekijken, maar veel verder dan installeren ben ik nog niet gekomen.

[hugo stoutjesdijk]

Vanmiddag in de trein maar weer eens even wat dingen aanpassen en dan vanavond nog eens aan de machine hangen.

Lekker dat je dat in de trein kunt, vroeger toen ik nog met de trein reisde kon ik die tijd alleen nuttig gebruiken met alle vakliteratuur doornemen ( ook niet verkeerd, om een beetje bij te blijven )
Die 15 meter die ik nu moet lopen is net te weinig om nog wat op te steken.

( ik zou er maar van uit gaan dat die CAM pakketten in ieder geval niet met volle cirkels kunnen omgaan (lees aanleveren), dat dat dus een beweging <0.001 is )