Compiling probekins and using probe2stl

Can you just move the tool down 3-4mm and touch off Z to 0?
That was step 11 on my list.
11. touch off X and Y if necessary and touch off Z

Also make sure that Z is adjusting the correct direction. I had problems with that before.
It's good you are making progress. It should all be working soon.

I tried doing touch off to and initially thought that was why it was hovering. The coords in the 3d view are saying that z = -0.2 and when I stop it and do G1 Z0, it does not touch the surface, it just moves up slightly and right before I hit play I did a touch off. to get it to touch the surface I have to move it to -1.223 z. so somewhere it is moving it up for some reason.

when I turn on z correct I get "joint 2 following error". I'm not sure how I look at the actual error. But I assume that it is just because the cut path is out side the z correct field.

I just got a "joint 1 following error" when I issued the command G1 X0 Y0. it turned "off the machine" so I clicked the power button and issued the command again and it successfully moved to 0,0.

I think it might be time to look at the code. I hate looking at other peoples code....

Are you probing in the same units as running the program? G20 or G21

Have you looked at the files I posted earlier? In the probing routing, I added a few LOGs to add the machine outer bounds to the probe file.
That will help cure following errors when moving outside the probed area.
If you get a following error when you turn on z correction, then the delta-z is too far from 0. It tries to jump into position, but isn't quick enough.
That is the reason you need to be in the XY position where you touch off Z to 0. It won't try to move the Z, because delta-z should = 0.
A joint 1 following error, I don't think would be related to probekins, as it should only adjust Z.

I'm trying to make the probekins module work, and am having trouble with stlcorr not getting the shared memory segment.

I've checked out the development branch of linuxcnc (2.7.0~pre0), and added the probekins code, and succesfully compiled it.
Using the example 'sim/axis/axis' configuration, I've replaced 'loadrt trivkins' with 'loadrt probekins size=2048' in core_sim.hal.
using the 'rip' environment, linuxcnc comes up, and log messages from dmesg indicate that probekins is loaded correctly, and
allocated shared memory as expected:

[ 3421.457981] RTAI[hal]: <3.8.1> mounted over IPIPE-NOTHREADS 2.6-03.
[ 3421.458009] RTAI[hal]: compiled with gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) .
[ 3421.458037] RTAI[hal]: mounted (IPIPE-NOTHREADS, IMMEDIATE (INTERNAL IRQs DISPATCHED), ISOL_CPUS_MASK: 0).
[ 3421.458062] PIPELINE layers:
[ 3421.458087] f91dae20 9ac15d93 RTAI 200
[ 3421.458110] c085cb20 0 Linux 100
[ 3421.485171] RTAI[malloc]: global heap size = 2097152 bytes, <BSD>.
[ 3421.485302] RTAI[sched]: IMMEDIATE, MP, USER/KERNEL SPACE: <with RTAI OWN KTASKs>, kstacks pool size = 524288 bytes.
[ 3421.485315] RTAI[sched]: hard timer type/freq = APIC/62162364(Hz); default timing: periodic; linear timed lists.
[ 3421.485319] RTAI[sched]: Linux timer freq = 250 (Hz), TimeBase freq = 2090963000 hz.
[ 3421.485321] RTAI[sched]: timer setup = 999 ns, resched latency = 2944 ns.
[ 3421.485396] RTAI[usi]: enabled.
[ 3421.573041] RTAI[math]: loaded.
[ 3421.669349] HAL: initializing component 'probekins'
[ 3421.669354] RTAPI: initing module HAL_probekins
[ 3421.669363] RTAPI: module 'HAL_probekins' loaded, ID: 8
[ 3421.669368] HAL: component 'probekins' initialized, ID = 08
[ 3421.669371] probekins debug=0 shmsize=2048 comp_id=8
[ 3421.669410] RTAPI: shmem 02 created by module 08, key: 4711, size: 2048
[ 3421.669412] faces offset=80
[ 3421.669415] HAL: creating pin 'probekins.enable-z-correct'
[ 3421.669432] HAL: creating pin 'probekins.delta-z'
[ 3421.669436] HAL: creating pin 'probekins.flags'
[ 3421.669440] HAL: exporting function 'pkupdate'
[ 3421.669443] HAL: creating parameter 'pkupdate.time'
[ 3421.669446] HAL: creating parameter 'pkupdate.tmax'
[ 3421.911314]

However, when I try to load shared memory with 'stlcorr.py --load <probe.stl', I get the following error:
Traceback (most recent call last):
File "./stlcorr.py", line 171, in <module>
main()
File "stlcorr.py", line 130, in main
load_file(b,filename)
File "stlcorr.py", line 62, ln load_file
raise Exception "Buffer too small, have %d need %d" %(len(b),req)
Exception: Buffer too small, have 0 need 164

The problem appears to be that getbuffer does not return "anything" (I'm not enough of a python programmer to be more specific)...
I added some print statements to the get_buffer routine in stlcorr.py, and get the following:
c is <hal component notused(20) with 0 pins and params>
sm is <shared memory buffer key=1267 id=2 size=0>

The 1267 is the hex representation of 4711, which is the 'key' value coded into probekins, and the argument to the hal.shm call.

Sooo.... any ideas?

Thanks in advance!
*** Doug

andypugh wrote:

Is stlcor _definitely_ loading after probekins?
You might try putting the loadusr for stlcor in the postgui HAL just to be sure.

Yes, I'm sure - I'm running stlcorr as a seprate command manually after linuxcnc is up-and-running.
However, I did try the postgui trick (just in case), and got exactly the same error messages.

*** Doug F.

what is on line 11 of the file stlcorr?
size = 2048? or something else?
It needs to match the number you specify when you load probekins module.

andypugh wrote:

My next thought is that perhaps the buffer keys are both decimal (or both hex).
Do you get to choose either of them?

No, they are identical...

alan_3301 wrote:

what is on line 11 of the file stlcorr?
size = 2048? or something else?
It needs to match the number you specify when you load probekins module.

Bingo! That was the issue. It appears to be working now.
For future generations,Here is the specific change:

In the function get_buffer() in stlcorr.py:

was:
sm = hal.shm(c,key,0)

new:
sm = hal.shm(c,key,2048)
(2048 is the argument for buffer size that I used when loading probekins in the hal file)

I think the theory in the original code was that the call to hal.shm would supply the size of the shared memory
buffer. Obviouosly (now) that isn't true....

THANKS alan_3301 (and andypugh, too) for your help. Now I can move on to using probekins.

*** Doug