Advanced Search

I have the same probe, but I haven’t tested it yet. Based on the documentation I read, this probe switches on the negative (–) instead of the positive (+). So this is probably an electrical issue, and you need to change the wiring.

For a more comprehensive switchable kinematics example see:

sim/axis/vismach/5axis/table-dual-rotary

which uses:
github.com/LinuxCNC/linuxcnc/blob/master.../xyzab_tdr_kins.comp

You can download a detailed html documentation on how the kinematic component above was derived:
forum.linuxcnc.org/10-advanced-configura...mill?start=80#263694




For an example using four kinematic models see:
github.com/Sigma1912/LinuxCNC_Demo_Confi...egrex_200y_kins.comp

Why does X has a 'tran' and V doesn't?

I cannot give you a totally clear answer but that is basically just the way the data structure is setup:

pos->tran.x, pos->tran.y and pos->tran.z are the 'translational' parts of the cartesian axis pose (ie X,Y,Z axes)

The other axes elements are just called pos->a, pos->b, pos->c, pos->u, pos->v and pos->w

Is this the part of the component/programming that changes the position of the joints?:

The lines with 'pos->* = j[*]' are part of the 'Forward' kinematic model (ie the section you have on your last post). This is used to calculate the AXIS position after the respective joint has been homed. In your particular case the axis is set the same as the joint.

The lines with ' j[* = pos->*]' are part of the 'Inverse' kinematic model . This is used to calculate that particular JOINT position according to the requested AXIS position. In your particular case the joint is set the same as the axis.

Note that in your CASE 1 the joints/axes mapping is actually trivial just like 'trivkins' and the only thing you do in CASE 2 it to swap the joints/axes

So each 'CASE n' in the forward model needs to have a matching reciprocal 'CASE n' in the inverse model. In other words, if you run a joint position value through the forward kinematic and you run the resulting axis position value through the inverse model you should get the exact joint position value you started out with. If the models do not match upyou will get unstable results (eg runaway values).

More specifically, when the kinematics switch is made is the above what causes the X and V axes DRO's to switch?

The switch is made using a case structure in the forward and the inverse kinematic:
Each case represents a kinematic model. In millturn.comp we have two but you can have as many as you like.
The 'switchkins_type' value is changed using an analog motion pin which is connected to a dedicated hal pin (see [HAL] section of the millturn sim config):

Bonjour a tous , 
 je viens d'acheter une nouvelle sonde 3d,je l 'ai brancher  a la place de l 'ancienne , mais j 'ai maintenant une erreur , j 'utilise linux 2.8.1, cela fonctionnait tres bien avec l 'ancienne, je pense qu il y a un parametre a changer , mais je ne trouve pas, pouvez vous m 'aider?dans le panneau de configuration de hal , j 'ai le signal.
merci

Hi, I’m new to linuxcnc and I am trying to get the rrw lab board to work. I’m trying to use the SPI sd card firmware with an STM32 Blackpill. The blackpill led is flashing, but there’s no connection. I can’t seem to find anything online about setting up SPI with a pi5. Any help would be appreciated. 
Thanks.

No, sadly not!
I tried various other things too, but nope.
I am going back to do a completely new install from scratch of Linux, etc. which requires a SSD shuffle between computers.
...

I think it might be more effective to create a dedicated component, rather than force carousel to fit.

But I think that Carousel will probably just keep the "motor-fwd" bit set high until the carousel is in the correct position, so the trick is to find a way to release the pressure and lower the carousel once the actuating cylinder hits end-of-stroke.
Is there a sensor for that?

The crude way to make this work might be to use motor-fwd to enable a siggen component that sends a suitably-timed series of pulses.

Aciera wrote:

one advantage of using switchable kinematics is that all joints can be homed normally on startup.

Trying to digest all this and a couple questions occurred to me...

Is this the part of the component/programming that changes the position of the joints?:

• CASE 1
  • pos->tran.x = j[0];
  • pos->v = j[2];
• Case 2
  • pos->tran.x = j[2];
  • pos->v = j[0];

More specifically, when the kinematics switch is made is the above what causes the X and V axes DRO's to switch?

Why does X has a 'tran' and V doesn't?  I saw that stuff in userkins.comp, but I can't find an explanation of the programming language/syntax.

 

endian wrote:

Yes Rod .. it is solution but it is creating constant delay between control position -> DFIR -> current position of tool ....
 

It will not add any delay as it should be applied as the acceleration is calculated or read per servo cycle. Just not sure how you need to use it. 
the size of the buffer is configurable.
Any other published moving average solution wanted to use loops which are a source of delay so I devised this..
One of the cleverest algorithms I have ever coded...

I don't think they do consultancy, but you are very close to the Mesa Electronics HQ.

You don't say what the inputs to and2.2 are. That is probably important.

A problem you will have is that spindle.0.index-enable is a bidirectional HAL pin, so can't be directly connected to the output of an and2 block.

You can probably work around this with linuxcnc.org/docs/stable/html/man/man9/tristate_bit.9.html

But, are you sure that your spindle encoder driver doesn't offer e direct, bidirectional, index-enable pin?

There is an example of an index-simulator HAL component here:
forum.linuxcnc.org/24-hal-components/388...ation?start=0#223508

It's written for a stepper spindle, but should work just as well (or just as badly) for an absolute encoder assuming that the encoder has an integer "counts" output.


I was going to suggest watching one bit of the binary counts value and tristate-bit. But that wouldn't zero the counts on index.

There _is_ a way to do it with a sample-hold to capture the counts at index, then subtracting that from the raw counts, that would need a bitslice, mux_generic (set up for signed int), edge, and tristate-bit HAL component.
It's do-able but at that point the custom HAL component makes more sense.

@grandixximo 
Do you have any idea what might be causing the delay in the DRO? 
It seems like the drives arent going into OP right away. The delay is always different. Sometimes the DRO is instantly filled with the encoder read (but converted to axis position) values, sometimes it takes up to 10 seconds. 

Could this also be part of the whole issue? The drives PRE-OP to OP delay. 

Hi all,I'm using a Mesa 7i95T and I need a bitfile with the following configuration:

• sserial on P1 (to read a MESA 7i87 for analog sensors)
• 1x rcpwmgen for RC servo control (MG995, 50Hz, 1-2ms pulse width)
• as many stepgens as possible with the remaining pins (ideally 5)

Currently I'm usingwhich has a standard pwmgen, but rcpwmgen would be much cleaner for direct RC servo control without needing external offset/scale calculations. Is there an existing bitfile that covers this, or could you compile one?Thanks in advance!

It is an older 15kw Tosvert that i repaired some time ago, dont think its in the modbus era. So traditional i/o it is. The servo drives only have 2-3inputs for internal use, like fault reset, homing switch and e-stop.

Yes Rod .. it is solution but it is creating constant delay between control position -> DFIR -> current position of tool ....

next stuff what Gemini tells me at Cloud of points topic is - 

* Look-Ahead Buffer CompressionConventional S-curves fail when the "Look-ahead" buffer is too small. If the planner only sees 10 points ahead, it doesn't know it can maintain $F500$ through the next 100 points.The Fix: Use a Compressor or Point Filter.In your trajectory planner settings, ensure the look-ahead is set to at least 100–200 segments.The Approximation: If three points are almost in a straight line, the planner should "ignore" the middle point. This turns a "Cloud of Points" back into a "Set of Vectors," which is much easier for S-curve math to handle.

(before noticed DRIF)
* The "Look-up Table" (LUT) Approximation
If the analytical math (solving cubic equations) is too slow for your CPU, you can use a pre-computed trapezoidal acceleration profile and apply a Finite Impulse Response (FIR) Filter.

The Method: Calculate a standard, "harsh" Trapezoidal move first. Then, run that velocity profile through a "Moving Average" filter.

The Result: The "sharp corners" of the trapezoid become smooth "S" shapes.

* Constraint Decoupling (Axis vs. Path)Latency often spikes when the planner tries to synchronize 3+ axes using 3rd-order math.The Fix: Instead of calculating a full 3D vector S-curve, calculate the S-curve for the Master Path (the total distance) and then linearly project that to X, Y, and Z.The Trade-off: This is slightly less "optimal" for machine time, but it reduces the math complexity by $66\%$, significantly dropping your latency.

* Frequency Domain Filtering (Advanced)
If you are writing the code for the planner, you can use a Low-pass filter on the commanded acceleration.
Generate the "rough" motion.
Pass it through a 2nd order low-pass filter (Butterworth or similar).
This effectively "limits jerk" by removing the high-frequency components (the "thumps") of the motion.

what I can see aproximation or longer thread timing are the only known solutions... but I am not expert in this topic