Advanced Search

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.

 You posted Knuth.hal but not:

6i24.hal
LadderIO.hal
custom.hal
custom_postgui.hal

These are all parts of the configuration

Looking into halshow now.

Is there something specific you are looking for? There are a myriad of back up files stored in here.

Unfortunately, I got the lovely task of coming in behind somebody else and I need to figure it out. I knew nothing of Linux prior to a month ago, but I'm a fast learner. This has had me stumped for quite some time. If you could point me towards some documentation or if you could give some guidance on how to accomplish what is needed, that would be greatly appreciated.

If you look at the hal file, none of the important spindle connections
actually connect to anything, that is, the hi-lighted signal names are
not connected to any driving source.

EDIT: can you post the other hal files? I suspect the missing
connections are there.

HALFILE = Knuth.hal
HALFILE = 6i24.hal
HALFILE = LadderIO.hal
HALFILE = custom.hal
POSTGUI_HALFILE = custom_postgui.hal


Also using halshow to watch hm2_5i24.0.7i83.0.2.analogout0
when running the spindle in each direction would help debug this

They were posted earlier in this thread. Not much has changed since then.

Can you post your hal/ini files?

Upon closer inspection, it is 7i83. I'll get a flashlight next time. How can I tell if the version I have is too old? (LinuxCNC 3.4.6) Furthermore, can I update it?

You probably mean a 7I83 or 7I77 (the 7I87 is an analog _input_ card)

My guess is that there is a missing abs function in the hal file.

The 7I83 and 7I77 have bipolar +-10V analog outputs, but most VFDs
only take a unipolar ( typically 0 to +10V) input range, so you either need to
use the absolute spindle speed pin from motion or add an abs function
if you have an old enough LinuxCNC version that does not have the absolute
spindle speed pin.