[Jon.N.CNC]

Hi there,

This is getting well and truly irritating now. Whats up with uccnc and limit switches. Compared to mach 3 my switches are registering almost instantaneously. UCCNC i could sneeze before they register. On homing id say they are overshooting at any feedrate by around 8mm.

The x and y do home overshoot massively and move off, not as much as they should, intermittently they will stop just shy of releasing the switch. but the z is having none of it, simply land on the switch and thats it, no attempt at moving off.

Could this be because my z is setup in positive direction mode? if so the homing procedure should be applying the home off move to all limits not just the minus.

And how the hell do you set the home off distance?

Not sure im into this pre configured crap.

I dont take enjoyment in these kind of posts.. i hope that im missing something and i will be corrected so i can remove this post as its of no pleasure but really, not so much as a mention in the documentation, for an essential parameter to be so illusive is crazy.

anyone shed any light on the subject? Cheers Jon.

[BanduraMaker]

Did you check the diagnostics page? Are the limit switches triggering properly?

[Jon.N.CNC]

Okay got the z moving off. had to slow the acceleration. So 100mm/ps/ps seems to be uccnc's limit if you want it to home correctly :s

Yeah they are all just super slow.. Not one is faster than the other.

i run both mach and uccnc at the moment and like i say they are almost instantaneous in mach 3 so the issue resides only in the software.

kernel speed is 100khz not that should make a difference.

Still overshooting much more that they should. its as though its still applying the same deceleration ramp after the switch triggers instead of reducing the ramp.

I could slow the homing speed to reduce the overshoot but its already at 100 mm/min, my machine is 8 x 4ft. any slower i think id lose the will to live.

This cant be right that its the homing procedure that defines the acceleration of you machine surely. My machine doesn't miss a beat at 400mm/ps/ps, so 1/4 its capability its got be then

[BanduraMaker]

Hmm... Mine homes at 50ipm which is 1270 mm/min. I tend to park it at 0,0 before I turn the machine off to speed up homing.

[Jon.N.CNC]

I retract that stement its moving off but not enough to deactivate the switch grrrrr... just tried 50mm/ps/ps... no change

Okay got the z moving off. had to slow the acceleration. So 100mm/ps/ps seems to be uccnc's limit if you want it to home correctly :s

Yeah they are all just super slow.. Not one is faster than the other.

i run both mach and uccnc at the moment and like i say they are almost instantaneous in mach 3 so the issue resides only in the software.

kernel speed is 100khz not that should make a difference.

Still overshooting much more that they should. its as though its still applying the same deceleration ramp after the switch triggers instead of reducing the ramp.

I could slow the homing speed to reduce the overshoot but its already at 100 mm/min, my machine is 8 x 4ft. any slower i think id lose the will to live.

This cant be right that its the homing procedure that defines the acceleration of you machine surely. My machine doesn't miss a beat at 400mm/ps/ps, so 1/4 its capability its got be then

[Jon.N.CNC]

Hmm... Mine homes at 50ipm which is 1270 mm/min. I tend to park it at 0,0 before I turn the machine off to speed up homing.

yeah thats the kinda speed id expect, in mach 3 no problem.

[Jon.N.CNC]

Hmm... Mine homes at 50ipm which is 1270 mm/min. I tend to park it at 0,0 before I turn the machine off to speed up homing.

Just tried z at 1200, it improved by moving off more but overshoot still same.. tried it at 2000 it bouced off the ballscrew support and moved off the switch!!! wth is going on

[Jon.N.CNC]

Okay my bad.. looks like uccnc is more resource heavy than i thought, swapped back to my faster laptop and it worked fine. so even though the slower laptop is capable of running large amounts of code fine.. struggles with registering switches. Not sure but it may only have standard usb. not usb 2 which by the looks of it is needed for input i/o's

All that said and yes they are now registering but still a large delay over mach 3, so still overshooting in comparision. The faster laptop of the two is a dual core 3.6ghz per core usb 2 4gb ram so should be more than capable. And this still doesn't explain why mach 3 registers almost instantaneously on the slower laptops old standard usb port and uccnc requires a faster port.

And the move off parameter not being adjustable makes it more suited to the small type microswitch not the larger ones.

[dubble]

You probalby have your home switch polarity configured in reverse and your axis homing direction also in reverse.
If so then when you start the homing process then the UCCNC will think your axis is on your limit switch already, so it will start in the downgoing direction and when it will actually push your home switch it will think it just went off the switch and then it will deccelerate down toward the switch and will remain on the home switch.
Please note that towards the limit swith the UCCNC does not use decceleration, it only deccelerating on the downwards direction, so if you see the UCCNC deccelerating toward your switch then you sure have the home polarity wrong!
With your home switch not triggered check that the home virtual LEDs on the Diagnostics page are off, if they are on then I was right and you need to change the polarity of the home and also the homing direction polarity.

P.S.: Please also note that I'm not reading this forum at all, I just accidentally got here today, but will not revisit anytime soon ... and we do not support our products on CNCZone, we have no connection with this forum, if you will need any help you can e-mail us.

[Jon.N.CNC]

Good question. and a good point but nope its off.. If it were the other way wouldnt limit logic always be on? unless on the switch that is.

Now i have determined that the slower laptop was slowing the register of the trigger, and now with a faster machine its better, its now the issue of the distance it homes off. my limit switches are large and with the slow trigger the overshoot is still further than the home off. there has to be a script somewhere in the software.. doesnt seem to be in the profile file. where else could it be hiding?

That said the distance it homes off doesn't seem to be the same each time. Its quite possible it simply homes off until the logic of the switch changes. Only its getting a false low when the switch is at 50% undepressed. which if a faulty switch would explain the overshoot but its happening on all switches

Just tested in mach 3, and they are fine.

from the point the switch is triggered and the software commands a stop is simply too long imo

[dubble]

Nope, the home and limit polarity can be set separately (as you may see on the setup page), because it is not sure that all machines share a single switch for the home and the limit, these may be separate switches/sensors.
So, it is possible to setup the limit switch to correct and the home switch to the wrong polarity and what you will see in this case is what I described previously.
There is no script for homing, what the homing does is that it runs to the home switch when reached immediately reversing and when left the swith it stops with the set decceleration and registers the home position (if setup to do so.)
Note that you can set separate running speed for the homing up and down directions.

And there is no such thing as "slow trigger" for homing, the motion controller directly and immediately acts on the home switch and only after feeding back information to the PC,
therefor when the switch triggers does not depends on the speed of the PC at all, when the signal enters the motion controller, the motion controller takes action and the whole homing action is controlled by the motion controller and not by the PC!
The PC only telling the motion controller when to start a new axis homing and the motion controller tells the PC when the homing is done...

OK, I'll really have to go now, if you will still have problems you can e-mail us. Bye!

[Jon.N.CNC]

Bizarre.. swapped all the switches from normally open to normally closed and active high for both limit and home switches and bingo!, though they were all set as active low so wasn't a mismatch.

Very odd.. cant see what the difference is to uccnc but hey.

Thanks dubble, you wasn't far wrong and was enough to give me the idea. Cheers

Of course yes, I was forgetting the uc300 does act on the switches. I was going of the led delay assuming that it was the same delay that was causing the overshoot.

Thanks for your help.

[dubble]

Might be a prell / noise on the home signal, if there are optocouplers then ative low and high edges may go through differently, so it might be the problem with the breakout board's opto circuit ... or if the switch prells too much (switching point not stable) can cause weird problems like e.g. the axis stucks on the switch, for the software/motion controller it does not count if the signal is active high or low, I mean it works the same, just one bit is inverted ... okey I really went to sleeeep now. Bye

[Jon.N.CNC]

May well be right there..i thought i had taken every measure to avoid noise tho, alpha cable, ie grounded screens throughout each component board in the controller is segregated from each other in their own grounded enclosure, no ground loops, screened grounded at only one end etc etc, so be quite annoyed if was noise from the wiring but may well be noise on the board itself.

The board has individual opto'd circuits for every input output, ive tested this in the past having fried a few on a different board and you can fry them individually with the rest still working. so one might expect the issue not to be the same over all the switches.

which leads me to think the switches could be naff, But seem to be working fine for now as nc so see how they fair.

thanks for the insight dubble.