Ik heb een Macro in Eding waarin ik een pocket kan frezen als een spiraal. Dit is dus een constante beweging waarbij alleen de eerste en de laatste gang een afwijkende snedediepte hebben. Dit werkt erg goed en ik gebruik hem ook zeer regelmatig.
Echter nu valt het mij op dat de machine even een kleine hapering geeft bij het uitkomen van de "while" functie in de code. Het is nauwelijks te zien en in het werkstuk zie ik het eigenlijk ook niet terug. Maar als het eenmaal is opgevallen ga je erop letten en gaat het je storen. Dit doet hij alleen na deze functie, alle andere regels lopen naadloos in elkaar over.
Hieronder een stukje van de code, dit stukje zorgt ervoor dat de frees naar de gewenste Z-diepte gaat en als deze bereikt is nog een extra circel maakt om de laatste gang compleet te maken. De hapering gebeurt na de endwhile.
In linuxcnc doe ik het op een andere manier maar ook daar gaat de spiraal naar beneden vloeiend maar houd even in voor hij de cirkel op de bodem/zelfde hoogte maakt.
Ik zie geen rare dingen, #64 is je gewenste einddiepte en #37 is je step ?
Met hapering bedoel je dat de machine even niets doet dus stil staat op de plaats niet dat er een beweging is neem ik aan ?
Een while lus evalueren en skippen kost altijd een paar processor cycli extra maar dat zou eigenlijk niet mogen opvallen daar zou het tekort voor moeten zijn.
Wat ik me kan voorstellen is dat het met Edings look ahead algoritme te maken kan hebben. Deze kan alleen vooruit kijken en gaat er dus vanuit dat de loop door gaat, als deze dan niet door gaat moet hij deze info "dumpen" en kijken waar het programma verder gaat. Dat is het enigste dat me te binnen schiet dat wellicht (hypothese) optreed.
Ik zou het moeten simuleren om te kijken wat er gebeurt, wat doet de simulatie van Eding ?
Sven schreef: ↑27 mei 2021 09:32
Als ik het goed begrijp maak je hier een gat mee?
In linuxcnc doe ik het op een andere manier maar ook daar gaat de spiraal naar beneden vloeiend maar houd even in voor hij de cirkel op de bodem/zelfde hoogte maakt.
Ik maak er pockets mee, meestal als er al een gat in zit. Wel typisch dat het bij linux hetzelfde doet.
Kjelt schreef: ↑27 mei 2021 09:40
Ik zie geen rare dingen, #64 is je gewenste einddiepte en #37 is je step ?
Met hapering bedoel je dat de machine even niets doet dus stil staat op de plaats niet dat er een beweging is neem ik aan ?
Klopt, maar wel maar een fractie van een seconde.
Kjelt schreef: ↑27 mei 2021 09:40
Een while lus evalueren en skippen kost altijd een paar processor cycli extra maar dat zou eigenlijk niet mogen opvallen daar zou het tekort voor moeten zijn.
Wat ik me kan voorstellen is dat het met Edings look ahead algoritme te maken kan hebben. Deze kan alleen vooruit kijken en gaat er dus vanuit dat de loop door gaat, als deze dan niet door gaat moet hij deze info "dumpen" en kijken waar het programma verder gaat. Dat is het enigste dat me te binnen schiet dat wellicht (hypothese) optreed.
Ik zou het moeten simuleren om te kijken wat er gebeurt, wat doet de simulatie van Eding ?
Dat klinkt aannemelijk. Alleen is er dan niets aan te doen denk ik?
In de simulatie zie ik het ook, dat was me eerder nog niet opgevallen maar daar zie je het idd ook terug.
bartL schreef: ↑27 mei 2021 10:28
Dat klinkt aannemelijk. Alleen is er dan niets aan te doen denk ik?
In de simulatie zie ik het ook, dat was me eerder nog niet opgevallen maar daar zie je het idd ook terug.
Als je het in de simulatie ook ziet dan zit het inherent in het algoritme van Eding. Je zou ze een mail kunnen sturen of dit bekend is.
Wat is exact het bij-effect waar je last van hebt ?
Als je het niet in het werkstuk ziet lijkt het me niet erg. Mocht je het wel zien dan misschien de frees iets naar het center terug bewegen voor de endwhile statement maar dat kost je dan meer tijd want iedere loop zal hij dit doen.
Kjelt schreef: ↑27 mei 2021 10:41
Als je het in de simulatie ook ziet dan zit het inherent in het algoritme van Eding. Je zou ze een mail kunnen sturen of dit bekend is.
Wat is exact het bij-effect waar je last van hebt ?
Als je het niet in het werkstuk ziet lijkt het me niet erg. Mocht je het wel zien dan misschien de frees iets naar het center terug bewegen voor de endwhile statement maar dat kost je dan meer tijd want iedere loop zal hij dit doen.
Waar ik last van heb is dat ik het niet wil zien.
Uit het werk bewegen vind ik geen optie, het hele doel van deze macro is juist dat ik de hele pocket in 1 beweging kan frezen. Ik dacht altijd dat die welbekende kabouters veel harder konden rennen dan wat ik met mijn ogen kon zien, maar dat is in dit geval dus niet zo. Misschien inderdaad eens een mailtje naar Bert...
Misschien heeft het te maken met je instellingen in de setup links-onder bij Trajectory setup en dan met name de LAF angle, Interpolation time en fifo time.
't is niet een specifiek "Eding Dingetje" ik heb het bij Heidenhain besturingen ook gezien.. zelfs een hapering tussen 2 aansluitende cirkelbogen in een met CAM gegenereerd programma.
Ik kom het ook tegen in bepaalde cycli.. maar ach..als het resultaat is wat ik er van verwacht.. Boeie.. bovendien... meestal sta ik toch niet met mijn neus tegen het glas te kijken hoe de machine bezig is.. 'k heb of een pot koffie in mijn takken, of ik sta bij een andere machine code in te kloppen..
ruudpg schreef: ↑27 mei 2021 13:15
Misschien heeft het te maken met je instellingen in de setup links-onder bij Trajectory setup en dan met name de LAF angle, Interpolation time en fifo time.
Dat is nieuw voor me. Hoe zou ik dit dan in moeten stellen volgens jou?
