gcode errors in USBCNC

[npbosch]

Na alle hulp in mijn vorige draad, heb ik USBCNC nu draaiend.
Ik moet een nieuwe driver gaan kopen en twijfel nog tussen parallel of USB. Via Kevin Damen krijg ik het advies om voor usb te kiezen. Bijna niemand zou nog om een parallele driver vragen.

Ben dus nu aan het experimenteren met de software USBCNC.
Tot nu toe gebruik ik AutoCad -> Ramsgold om toolpath te berekenen en de Gcode te produceren -> KCam om de frees aan te sturen.

De toolpath generator van usbcnc zou mi zeer sterk aan kracht winnen, indien je na het laden van de dxf ieder element apart zou kunnen aanklikken (selecteren) en daar apart een toolpath voor kunnen laten berekenen. Het ene rondje moet bv 3 mm diep en het andere vierkantje 6 mm. Nog mooier zou zijn als dan vervolgens van een te kiezen combinatie van toolpaths een grote gcode file gemaaakt zou kunnen worden. (hoef je dat niet met notepad te doen). AL deze mogelijkheden zitten bv wel in Ramsgold. (Ik geef toe dat is ook een veel duurder product)

Zoals usbcnc nu werkt moet je er rekening mee houden in je cad programma dat je ieder element dat een andere toolpath behoeft op een aparte layer zet. Dat is erg omslachtig naar mijn mening, maar alles went.

Ook tekst frezen gaat niet op de manier zoals ik wil. Na veel experimenteren (voor het doel om panels voor vliegtuigsimulatoren te maken) krijg ik het mooiste resultaat door de verf weg te frezen , dus via parallel of spiraal frezen van dat deel van het werkstuk binnen de letters en dus niet via slotfrezen (wat usbcnc graveren noemt).
Kijk maar wat ik bedoel op bijgevoegd plaatje. De A gaat goed maar de D niet.


Ik kan natuurlijk rams blijven gebruiken (dan spelen bovengenoemde problemen niet meer) maar wanneer ik gcode gegenereerd door rams naar usbcnc stuur dan gaat het alleen goed zolang er niet het commando I of J in voorkomt.
Zodra die erin zit komt de foutmelding
Error: beging radius is niet gelijk aan eind radius

Vervolgens de gcode laten berekenen via usbcnc zelf,(misschien genereert rams wel een gcode dialect dat usbcnc niet aan kan) maar ook die code geeft na laden dezelfde foutmelding.
In Kcam staat ergens een optie I en J code incremental, als ik die niet aanvink, dan is het weergegeven path in kcam ook niet correct. Ik ben echter alle instellingen in USBCNC nagelopen en kan niets vinden dat hier op lijkt.

Heeft iemand een oplossing voor een of meerdere van deze 3 problemen? Met name de laatste is van belang want zo is de USB-weg voor mij niet haalbaar en moet ik voor een nieuwe driver gaan die geschikt is voor de parallele poort. De eerste 2 is te omzeilen door de gcode gewoon door rams te blijven laten doen.

Nu ik toch in het USB deel ben van dit forum: ik neem aan dat de meeste usbcnc gebruikers ook ervaring hebben met cnc en via de LPT. Is de USB weg nu werkelijk zoveel beter?

Met vriendelijke groet

Norbert Bosch

http://home.wanadoo.nl/norbert.bosch/

[Leeuwinga]

Kijk eens bij Deskcnc (http://www.deskcnc.com)
Daar kun je een complete in een keer getekende DXF tekening inlezen
en aansluitend alleen die elementen eruit kiezen welke je wil bewerken.
De bewerking kun je per stuk uitvoeren of koppelen tot een compleet
file waarin alle bewerkingen , en gereedschappen zitten.
Deskcnc werkt via RS232 of via een aangepaste kabel met USB.

[Erik]

In Ramsgold zal toch wel een aanpasbare postprocessor ingebakken zitten?

[Arie Kabaalstra]

Error: beging radius is niet gelijk aan eind radius

als je dat krijgt, zit er meestal een afrondingsfout in de software die de code genereert..

I en J incremental is default, absolute is een mogelijkheid, maar dan moet je Cam software het ook ondersteunen.. en het moet dan ook aangevinkt zijn in USBCNC, anders gaat het de mist in, en krijg je nog meer errors.

zo'n toolpath generator is wel leuk, maar hoort eigenlijk niet in een CNC besturing thuis.. ik ken in elk geval geen enkele professionele besturing waar je een DXF bestandje kan inladen..

als er G-code extern gemaakt wordt, gebeurt dat meestal toch wel "op kantoor".

wat het verschil tussen LPT en USB communicatie betreft.. TIMING.. Windhoos zit continu aan de LPT te rammelen.. en de andere applicaties moeten hun beurt afwachten.. USBCNC stuurt zijn data in pakketjes naar de CPU, waar ze gebufferd worden, en in een steady stream naar de drivers gaan.. als je 2 identieke machines bouwt, en er één op USBCNC laat lopen, en de andere via LPT, dan hoor je duidelijk verschil..

[npbosch]

In mijn cam software (KCam) heb ik inderdaad bij GCode plotting options "I en J code are incremental" aangevinkt.
Als ik dat uit heb staan, geeft ook Kcam weliswaar geen foutmelding maar er wordt bij lange na niet gefreesd wat de bedoeling is.
In USB cnc zie ik niet een dergelijke instelling, waar zou die moeten zitten?

Mijn toolpath generator Ramsgold, heeft wel een postprocessor. Ik heb die inmiddels aangepast dat er niet meer gevraagd wordt om een naam in te voeren (standaard 1000) dat komt dan in de gcode als O1000 op een van de eerste regels. Dat gaf ook een foutmelding in usbcnc.
Maar dat met die I en J problemen los ik zelf niet zo 123 op.

Als ik toch een dedicated pc heb staan bij de frees die niets anders doet dan de cam software laten draaien, wat is dan nog het voordeel?

[Joost]

wat het verschil tussen LPT en USB communicatie betreft.. TIMING.. Windhoos zit continu aan de LPT te rammelen.. en de andere applicaties moeten hun beurt afwachten.. USBCNC stuurt zijn data in pakketjes naar de CPU, waar ze gebufferd worden, en in een steady stream naar de drivers gaan.. als je 2 identieke machines bouwt, en er één op USBCNC laat lopen, en de andere via LPT, dan hoor je duidelijk verschil..

Eh.. USB stuurt gehele pakketten met data, deze worden gebufferd in de USBCNC hardware. De timing wordt dus door de controller gedaan en heeft niks met de verbinding te maken.

De LPT poort fatsoenlijk aansturen kan best; LinuxCNC ( http://www.linuxcnc.org ) stuurt de LPT poort prima aan! Ik gebruik het sinds twee weken en ik vind het geweldig! Ik was eerst 'bang' voor linux maar dat valt reuze mee.
Ontwikkeld door een professioneel team (o.a. motion control experts), open source en GRATIS! Geen extra hardware nodig, hang je drivers aan je printerpoort en je bent klaar.
Je kan er zelfs hexapods e.d. mee aansturen.

Het zal zeker niet slechter klinken dan met USBCNC, een puls is een puls...

[Arie Kabaalstra]

In USB cnc zie ik niet een dergelijke instelling, waar zou die moeten zitten?

in USBCNC setup rechts op het scherm AbsoluteCenterCoords, als je die aanvinkt dan moeten er in je code absolute centerpoint coordinaten staan in plaats van Incrementele ( Incrementeel is default )

Eh.. USB stuurt gehele pakketten met data, deze worden gebufferd in de USBCNC hardware. De timing wordt dus door de controller gedaan en heeft niks met de verbinding te maken.

Klopt, maar Mach bijvoorbeeld, buffert dus niets.

en :

De LPT poort fatsoenlijk aansturen kan best; LinuxCNC ( http://www.linuxcnc.org ) stuurt de LPT poort prima aan!

juistem..
maar zoals ik al eerder schreef:

Windhoos zit continu aan de LPT te rammelen..

als je een ander OS dan Windhoos hebt, dan is't goed mogelijk dat de LPT communicatie goed werkt..
een tweede probleem met LPT is echter.. bij modernere PC's zit er al niet eens meer een LPT aan, en als er al een aanzit, dan heeft ie niet de ouderwetsche 5V, maar iets van 3.3, waardoor je signaal verlies krijgt..

Toegegeven.. dat probleem is er soms ook bij USBCNC, met modernere Laptops die ook "te weinig prik"op de USB hebben, maar da's met een gevoedde USB-HUB van een paar euri's wel op te lossen..

[npbosch]

OK , ik ben wel overtuigd dat usb technisch beter is. Dus ga er alles aan doen om USBCNC mijn gcode te laten slikken.
Ik heb die optie absolute center coord aangevinkt (en op geslagen) maar ook dat maakt geen verschil.

Heb net met een proggie dfx2gcode , gcode gegenereerd , dat werkt wel. Denk dus dat het probleem in mijn toolpath generator zit. (de post processor van Ramsgold).

gr

Norbert

[Arie Kabaalstra]

Ik heb die optie absolute center coord aangevinkt (en op geslagen) maar ook dat maakt geen verschil.

die optie Incrementeel of absolute Center coordinaten maakt ook in wezen geen verschil, 't enige is, dat het makkelijker met de hand programmeert als je absolute coordinaten hebt, meestal staan deze in tekeningen wel aangegeven, voor incrementele waarden moet je dan gaan rekenen, met kans op fouten..

eigenlijk en eerlijk gezegd weet ik niet wat de programmeur dacht toen hij de norm voor RS274D G-code vastlegde.
Wie verzint het in 's hemelsnaam om 't hart van een cirkelboog ten opzichte van het beginpunt van die radius op te geven?.. (ok.. soms kan het handig zijn.. en Heidenhain taal kan zowel absoluut als incrementeel aan, zelfs door elkaar)

als ik cirkels programmeer, dan doe ik dat meestal NIET Met I en J, maar met G2/G3 X...Y... R da's veel makkelijker.. en als je een Postprocessor hebt die volgens die syntaxis cirkelbogen kan uitgeven, dan ben je van veel ellende af.... ( als de boog een ietsje te groot is, merk je daar niets van.. 't middelpunt verschuift dan ietsje, maar daar zie je niets van terug.. )

't komt vaker voor dat de afrondingen in de diverse software pakketten bij gecompliceerde contouren de boel verstieren.. als je met aansluitende bogen tussentijds afrondt, dan begin je al met een afwijking aan de volgende boog, en na 3 bogen val je buiten de tolerantie van de besturing, en KLAP!. ERROR..
(T-Cam was hier berucht om, in combinatie met de oudere AutoCad releases)

[npbosch]

De problemen zijn opgelost

Mbt de letters:
door wat te spelen met de parameters: connect tolerance, calculation accuracy en close path , heb ik mijn abc.dfx (waar alle letters op staan) al bijna foutloos door usbcnc heen gestuurd. De letters die toch nog problemen gaven heb ik overgetrokken met polyline (zijn nu dus helemaal dicht) en voorzover dat getest is tot nu toe werkt dat.

Het was toch de parameter bij abs center coordinated. Ik had hem aan staan maar hij moet uit bij mij. En het werkte pas na een keer afsluiten en weer opstarten.
He he , toch nog een vruchtbaar avondje geworden. Knoop doorgehakt ga dan toch voor de usb driver.

Dank voor alle opmerkingen en hulp.

groet

Norbert Bosch

[Rob65]

Norbert,

gefeliciteerd met de keuze voor USBCNC.
Ik ben zelf zojuist overgestapt van EMC (linuxcnc) naar USBCNC.
Neem wel de CPU-V4 module van USBCNC, daar heb je in de toekomst meer plezier van (kan 3 keer zo snel stappen dan cpu V3).

Systemen die de stappenmotoren via de printerpoort besturen zijn over het algemeen langzamer dan de CPU-v4 van USBCNC. Daarnaast vind ik die simpele USB aansluiting wel wat hebben; het is erg makkelijk om even snel een andere PC aan te sluiten.

Let wel even op de aanwijzingen voor installatie: ik had de boel even los op tafel getest en dat lijkt te werken maar af en toe treden er vreemde fouten op. Nu ik alles netjes in een metalen kast heb gebouwd werkt alles vlekkeloos - de machine draait nu echt perfect.

Oja, ik kan het niet laten even op Arie te reageren:

zo'n toolpath generator is wel leuk, maar hoort eigenlijk niet in een CNC besturing thuis.. ik ken in elk geval geen enkele professionele besturing waar je een DXF bestandje kan inladen..

Helaas ... er komen steeds meer fabrikanten van CNC besturingen die de mogelijkheid bieden om direkt vanaf een DXF te frezen. Geen moeilijke toestanden meer met aparte CAM software en oversturen van de data via een serieële poort of netwerk maar gewoon direkt de DXF inlezen en freesbanen bepalen.
Gebruikers zijn hier dol op

Groeten,

Rob

[rsemotion]

[

zo'n toolpath generator is wel leuk, maar hoort eigenlijk niet in een CNC besturing thuis.. ik ken in elk geval geen enkele professionele besturing waar je een DXF bestandje kan inladen..

Eugh arie, de iTNC530 van heidenhain met SmartNC kan je zo een DXF in proppen