[EdingCNC 5.3] MCA niet actief tijdens subroutines

[Caesar]

weer een vraag waar ik tegen aanloop;

ik gebruik op dit moment EdingCNC 5.3 en de MCAguard aan en alle softlimits ingesteld. Wanneer een willekeurige file ingeladen wordt, wordt netjes aangegeven dat deze buiten de MCA valt en er dus niet verder gegaan kan worden.

Echter, wanneer ik een subroutine aanroep via user_xx, dan heeft de machine geen enkel probleem om buiten de MCA coordinaten te proberen te gaan.

Bijvoorbeeld;

MCA afmetingen/instellingen zijn: X neg = 0, X pos = 770, Y neg = 0, Y pos = 660. Als ik in de MDI direct G1 F500 G53 Y-5 aanroep, krijg ik terecht een foutmelding dat ik buiten de MCA probeer te komen.

Roep ik echter dezelfde code aan (om te testen) via een subroutine, dan gaat de machine daadwerkelijk naar Y-5 en krijg ik een foutmelding op het moment dat de homing sensor aangeroepen wordt.

Uiteindelijke doel is om een kruislaser 0 naar spindel nul om te zetten, maar het kan zijn dat als dit omgerekend wordt, de spindel 0 buiten de MCA valt (slecht werkstuk opspannen uiteraard). Ik kan in de macro uiteraard ondervangen dat de uitgerekende machine coordinaten niet negatief mogen worden, maar mij lijkt juist dat dit ondervangen zou moeten worden door EdingCNC. Dit is dan ook een bredere vraag; klopt het dat MCA coordinaten en softlimits niet actief zijn bij aanroepen van subroutines? Belangrijk om te weten namelijk!

Iemand hier een visie op?

[Kars-cnc]

Het klopt dat de MCA en TCA limieten niet gelden binnen een macro. Dat is ook niet heel raar want macro's worden vaak gebruikt voor zaken als de MCA limiet(schakelaar) zoeken. Daarvoor moet de macro wel over de limiet heen kunnen gaan. Hetzelfde voor de TCA limieten, normale G-code mag niet binnen de 'Tool Change Area" komen maar de Tool Change Macro moet dat wel kunnen om z'n werkte kunnen doen.

Waarschijnlijk kun je binnen een macro met het MCA-on of het TCA-on commando zorgen dat die limieten weer gerespecteerd worden, maar daar heb ik geen ervaring mee.

Ik ben hier ook door schade en schande achter gekomen... Dat soort dingen gaan bij mij meestal mis als ik de macro nog aan het ontwikkelen ben (laatst nog ervaren wat M3 binnen een 3D-probe macro doet ) als de macro eenmaal doet wat het moet doen is het meestal geen probleem meer.

[Caesar]

Ja ik had al zitten spelen met MCAguard on, maar daar lijkt weinig mee te gebeuren. Misschien nog wat meer testen, maar als ik 'MCAGuard on' in de sub zet gaat hij het alsnog uitvoeren.

Probleem is dat deze macro voor iemand anders gaat zijn en dynamisch is (nullen m.b.v. een kruislaser). M.a.w. het moet wel foolproof zijn.