Encoder velocities and index signal reading

If that does not fix, it is time to add a debug pin for destination and observe what is going on in halscope

rodw wrote: you can just use the fmod(a,b) function to calculate the modulus of two floating point numbers!

It's always worth checking that a given C function exists in rtapi_math.h
github.com/LinuxCNC/linuxcnc/blob/0f91c5...c/rtapi/rtapi_math.h
These are the only maths functions that you can safely use in realtime code.

rodw wrote: I'm not sure if this will help. Try

Code:

double destination = (double)repeat_multiple * repeat_length + event_pos;

C is a typed language so it is not usually valid to mix types (unsigned and double) in a calculation so you need to use a cast to explicitly tell C to convert that number to a double before using it.

EDIT: So the code will compile but I would expect to generate a compiler warning and one should always treat warnings as if it was an error if you are programming defensively.

Thanks, I'll run that by my friend. He's written me several components for various things, it does compile and load in hal but I haven't bothered testing it yet because I'd like to make it a "one size fits all" component that will allow me to get rid of the hal logic file I use for the other hardware case. It's severely bloated by off the shelf component limitations.

One thing I'm curious about is the time aspect of RT components. Is this handled the same way any other compiled code is, or is there some rtapi consideration? My thought is that a typical time calculation may work differently when considering the RT thread the code is running in, or does halcomp just take care of this internally?

blazini36 wrote: One thing I'm curious about is the time aspect of RT components. Is this handled the same way any other compiled code is, or is there some rtapi consideration? My thought is that a typical time calculation may work differently when considering the RT thread the code is running in, or does halcomp just take care of this internally?

Think of the Servo thread being an interrupt service routine (ISR) for a Timer interrupt that fires 1000 times per second. Every Hal component is loaded in a chain and all must execute inside that time period. Bad things will happen if it overruns.There are other system interrupts that depend on this so if you hang or have an endless loop in an ISR, it won't be pretty, even down to the hardware level. Thats why ISRs and HAL components, need to be short, sharp and sweet. Its unlikely they will run early or late.

In every hal component there are two system variables Period (nanoseconds) and fperiod (seconds) that give you the precise period timing invocation per servo thread cycle.

Sorry blazini36 if I chime in.
I would advise you to stick with an index on the real hw. I know what I'm talking about as I was the main brain of a digital printing on cd's process around 2001.
eitel.ch/job/digitran/index.html
In case of missing a puls you will have a drift that might ruin your complete batch.

M5c
Mike

@mike,
That was quite a chalenge, very nice work.
At that time i was doing the other part of that job, the CD copy machines.
Regards,
Tom.

@Tom
Yes fascinating job, but lost 5 years of good looking in 2...
Much calmer today. Mechantronic only as hobby.
But sometimes is miss those days nevertheless...
Mike

Oh hell, i'm 49 and i still enjoy chalenges, a lot.