Closed zz912 closed 1 year ago
-0 is valid in IEEE floating point. But .home_sequence is an int, so I agree that the setup wizard should not be using -0. (Or, possibly, should refuse to use 0 as the sequence number for a tandem joint. I haven't run a test to see how this happens)
I looked in the documentation: http://linuxcnc.org/docs/2.9/html/config/ini-homing.html#sec:homing-section
The initial HOME_SEQUENCE number may be 0, 1 (or -1).
This is NOT bug of motion, but this is a bug of PncConf.
Correct solution for my exmple is: [JOINT_0]HOME_SEQUENCE = 2 [JOINT_1]HOME_SEQUENCE = -3 [JOINT_2]HOME_SEQUENCE = -3 [JOINT_3]HOME_SEQUENCE = -1 [JOINT_4]HOME_SEQUENCE = -1
This works correct.
https://github.com/LinuxCNC/linuxcnc/pull/2660 covers this problem.
RIP 2.9 Branche Debian Bookworm Oracle VM VirtualBox
Hello,
Maybe I'll make an interesting machine with "X Y1 Y2 Z1 Z2" kinematics. That's why I'm preparing for this situation. I made the configuration "X Y1 Y2 Z1 Z2" by PncConf. I used it to simulate this configuration. Here are configuration sim files: Z0069_sim-003.zip
The homing sequence must be: 1) Z 2) X 3) Y
This creates a situation where the INI file contains: HOME_SEQUENCE = -0 Minus zero is not my invention. This was invented by PncConf.
The bug is that I can break the CNC machine in joint mode. I can move the Z axes asynchronously.
Automatic homing works fine:
Manual homing is very, very dangerous, I can home: 1) Z1 2) Y1 and Y2 3) X 4) Z2