G2 code probleem

Moderator: Moderators

Plaats reactie
Tosse
Berichten: 5
Lid geworden op: 27 aug 2008 00:00
Locatie: Leuven - Belgie

G2 code probleem

Bericht door Tosse » 22 dec 2018 22:22

Hey lezers,
ik ben vandaag een probleem tegengekomen met mijn cambam.
Wanneer ik een stuk invoer en hem hierop een G-code laat maken krijg ik in mach 3 een vreemde uitkomst.
Na zoeken kom ik uit op 1 regel die hij verkeert opneemt.
Het gaat over een G2 code waarbij hij als eindpunt enkel een Y coordinaat opgeeft.
Weet iemand hoe ik dit moet aanpassen in cambam zodat hij dit wel correct opstelt voor mach3?

hieronder het stukje code waarover het gaat:

G1 X151.6267 Y89.4486
G2 Y89.4487 I1602.5306 J-542.8064
G2 X154.6209 Y98.2095 I1602.5306 J-542.8066

Alvast bedankt voor de hulp, ik geraak er zelf niet aan uit. Ik gebruik mijn frees nu al lange tijd, maar dit is de eerste keer dat ik dit probleem heb.
Misschien heb ik per ongeluk ergens een setting aangepast.

Gebruikersavatar
hugo stoutjesdijk
Donateur
Berichten: 6734
Lid geworden op: 02 mar 2011 17:04
Locatie: elst (u)
Contacteer:

Re: G2 code probleem

Bericht door hugo stoutjesdijk » 22 dec 2018 22:47

Dan moet je in de format regels van de postprocessor achter de G2 en G3 regels de $_x vervangen voor $x (en ook voor de y)
$x, $y, $z, $a, $b, $c
$i, $j, $f, $r, $p, $q
$_x, $_y, $_z, $_a, $_b
$_c, $_i, $_j, $_f, $_r
$_p, $_q
These macros insert the parameters used in common Gcode move operations. If an underscore (_) prefix is used, these parameters are treated as modal. That is they will only be output if the current value has changed. Omitting the underscore will force the parameter to be always output.

These macros will include the register code as well as the value, for example $x = X1.23
Ik ben voor meer techniek op school, maar dan wel vanaf groep 1 basischool.

Tosse
Berichten: 5
Lid geworden op: 27 aug 2008 00:00
Locatie: Leuven - Belgie

Re: G2 code probleem

Bericht door Tosse » 23 dec 2018 08:41

hugo stoutjesdijk schreef:
22 dec 2018 22:47
Dan moet je in de format regels van de postprocessor achter de G2 en G3 regels de $_x vervangen voor $x (en ook voor de y)
$x, $y, $z, $a, $b, $c
$i, $j, $f, $r, $p, $q
$_x, $_y, $_z, $_a, $_b
$_c, $_i, $_j, $_f, $_r
$_p, $_q
These macros insert the parameters used in common Gcode move operations. If an underscore (_) prefix is used, these parameters are treated as modal. That is they will only be output if the current value has changed. Omitting the underscore will force the parameter to be always output.

These macros will include the register code as well as the value, for example $x = X1.23

Super, bedankt voor de reactie.
Maar hoe komt het dat bij de MACH 3 ppostprocessor in cambam dit niet juist staat?
OF hem ik manueel iets gewijzigd in mach3 waardoor hij daar moeilijk mee doet?

bijgevoegd:
Ondertussen dit aangepast en ik krijg nu de X coordinaten er ook bij.
Maar blijkbaar is dit niet het probleem voor mach 3.
Het resultaat blijft hetzelfde. Hij doet blijkbaar moeilijk over dat commando
Afbeelding
dit is in mach 3 het resultaat.

dit is een NC-viewer het resultaat
Afbeelding

De regel waarover het gaat is dus
G1 X210.6267 Y99.4486
G2 X210.6267 Y99.4487 I1602.5306 J-542.8064
G2 X213.6209 Y108.2094 I1602.5306 J-542.8066
Waarom is er een verschil in de NC-viewer, waarbij dit wel perfect is en in mach3 een grote cirkel getekend staat voor dat commando.
Ik weet het niet meer...

Gebruikersavatar
hugo stoutjesdijk
Donateur
Berichten: 6734
Lid geworden op: 02 mar 2011 17:04
Locatie: elst (u)
Contacteer:

Re: G2 code probleem

Bericht door hugo stoutjesdijk » 23 dec 2018 09:58

ER zitten een paar vreemde dingen in het programma, maar zonder meer achtergrond info is er lastig uit te komen.

Code: Selecteer alles

G1 X210.6267 Y99.4486
G2 X210.6267 Y99.4487 I1602.5306 J-542.8064
G2 X213.6209 Y108.2094 I1602.5306 J-542.8066
Ten eerste vind ik het vreemd dat je met 4 cijfers achter de komma werkt, lijkt er op dat het eigenlijk een inch pp is. (maar dat mag verder het probleem niet zijn)
Die eerste G2 heeft geen X omdat cambam ziet dat die gelijk is aan het startpunt, en dan is ie dus modaal ongewijzigd en hoeft niet opnieuw geschreven.
De bijbehorende Y wijkt maar 0.0001 af van z'n voorganger, is dus eigenlijk ook hetzelfde (was me eerst niet opgevallen) en dat betekend dat het een volle cirkel is, dat is nu eenmaal de afspraak in G-code land, dat de simulatie niet begrijpt dat die 100 nanometer helemaal niets is, en denkt daar nog even een cirkel in te frotten is de fout van de NC viewer. (die werkt puur theoretisch, de machine besturing houd ook rekening met afrondingsfouten en minder dan 1 mu is dus start en eindpunt gelijk = volle cirkel)
En ik denk dat jouw machine geen 3 meter is, dus misschien heeft mach3 door dat ie over z'n limits heen gaat komen en geeft een foutmelding. (of je had alleen nog maar op het scherm gekeken ?)

Ik zou de [minimum arc length] op 0.1 zetten, dan worden alle cirkel korter dan 0.1 mm recht lijnstukjes, dan komt dit probleem denk ik niet meer voor, en merk je verder niets van.
En tegelijk ook de [Number format] 0.### maken zodat er nog maar 3 cijfers achter de komma staan. ( ik neem aan dat je niet de illusie hebt dat die 1mu ook echt iets doet, dus nog eens een faktor 10 kleiner is overdreven)
Wanneer je alleen die 3 cijfers achter de komma aanpast heeft de PP van CAMBAM misschien al door dat het geen cirkel is, CAM pakketten doen niet aan volle cirkels, besturingen wel.
Maar dan nog zou ik die minimum arc length wat groter zetten.

Ja, en waarom al die PP's nooit standaard goed staan is me ook een raadsel, ik heb even naar SW-CAM gekeken, als je zie welke prehistorische meuk die in de PP hebben staan (en nog fout ook), waarschijnlijk bedoeld om te kunnen zeggen dat er voor een heleboel machines PP bijzitten, maar ondertussen betaalde support kunnen leveren voor de klant die net weer iets anders nodig heeft.
Dat is ook de reden dat ik altijd weer terugkom op de 'noodzaak' om je toch een beetje te verdiepen in de basic G-codes, en ook een blik werpen in de PP is helemaal niet zo lastig, zoals ik ook ooit op een CNC-zone dag heb laten zien.
Ik ben voor meer techniek op school, maar dan wel vanaf groep 1 basischool.

Grafjan
Berichten: 203
Lid geworden op: 16 aug 2018 23:01
Locatie: Tilburg

Re: G2 code probleem

Bericht door Grafjan » 23 dec 2018 10:08

Dat heb ik ook weleens gehad,bij mij lag het toen aan het feit dat de ene postprossor een G91.1 uitgaf en de andere niet.

Tosse
Berichten: 5
Lid geworden op: 27 aug 2008 00:00
Locatie: Leuven - Belgie

Re: G2 code probleem

Bericht door Tosse » 23 dec 2018 12:07

hugo stoutjesdijk schreef:
23 dec 2018 09:58
ER zitten een paar vreemde dingen in het programma, maar zonder meer achtergrond info is er lastig uit te komen.

Code: Selecteer alles

G1 X210.6267 Y99.4486
G2 X210.6267 Y99.4487 I1602.5306 J-542.8064
G2 X213.6209 Y108.2094 I1602.5306 J-542.8066
Ten eerste vind ik het vreemd dat je met 4 cijfers achter de komma werkt, lijkt er op dat het eigenlijk een inch pp is. (maar dat mag verder het probleem niet zijn)
Die eerste G2 heeft geen X omdat cambam ziet dat die gelijk is aan het startpunt, en dan is ie dus modaal ongewijzigd en hoeft niet opnieuw geschreven.
De bijbehorende Y wijkt maar 0.0001 af van z'n voorganger, is dus eigenlijk ook hetzelfde (was me eerst niet opgevallen) en dat betekend dat het een volle cirkel is, dat is nu eenmaal de afspraak in G-code land, dat de simulatie niet begrijpt dat die 100 nanometer helemaal niets is, en denkt daar nog even een cirkel in te frotten is de fout van de NC viewer. (die werkt puur theoretisch, de machine besturing houd ook rekening met afrondingsfouten en minder dan 1 mu is dus start en eindpunt gelijk = volle cirkel)
En ik denk dat jouw machine geen 3 meter is, dus misschien heeft mach3 door dat ie over z'n limits heen gaat komen en geeft een foutmelding. (of je had alleen nog maar op het scherm gekeken ?)

Ik zou de [minimum arc length] op 0.1 zetten, dan worden alle cirkel korter dan 0.1 mm recht lijnstukjes, dan komt dit probleem denk ik niet meer voor, en merk je verder niets van.
En tegelijk ook de [Number format] 0.### maken zodat er nog maar 3 cijfers achter de komma staan. ( ik neem aan dat je niet de illusie hebt dat die 1mu ook echt iets doet, dus nog eens een faktor 10 kleiner is overdreven)
Wanneer je alleen die 3 cijfers achter de komma aanpast heeft de PP van CAMBAM misschien al door dat het geen cirkel is, CAM pakketten doen niet aan volle cirkels, besturingen wel.
Maar dan nog zou ik die minimum arc length wat groter zetten.

Ja, en waarom al die PP's nooit standaard goed staan is me ook een raadsel, ik heb even naar SW-CAM gekeken, als je zie welke prehistorische meuk die in de PP hebben staan (en nog fout ook), waarschijnlijk bedoeld om te kunnen zeggen dat er voor een heleboel machines PP bijzitten, maar ondertussen betaalde support kunnen leveren voor de klant die net weer iets anders nodig heeft.
Dat is ook de reden dat ik altijd weer terugkom op de 'noodzaak' om je toch een beetje te verdiepen in de basic G-codes, en ook een blik werpen in de PP is helemaal niet zo lastig, zoals ik ook ooit op een CNC-zone dag heb laten zien.
Bedankt. dit was inderdaad het probleem.
Kan je goede literatuur aanraden voor me te verdiepen in de G-code taal?

Gebruikersavatar
hugo stoutjesdijk
Donateur
Berichten: 6734
Lid geworden op: 02 mar 2011 17:04
Locatie: elst (u)
Contacteer:

Re: G2 code probleem

Bericht door hugo stoutjesdijk » 23 dec 2018 13:06

Misschien kom je hier wat verder mee:
https://drive.google.com/file/d/1dDtjtr ... sp=sharing
https://drive.google.com/file/d/1ZPYc6U ... sp=sharing

Is niet direct als uitleg bedoeld, maar als plaatjes bij het praatje (op CNC-zone dag) en verder is voorlopig G0, G1, G2, G3 en wat standaard dingetjes F, S, M3 M5 voldoende denk ik.
Maar kijken wat er in je G-code staat wat de PP aanmaakt, uitzoeken wat die codes allemaal doen is natuurlijk een goed begin.
Ik ben voor meer techniek op school, maar dan wel vanaf groep 1 basischool.

Plaats reactie