Centroid Community CNC Support Forum

Machine has been working well for over a year with no hardware changes and decided to do a bunch of work with a custom VCP configuration.
All went well but then noticed my "reset home" function no longer works properly. It immediately complains that the X axis home is not set (see screen shot), and if I press cycle start, will finish homing Z, then complain as it tries to home X, and if I press cycle start, will finish homing X, and then do the same for the paired Y axis. Except at the end it does not actually set the machine coordinates to 0.

I have tried having the wizard recreate the homing file but that results in no change. I have re-confirmed the proper paired axis configuration.
I did notice, oddly, that if I try to move the "Pair Axis" button in the VCP it will re-create it in the default location even though the manual claims you can move it. Since I originally tried to remove it maybe this is related, though now its back and I still have my problem. Just mentioning this since it doesn't operate as explained and it seems *somewhat* related.

I can't figure out what the heck is going on, or why re-configuring the VCP would mess up my homing, particularly when I didn't touch which skin event the reset home button calls, or the macro that skin event is tied to.

Anybody have a similar experience? Wizard screenshots, error screenshot, and report file attached. HUGE thanks for any help.

Can you go back to the original VCP config? Sometimes the answer is REBOOT

Not easily. Also then what? Feels like it would be good to learn what happened here so it doesn't happen again. IE I can't find the problem but would love to learn from someone who can!

Could try to restore an earlier report before you changed the VCP. (Create a current report before doing this). If it solves your issue, could send us both reports (before and after) to compare so can look at differences and give us a better idea what changed and ect.

Yep, that's part of my next step. I changed buttons around, added a few new macros for homing individual axis, and mapped them. Nothing that directly touched the "homing" macro but obviously something did, tangentially.
Unless somebody has a better idea, will back out to my last report and even just add new things one by one until it breaks again to see what it was...
But still hoping somebody sees the above error and has an idea why a system-generated homing macro would be checking for a homed axis when the whole point of that macro IS that it homes that axis....

okay, well I fixed it though I'm not sure what broke it to begin with.
I restored the files and a report from right before I messed with all of this and noticed that it still exhibited the error mentioned above. This should not be given that all of the settings were reset. But I noticed that because the restore only replaces settings and adds or overwrites files *but does not delete them*, I still had 5 new macro files I had made to do various new things in my VCP. On a hunch, I copied those to a safe place and deleted them, and lo and behold, homing works again. Through a series of tests, I discovered the one (and only one) causing homing not to work was a new mfunc26.mac file I had associated with skin event #5. I took that exact macro file, saved it instead as mfunc77.mac, associated it with skin event 15 instead, changed by button to reflect that new skin event, and all works perfectly.

I ran it over and over in every way I could think to, homing, restarting, moving around, reseting axis, and it definitely works.

I have NO idea why making that macro (which resets an axis and complains if one isn't homed, BTW) mfunc26.mac and associating it with skin event 5 made it run during homing. I'm clearly missing something here. But there was no macro before with that name and nothing associated with skin even #5 before, so it's more than baffling.

Anyone know if there is something special about that event or macro?!

M26 is an internal file that sets the machine zero position. There are only certain "M" commands that are available to the user. Look em up

I see that now in the master Centroid Mill manual. Still pretty new at this and missed that some M-numbers are reserved even if there is no existing mfuncXX file to match it. Thanks for that info, and that explains my problems!