Limit Switch Troubles - HAL Debounce

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 !

Signlab, Engravelab, Profilelab.... all at this point, overly priced products from Cadlink. www.cadlink.com/

Been around for decades. Kind of like Cad/Cam would be if Corel Draw did it. VCarve comes close, but sadly VCarve STILL does not do certain things Signlab can do.

I believe my IJK error "issue" is covered in the Lcnc user manual under G2, G3:

It is an error if: When the arc is projected on the selected plane, the distance from the current point to the center differs from the distance from the end point to the center by more than (.05 inch/.5 mm) OR ((.0005 inch/.005mm) AND .1% of radius).

Signlab is not the only program that compiles G-code and produces this erroneous radius, and there seems to be quite a few people who get the error in Lcnc. The answer so far that I have come across for some is to try running with G90.1 (or G91.1, I forget which) rather than just G90. Right away, responses blame the cam program and not Lcnc.

I've got 20 years of specifically engraving files that I have run perfectly well with FC... and this machine is an engraver.......
www.google.com/search?q=vision+1624&biw=...CgAw&ved=0CAgQ_AUoAw

I was just hoping to come across a SETTING for the above Lcnc statement as to what constitutes an error or this will be a problem. I believe that my error is kicked by the second part of the statement of the ".0005" AND 1%. because the adjustment in FC is called "Arc RADIUS Tolerance" and I believe defaults to .01". I can tell you that whatever this amount of error is generated by the post in Signlab is not enough to actually SEE, even if I engrave very, very tiny letters (thus the .0005 and 1% potential culprit). Its never been an issue !

Bottom line is this is not my only engraver and parsing my existing files will not be a good resolution!

Well, for years, I did not use it only as a "Sign Program"... While it was designed specifically for that, but I would draw any of my mechanical needs in Cad, the import it and use Signlab as a Cam program. In many ways, it still does things a lot of other Cam programs fail to do, but I would never recommend it as a Cam program these days.

My problem paths in general are all 2.5d, and I have attached a snippet of something really simple that opens and runs fine in FC, but gives error in Lcnc. Now, unfortunately, in gmoccapy, I can not COPY that error message in order to paste it somewhere, but it is essentially complaining about a start and end point being some percentage off from each other.

I did not look, but I assume that yes, I might find a setting in Signlab to tighten things up in this regard... its just never been an issue ! I've been using Signlab for things since probably 1994 -95ish, and Flashcut since mid 1996. I ran Signlab files on Ah-ha controls before that, and before that, some proprietary controls.

I probably wouldn't know anything about such an error if it had not been for Flashcut occasionally popping up a warning dialog when the file must have had a similar error just outside the default tolerance. When I saw it in Lcnc, I immediately knew what it was complaining about.

There obviously IS a setting for this in Lcnc because the manual describes exactly when they will cause it to trigger the error we see on screen. Its just that the developer figures he knew what was necessary or best. As such, the end user just does not have access to such a setting unless of course he is a coding genius and can find the references and alter them.

It's not an end all problem for me, just that anything older has to be run on a different machine. Some of these files were created without G2-3 arcs and all short line segments. In the beginning, Flashcut ran thru short line segments faster than arc commands, so we just created files accordingly (that has obviously changed).

I did have troubles with the gmoccapy interface tonight.... the visual toolpath display would fail to show me the path of the file that I had loaded. In fact, I never got it to show the toolpath segment I have attached.... I opened it in FC and it displayed exactly what I figured it would.

No worry.. I have a LOT to learn ! There are many things I am used to having that I can't find... YET at least. But I am homing reliably now !

Should I start a thread asking specifically about the IJK error and the default Lcnc settings that we can not get at ??

Thank YOU for your help though.

ctrl-frq wrote:

Should I start a thread asking specifically about the IJK error and the default Lcnc settings that we can not get at ??

BigJohnT wrote:

Ah, but we (anyone) can get at any setting because LinuxCNC is open source.

Another thread might be good to discuss the source code.

JT

Try this one

www.linuxcnc.org/index.php/english/forum...-arc-tolerance#54186

regards

Hi, does this work for limit switches too? eg all-limit? Would it be:

net debounce-all-limit debounce.0.0.in <= parport.0.pin-10-in
net all-home debounce.0.0.out

Does it have to go in the main .hal file or can you just put it in the custom.hal file?

Is there documentation were all the home-x etc are listed and defined?
Thanks.