Advanced Search

That points to hardware issues, are you sure:

The index wiring is correct.

The encoders actually have an index output.
 

i do that, but never nothing

Note that 'genserkins' uses 'modified' DH parameters.
Have a look here (there is also an example of how to derive the parameters for a manipulator):
www.linuxcnc.org/docs/stable/html/motion...ml#cha:dh-parameters

Do the joints not move at all when you try to home them?

As a short-term expedient you can turn off the requirement to home (INI NO_FORCE_HOMING) and (if you are using the Axis interface) switch to world mode with Ctrl-$.

But don't forget that then the machine will have no idea where the joints are, so the end-effector motion will be a very curly version of cartesian.

"Bad character" should tell you which line of the G-code the error is on. This is much more likley to be a problem in your G-code than in the G71 code. (not that I exclude that possibility)

At a guess you have closed-loop control of the spindle, but the PID is being commanded by absolute spindle speed request.

I am not sure why you used Stepconf at all. You should have been able to just copy the old "linuxcnc" directory from one drive to the other, and carry on as before.

M3 probably _could_ be remappable. It would just need the hooks adding to the code. After literally seconds of contemplation I can't think of anything that means it fundamentally couldn't be remapped if the code was modified to handle it.

The issue is that I'm not even able to move the robot arm, because it requires me to perform a 'Home All' operation before initiating any movement. I'm 90% sure that the problem lies in the incorrect application of DH parameters on my part. The tricky part is that it's so simple, I have no further idea what could be going wrong. I've been stuck at this point for a couple of days now, and still no progress. Later, I plan to rebuild the project from scratch to avoid any unnecessary correlations with the original Puma source files. Maybe that will help.

My guess would be that you lost the { at the end ofor possibly the one that terminates that set.

If you still have the good and bad files, then could you attach them? I don't think that I can make the compiler more helpful in it's error messages, but possibly the preprocessor could be.

How good are the clones they sell o AliExpress?

Has anyone tried one of these on a Nena 23 motors.

embeddedtronicsblog.wordpress.com/2020/06/24/tmc2160/

Note that all that I know about kinematics is that it confuses me...

Forward kinematics takes the joint positions and calculates the end effector position. This will always work and will always return exactly one solution.

Inverse kins takes the required end effector position and calculates the joint positions to achieve that. Sometimes there is no solution (because the arm simply can't reach that point). Sometimes there are multiple solutions (in fact there _generaly_ are.
So, the kins has to choose a solution. And sometimes it can lock itself in a corner, where there are solutions for the current position, and for the next position, but it would have to pass through a "wrong" position to get there.
This isn't just robots. I am sure you have been in this position with your own arms.... The difference is that you have a brain and are not blindly following what is basically a relatively simple mathematical equation which has no predictive capability.

So, back to your questiion: Homing happens in joint space, using forward kinematics. So presumably you only see the error after homing is completed, and the system switches to "world mode" and inverse kins.
Maybe your home position (in XYZABC rather than joint angles) simply isn't reachable? (or, doesn't _actually_ correspond to the joints-homed position?)

I see.
Looking at line 2968 makes me think that 'hide pyvcp' was simply not intended to be persistent by the original author:
github.com/LinuxCNC/linuxcnc/commit/6948...6d967654a7R250-R2968

Cześć.
Jak udało Ci się wyświetlić paski obciążenia servo w Probe Basic? Czy zrezygnowałeś z nich? Ja również używam tej karty od Dmitry'ego i jestem ciekaw, jak to rozwiązałeś.

Hi,I am currently developing control software for a 3-axis robotic arm using LinuxCNC together with a Mesa 7i96S motion controller. Everything has worked well so far, until I ran into issues related to the Denavit-Hartenberg (DH) parameters defined in the HAL file.As a base, I used the Puma560 example, which worked correctly with the default DH parameters. However, after replacing them with my own DH values, I started encountering problems. Specifically, I’m unsure how to properly handle fixed theta values within LinuxCNC’s DH parameter structure, since there seems to be no direct way to set them.I have created a precise mechanical model of the robot and derived the necessary DH parameters accordingly. Despite this, I consistently receive an "Inverse Kinematics Failed" error whenever I attempt to run the "Home All" sequence for the joints.I’ve attached both the DH parameter values and a visual representation of the robot. The actual robot has 5 axes, but for the purposes of this project, I am controlling only 3 of them using stepper motors to keep the setup simple. I would be very grateful for any advice or guidance on how to resolve this issue.Best regards,
Lex