Forum Header

Parallel limit switch connection problem

More
8 years 5 months ago - 8 years 5 months ago #110671 by caseyryan
Hi!
I tried to connect limit switches in parallel, so they could all work as one but after I had connected everything and tested I bumped into a problem I haven't managed to find solution for.
The problem is that when the router bumps into one of the switches it throws an error saying "can't jog joint 0 further past max hard limit". I've googled some pages with similar problems but to no avail so far.
The switches are connected in my .hal file like so:
Code:
net XYZ-max-lim parport.0.pin-12-in-not => axis.0.pos-lim-sw-in axis.1.pos-lim-sw-in axis.2.pos-lim-sw-in

I've also attached the picture of .INI file of my router config (sorry, I wasn't able to get the file itself for there were some problems with copying it to a flashcard).

What am I doing wrong? Is there a way to change this behavior?
Right now the only way to get the router off the switch is to manually disconnect the
Last edit: 8 years 5 months ago by caseyryan.

Please Log in or Create an account to join the conversation.

More
8 years 5 months ago #110675 by DanMN
I believe you'll need the switches in series to get what you want. Depending on your trigger logic you'll have a loop that pulls the homing pin high or low when any of the switches either breaks or completes the loop. Since you're using a "not" pin, that would imply you'll need to create a wiring loop that is normally closed and pulls the pin high until any of the switches is opened by axis travel limit contact.

Please Log in or Create an account to join the conversation.

More
8 years 5 months ago - 8 years 5 months ago #110677 by caseyryan

Since you're using a "not" pin, that would imply you'll need to create a wiring loop that is normally closed and pulls the pin high until any of the switches is opened by axis travel limit contact.

Well, if I understand you correctly, you mean the entire switching loop must always be high unless one of the switches breaks it. If so, it absolutely doesn't matter. I tied both configurations with high and low pins. It gives me the same error in both cases.
I can't provide a separate pin for each switch because I only have 4 of them on my board, and one of them is used for a tool touch-off plate. But in this case it wouldn't even change anything whether I connect 3 axes separately or just as one switch. The router would just get stuck every time it reaches 0:0:0 position on any axis. I believe there must be some programmatic solution to this.
All I want is the router to stop when it bumps into any of the switches and then be able to jog it back again by checking "override limits" box. At the moment I can only do it if it hits any switch on the other side of the router frame
What does this "hard limit" mean? And why does it need it at all?
Last edit: 8 years 5 months ago by caseyryan.

Please Log in or Create an account to join the conversation.

More
8 years 5 months ago - 8 years 5 months ago #110679 by DanMN
The problem appears to be your soft limits. A home offset of "5" says your home switch is 5mm from the end of physical travel. If you were using separate limit switches you'd have a distinct limit switch at physical "0" and you'd leave that "lost" 5mm as safety margin. That 5mm point would be measured as the point where your homing cycle completed its latch back-off. So if you're approaching the limit switch from the positive end of the axis, latch velocity is a negative number, it would find the homing switch and move to home -- with in this case is also toward the negative end at zero. As you're configured now, you're instructing the axis to go backward to zero from home offset after finding the switch. Since it can't get to zero without tripping the switch, you're caught in trap.
Last edit: 8 years 5 months ago by DanMN.
The following user(s) said Thank You: COFHAL

Please Log in or Create an account to join the conversation.

More
8 years 5 months ago - 8 years 5 months ago #110680 by caseyryan

you're instructing the axis to go backward to zero from home offset after finding the switch

So, how can I resolve this? Change the homing offset to some negative value, like, say -10?

p.s. It was not my setup, most of this is the default configuration of linuxcnc, including the homing offset of 5 (I didn't even know what it meant until you told me)
Last edit: 8 years 5 months ago by caseyryan.

Please Log in or Create an account to join the conversation.

More
8 years 5 months ago - 8 years 5 months ago #110681 by DanMN
It helps to understand the flexibility built into the system and how shared switches make compromises relative to that total set of features. For clarification of why the distinction between hard and soft limits, think about the variety of machines that Linuxcnc may encounter -- there could be situations where the homing switch is in some location other than the negative end of travel. It could even be in a location where setting it's homing position as zero would cause you to define a much smaller work area than the physical extents of a given machine. For example, you could have an axis where each 1000mm linear rail had an hard limit switch wired to e-stop, so if something ran-away, the entire machine would halt before your axis drove itself off the machine and onto the floor. That same machine might have its homing sensor at 150mm, due to some specific machine geometry, but you don't want that 150mm of travel lost. In that case, you'd use a home offset of 150, and HOME set to something just short of the distance that would trip your physical e-stop limit switch. Sticking with the example of 5mm, you'd use HOME = 5, telling your system to hit the homing switch at 150, latch to it and define that latch point as "HOME_OFFSET = 150", then upon homing cycle completion, move -145mm to HOME and set your soft limit at that point to axis zero. Your e-stop limit switch is still 5mm behind, hopefully to never be tripped.
Last edit: 8 years 5 months ago by DanMN.

Please Log in or Create an account to join the conversation.

Time to create page: 0.291 seconds
Powered by Kunena Forum