Centroid Community CNC Support Forum

The supported method of gantry "autosquare" requires that the slave switch triggers first. Having the master trigger first could result in erroneous results.

Gary Campbell wrote: ↑Tue Jul 09, 2019 9:27 am The supported method of gantry "autosquare" requires that the slave switch triggers first. Having the master trigger first could result in erroneous results.

But is there a way to change the fact that it wipes out travel limit when that happens? I wouldn't want my employe to just reset the machine, manually push the master side and run a machine with no soft limits...

3d_low wrote: ↑Tue Jul 09, 2019 9:29 am

Gary Campbell wrote: ↑Tue Jul 09, 2019 9:27 am The supported method of gantry "autosquare" requires that the slave switch triggers first. Having the master trigger first could result in erroneous results.

But is there a way to change the fact that it wipes out travel limit when that happens? I wouldn't want my employe to just reset the machine, manually push the master side and run a machine with no soft limits...

You have to set up autosquare as it was designed to operate Franco did a video on it.
Please see if you can recreate the issue and post before report (with your soft limits set) and after report (as you say, when the soft limits disappear)

martyscncgarage wrote: ↑Tue Jul 09, 2019 10:01 am

3d_low wrote: ↑Tue Jul 09, 2019 9:29 am

Gary Campbell wrote: ↑Tue Jul 09, 2019 9:27 am The supported method of gantry "autosquare" requires that the slave switch triggers first. Having the master trigger first could result in erroneous results.

But is there a way to change the fact that it wipes out travel limit when that happens? I wouldn't want my employe to just reset the machine, manually push the master side and run a machine with no soft limits...

You have to set up autosquare as it was designed to operate Franco did a video on it.
Please see if you can recreate the issue and post before report (with your soft limits set) and after report (as you say, when the soft limits disappear)

I will later today. Thanks

So i figured out the issue. Turns out this was an mechanical one that happened during assembly.

My table was too large compared to the X axis gantry by 2mm. So basically the gantry plates were "tapered" from top to down. This was putting pressure on the ballscrew nut and was causing the vibration since the nut and the screw were parallel but not collinear. I've readjusted the table extrusions lengths and redid some test. The whole machine is a lot smoother and i can easily run 700ipm rapids with 0.3 acceleration on my Y axis.

As for the sort of glitch, i've included both reports from before and after. If you reset home and the master switch trips before the slave switch, it gives you an error and wipes out the soft limit travels. I don't know if wiping the limits is intended, but i'd never run a machine without soft limits... curious to see what you guys think about it.

3d_low wrote: ↑Tue Jul 09, 2019 4:29 pm So i figured out the issue. Turns out this was an mechanical one that happened during assembly.

My table was too large compared to the X axis gantry by 2mm. So basically the gantry plates were "tapered" from top to down. This was putting pressure on the ballscrew nut and was causing the vibration since the nut and the screw were parallel but not collinear. I've readjusted the table extrusions lengths and redid some test. The whole machine is a lot smoother and i can easily run 700ipm rapids with 0.3 acceleration on my Y axis.

As for the sort of glitch, i've included both reports from before and after. If you reset home and the master switch trips before the slave switch, it gives you an error and wipes out the soft limit travels. I don't know if wiping the limits is intended, but i'd never run a machine without soft limits... curious to see what you guys think about it.

Thank you for the update. It happens.
Did you try a second time to recreate the issue? It was repeatable?
I assume you were not homing your machine properly when this occurred per the software pairing and switch configuration? If you could be very detailed that would be helpful in tracking and repeating the issue. As a beta tester, I have to spend a lot of time recreating the issue, creating notes on the hardware configuration and a step by step process to recreate the issue. Reports always have to go in.

If your machine is configured properly as is the software, NO your software limits should not "zero" out.

Please post a follow up when you have it all sorted out. Maybe a video of it running!
Thanks
Marty

Marty,

In order to create this report I manually triggered the master switch before the slave. I’ve done it multiple times before I figured it out. My machine had a pretty tight tolerance between both the slave and the master so I would get this error sometimes. I made another bracket for my slave homing switch and now it doesn’t happen unless somebody manually moved the gantry.

There doesn’t seem to be any relation with anything else. If the homing fails because the master switch is triggered first, the travel limits get erased every time. If this scenario happens, the software asks the operator to press escape to clear the error. If you open up the wizard and go to the homing tab after, the travel limits are all at zero.

Hope this helps

3d_low wrote: ↑Tue Jul 09, 2019 6:39 pm Marty,

In order to create this report I manually triggered the master switch before the slave. I’ve done it multiple times before I figured it out. My machine had a pretty tight tolerance between both the slave and the master so I would get this error sometimes. I made another bracket for my slave homing switch and now it doesn’t happen unless somebody manually moved the gantry.

There doesn’t seem to be any relation with anything else. If the homing fails because the master switch is triggered first, the travel limits get erased every time. If this scenario happens, the software asks the operator to press escape to clear the error. If you open up the wizard and go to the homing tab after, the travel limits are all at zero.

Hope this helps

Thanks for reporting it!
Marty

Yes - this exact same thing happened to me tonight when I was setting up the auto-squaring. Several times, the travel limits were reset to zero after I had previously set them to specific values for my table. I did have several occasions where the master home switch was triggered before the slave switch. I can document this with screen shots and photos if you need them. I assume that this is now a known "bug" in the software.
David

It won't zero out the soft limits if the auto square is able to run all the way through the macro. If you have the machine mechanically square and the limits staggered properly the software will reset your limits. If for example you trigger the master first the limits don't get reset since the macro was exited prior to finishing. One of the first things the macro does is zero out the limits in order to square the gantry then assuming the machine was setup properly for auto square once the routine is finished and the machine zero is set it puts the old limits back in the software.

I've spent a lot of time with auto square and as long as you mechanically square your gantry and stagger your switches/sensors properly and have the correct value for the distance entered into the wizard, it will work just fine.

If any of the above are not set up properly the auto square won't work properly.

I'm in the process of doing a how to video that goes over everything I just mentioned above that should be helpful for first time users such as myself.

I don't know if in the Beta if it keeps the limits at 0 if you mess up with setting up auto square since I haven't tested it yet and my machine is set up properly. I can test it today by stopping the homing cycle prior to it finishing. I suppose if it was a production machine with users that don't know much about the software I could see where you would be concerned. That said if the machine isn't setup properly to begin with it won't matter whose using it since it's not going to work properly regardless.

Dan