Advanced Search

OK so fairly complex...

As I said before, maybe the first step is to take a look at
hm2_5i24.0.7i83.0.2.analogout0 in halshow when running
the spindle in each direction.

Dear new Member please don't change the Subject when posting it renames the thread in the Index and makes it hard to find

4GB RPI5 is fine, if you are going to jump that way. But I'd be more inclined to look at the x86 offerings from Odroid. I've been using one for 4 or 5 years without an issue.

Sorry , I guess you are right, G33.1 also looks at the spindle speed 
But this works better with good velocity estimation, Though as I mentioned
you cannot use position interpolation except for constant speed applications
like threading on a lathe.

This is wrong because the TP does use the velocity value:

It is precisely true, LinuxCNCs TP only looks at the encoders position
in G33.1 moves. There is no other information path.

Looking a bit more into this, It does not look like the encoder velocity
( spindle.spindle_num].spindleSpeedIn ) is used for position mode synchronized
moves (G33 G76 etc) but only velocity mode synchronized moves (G95).
At least with a quick look at  tp.c 
 

PCW wrote:

Velocity estimation is unrelated to G33.1 as G33.1 only looks at position.
 

It is not true.
Tool moves while spindle stops, even if position is reached.

Hi,
I'm not too familiar with the integration into probe basic, but I'm pretty sure the surfacemap tab did work when it was released.

It's possible that posting your config might help narrow down any issues.
And can you show your halshow for the relevant pins when you believe it should be enabled?

Also, It is possible to use the compensation component standalone, with no involvement from probe basic, even if the process is slightly more manual.
Use the version from Scott's Repo and follow the instructions there:
github.com/scottalford75/LinuxCNC-3D-Pri.../master/compensation

For PCB milling, I think that this compensation component should work really well. Since the component is taking the current XY point and outputting compensation in Z, it's always 'playing catch-up' as the machine moves, but unless you're demanding very quick changes in the compensated value (think feeding fast over a rough surface) any deviation in the compensated position isn't really much of an issue.

I haven't tried any other compensation approaches, but G-Code Ripper with the Auto-Probe operation can warp your G-Code to the probed surface.
The version bundled with LinuxCNC is located in the /usr/lib/python3/dist-packages/qtvcp/lib/ripper/ directory (and you can run it standalone if you want).

It may be fixable

What servo thread period are you using?

what does:

sudo chart 99 ping -i .001 -q -c 60000 [7i96_ip_address]

report?

(it should run for 1 minute and report timing statistics, [7i96_ip_address] is the IP address of your 7I96S card)

Did you run a standard latency test?
 

I believe I got them and then some. 

Velocity estimation is unrelated to G33.1 as G33.1 only looks at position.

If you do position interpolation, it's only for threading (Constant speed)

Also, as I mentioned, you need hardware timestamp support for velocity estimation.

PCW wrote:

The normal way  this is improved is by velocity estimation, which changes the velocity calculation from
delta_counts/sample_time to delta_counts/time_between_counts.

It is true, but not solution for G33.1
In most worst case, the spindle stops, but the component waits for next pulse from encoder...
I have for tests small lathe with servo as spindle engine (velocity mode). It can stops (from 1500 to 0 rpm) at about 100 ms. (This is especially intended for fast G33.1)
In my opinion, the best is use high resolution encoder, and average speed from a 8 or 16 servo_thread periods.
Some cheap chinese encoders has bandwith 100-150 kHz, so in most cases 2500 P/R will be good.
But there is another problem. In my project I use STM32 with hardware quadrature counter, so this uses interrupts only for counter overflows.
Chips with no hardware quadrature counter must use interrupts for every encoders edges, it means hundreds of thousands interrupts per seconds, so it is very bad idea...

Fancy pants geneva mechanism finalised. steel pins for BCD encoding with induction sensors. fun fun! haha.
 
 

Thank you PCW, now everything is clear and understandable. I think i solve this purely on the Pico side.

You're correct. In the currently available modules there is no basic analog input. But the underlying code is there and used in the thermistor module.

I had bought a mini pc from Amazon and I’m not sure if it’s causing latency issues or not ? I’m using a mesa 7i96s .   This is the mini pc I bought.
www.amazon.com/gp/aw/d/B0DNT28BV1?psc=1&...pop_mob_b_asin_title 
i shut every thing i could off in the bios including WiFi. 

I was using probe basic but I get a latency error and random disconnects . 
Could I just switch to a raspberry pi5 16gih version? 

The issue with the sampling speed has to do with velocity calculations,
mainly at lower speeds or lower resolution encoders:

Imagine you have a 1000 count (250 PPR) encoder turning at 30 RPM (= 0.5 RPS so 500 Hz count rate)
If sampled at LinuxCNCs standard 1 KHz rate, you would get 1 count every other
sample, since the most basic velocity calculations would use the difference in counts to determine
the velocity, the velocity calculation would alternate between 0 RPM (count change of 0) and 60 RPM
(count change of 1). At higher speeds the problem gets better but does not go away, at 90 RPM
with the same encoder/sample rate, you would get alternating counts of 1 and 2 so alternating
velocity calculations of 60 and 120 RPM.

You can of course filter the velocity value since the average value will be correct, but this is not desirable
if the velocity is used for feedback as it lowers the control bandwidth.

The normal way  this is improved is by velocity estimation, which changes the velocity calculation from
delta_counts/sample_time to delta_counts/time_between_counts. This typically requires that the low level
hardware timestamp count changes to allow the time_between_counts to be determined.

Once you have decent velocity estimation, you can do tricks like position interpolation, allowing
use of very low resolution encoders for constant speed spindle synchronized motion like threading.