Limit Switch Troubles - HAL Debounce

ctrl-frq wrote: I believe the issue is debounce because the machine will USUALLY stop running and kick up the error before it ever gets to a switch. The switches are N.C. by the way.

Now it sounds like you have either a loose connection or a voltage issue in your limit switch circuit.

What are you using to bring the limit switch circuit into LinuxCNC?

What kind of limit switch are you using?

Really you should not need debounce for a limit switch.

JT

BigJohnT wrote:

ctrl-frq wrote: I believe the issue is debounce because the machine will USUALLY stop running and kick up the error before it ever gets to a switch. The switches are N.C. by the way.

Now it sounds like you have either a loose connection or a voltage issue in your limit switch circuit.

What are you using to bring the limit switch circuit into LinuxCNC?

What kind of limit switch are you using?

Really you should not need debounce for a limit switch.

JT

I agree with JT, the only problem I have ever had with limits was noise causing false activation. Jumping the limits circuit voltage to 12v completely cured it.

However I have been multi-tasking too much today and had forgotten that this was ever titled to be about limit switches, I was thinking home switches.

This section made me think you had joint limit and home switches

So, my troubles with the limits seem to be 100% debounce issue. The machine will attempt to home and sometimes does completely. But, more often than not, it will kick out with an error that claims the switch was active before this that or the other thing. I am convinced that I need to increase debounce.

So my confusion is compounded when I look at your .hal file and realise that you don't have any limit switches, the debounce is applied to the home switches?!

>>>This whole problem could be simply that you have not added the component to a thread.....

Wow... add something that says SERVO to my stepper config... clear as MUD ! LOL ! I assume it installs up there in with the rest of the "addf" references.
Thanks though... I'll give that a whirl tonight. I hope that solves it !

It really can't be something "loose".... the machine offers 100% reliable operation under the other control, heck 120%! The limit switches are still some OEM, unknown small push button jobbies that have the N.O. terminal cut flush or not even there. If they were, I would TRY Normally Open. I have used one of those HAL tools to let me SEE the switch operations under all sorts of rigorous attempts to force failure, but they always look just fine. I'm slowly grasping my diagnostic options with HAL meter and whatever else it was named....

HOW they are brought in to the parallel port ? Well, the machine has its own harness that jumps into a 30 some pin DB connector. From there, a cable takes ALL the wires including motor signals to another 30 some pin DB connector and into the driver cabinet. Now inside, I had gutted the OE embedded PC board and intercepted all of the other traces necessary to utilize the existing on-board relays and such for Outputs. Right out of the linux box, both my spindle and dust collection (coolant) relays operate perfectly.

All the wires in one cable ?? You can't do that !!! many will tell you, but hey, OEM's do this a lot. And it works for them. heck, it is working for me with FC but I feel the need to know more about Lcnc (been forced down the road with Mach more than once and it has always sucked for me.. always!).

I did similar trace intercepts (and isolation) on the existing OE PC boards to redirect the IMS483 driver inputs, as well as the LIMIT wires directly into a new DB25 plug mounted on the cabinet in order to provide a single inlet location for everything from in the first case, Flashcut, and now, a parallel port via linux.

I have simply created a new DB25 cable with the pin crossovers in place. I am not running any retail BOB in between. I quickly realized that I do not have a +5v source IN the cabinet for logic, so for now, just fed +5v into my new cable via wallwart (Flashcut itself provides an optional +5 logic source and I've always just used it - I'll put a dedicated +5 supply in the cabinet at some point).

Once the machine was jogging and the homing routine was set up to work but failed completion 95% of the time, I concluded it might be "pullup" issues, and then added some resistors... a tried a few different values commonly yacked up in the various forums... no difference. Then I searched for debounce options and found them to be a little blurry.

I know that most guys really want NC switches on those circuits and I know why. I will say that on other retrofits over the years, sometimes when I would use the conventional Cherry snap switch for convenience and specifically when they were used NC, they would require higher debounce periods with FC. Seems either the chatter of machining or perhaps the direct minor pulse rattle from steppers as some speeds would make the contacts tremor.

Oh well, fun stuff. I came across some Denford Lathe discussion in that brought me to just explore gmoccapy lathe screen..... Can a guy ever get enough of something that is this much fun ? Here are some photos of a Denford I have running on FC: data-cut.com/projects/miscmachines/index.html

It would look nicer with gmoccapy:-)

Norbert
( the gmoccapy maker)

newbynobi wrote: It would look nicer with gmoccapy:-)

Norbert
( the gmoccapy maker)

Well, if that is your work, its quite incredible ! I was ready thru the wiki and was completely amazed at the content. If it actually works (unlike a large number of the Mach3 dreams), that is one heck of an interface ! I for one would like to see a Pre-Loaded HAL file that contains all those pin options.

By the way, why doesn't someone just compile a "loaded" example HAL file with every possible option listed but Rem'd out ? Kind of like you find for a Samba Config ? It would be much easier for a dummy like me to see actual options and play with their use that way.

I spent a little more time in the Plasma section of the wiki as I have 2 plasma machines. The one that gets the most use is the one I have here at home. Its a little "portable" thing that folds up and sits against the wall when I don't need it.

It works very well now though and I really like the fact that I can just snap in a USB cable to my laptop and I'm up and running. I'm sure I will spend a lot of time in that interface... once I get to know it better, I'll try to apply it elsewhere.

Again, Incredible !

SOLVED !

ArcEye's recommendation about the line I was missing took care of it !

Honestly, I searched the web for the answer to this problem on and off for two days before I joined and asked here. I found the typical bits and pieces from seasoned users who assume dummies like me have a clue what you are talking about. But thanks ArcEye... You solved the puzzle and I am homing like a dream !

For the benefit of others, my machine would not complete the homing procedure reliably. On occasion the machine would move thru the whole routine, while other times it would stop moving and give me the error " Home Switch Inactive Before Start of Backoff move".

Here is the ENTIRE code that made a difference in the HAL file:

Under the last loadrt line, I added:

loadrt debounce cfg=3
setp debounce.0.delay 20

Under the last addf line, I added:

addf debounce.0 servo-thread

I located and Rem'd the limit info installed by stepconf:

#net home-x <= parport.0.pin-10-in
#net home-y <= parport.0.pin-11-in
#net home-z <= parport.0.pin-12-in

And installed the following under it:

net debounce-home-x debounce.0.0.in <= parport.0.pin-10-in
net home-x debounce.0.0.out
net debounce-home-y debounce.0.1.in <= parport.0.pin-11-in
net home-y debounce.0.1.out
net debounce-home-z debounce.0.2.in <= parport.0.pin-12-in
net home-z debounce.0.2.out

One thing that becomes quite obvious, is you can not really use stepconf more than once or what you have added goes bye, bye. I can only wonder why Debounce isn't just added to the stepconf gui, but then again, I already found a lot of things that could be in there for a newbie.

I have not been able to run any G-code yet..... all my engraving files have been done in Signlab, which has an obvious IJK start/end radius problem. I always knew that, but Lcnc kicks up an error. FC had an upfront default setting to ignore radius errors beyond what was set there, and if it went beyond that, it kicked up a message telling you how far it was off and asked if you wanted to halt or ignore and run it anyway.

So, I will now google the answer to this problem and hope to find that Lcnc also has the ability to ignore certain start/end errors or I'm screwed. I have thousands of engraving files....

Thanks to all who helped me with this issue !