Advanced Search

Hi all!

I have been trying to get a Z compensation thingy working for a while. 

github.com/scottalford75/LinuxCNC-3D-Pri.../master/compensation

I have gotten the script working, in the way that it is incorporated in LinuxCNC, and it reads my probe data, sorta. I have two problems with it.

First problem: It doesnt read negative coordinates in X and Y. It only understands lower left corner being zero in the gcode. Which is a problem, since my machine zero is in center of worktable, and i make all my gcode with zero in center. I have worked like that for ages, and i dont feel like changing my workflow. 

Second problem: The outputed coordinates only work from machine zero. It doesnt follow if i have a work offset active. 

Has anyone had the same problems? This is over my skill level, and i cant get it to work.

I am attaching a number of files. Compensation.py is the script i am using now. probe-results.txt has only positive coordinates and works. probe-results2.txt has both negative and positive, and does not work. Or, it works for a while if i only move in positive area, but after a while the whole compensation just dies and i have to restart LinuxCNC. Z_level_compensation.py is a file i found in another thread here, that i believe morley(?) has modified. It is based on the script i am currently using, but it looks like work offset has been fixed. I have not gotten this script to work on my system, but maybe someone can tell me how to fix my problems based on that. 


 

tommylight wrote:

Usually omitting or deleting lines with HOME_...._velocity in the ini file and editing the homing and limit lines in hal is all it takes,

It's usual to retain the lines, but set the two velocities to zero. Omitting probably works too (they will default to zero) but actively setting to zero looks less like a mistake. 
 

endian wrote:

I have not using any kind of global variables 

I think you are, look at line 159:

mode_selection is a static global in the code. 

I don't know for sure if that is enough to cause the problem? 

it looks like mode_selection should be a local variable (actually, make it a parameter so that you can debug using it)

Also maybe consider using a "switch" command on mode_selection rather than repeated "if (mode_selection == ##) "

timo wrote:

 because I might have damaged a drive or two without beeing aware of the importance of the wiring.

 
A cage-clamp terminal done up nice and tight with the cable not actually inside the clamp is a popular way to blow up a drive. Give the wires a good tug after tightening the clamps.

Kieran wrote:

How's the rigidity of the harmonic drive? 

It seems OK. The HD website quotes values for torsional stiffness, but to be honest I don't know what value would be appropriate for a milling machine, so the numbers aren't useful to me. 

But I frequently use it just as a handy way to mount round stock and have noticed no issues. 
 

Here's an example:

 

It's a bit tricky because you do need to use muxed encoders for all
encoders (because the 7I89 uses physically muxed encoders)

 

Does this help at all?
wiki.linuxcnc.org/uploads/orient.svg
It's one potential way to do it.