Basic questions about QtDragon_hd and seemingly odd behaviour

Hello all!

I am currently building a small CNC router using LinuxCNC and QtDragon_hd as GUI. The GUI loos great by the way!

I am having some difficulties on tackling last oddities/bugs out of my system so any help would be greatly appreciated here.

I configured the machine to use XYYZ kinematics with kinstype=both. However my machine axis layout is actually YYXZ as how the axis are arranged in respect to each other. Does this have any impact on the operation? I tried changing the kinematics configuration to YYXZ from .ini file and remapped the joint-pins to the correct drives to reflect the new kinematic configuration. The machine jogs and moves correctly in the coordinated mode (after homing) but joint moving (before homing) seems to be messed up after the change. The Z axis buttons are only ones that can be pressed and they seem to drive the X axis. Y and Z axis buttons throw a message that "cannot jog joint N because home sequence is synchronized". The X axis has only motor so that at least should not be synchronized axis.

Other issue is with MDI. The machine oddly moves all three axis even when one axis  is commanded to move. Ill give you some examples:

(Using the YYXZ kinematics model)
1st move is G0 Y50: Machine moves as expected only on one axis
 

2nd move is G0 X50: Machine moves on Y and X axis 
 

3rd move G0 Z20: Machine moves on all three axis
 

If I hit Esc in between the MDI commands it seems to move only one axis at the time for the first command I input. I bet this is some kind of mode I am not figuring out here. I think QtPlasmaC and some GRBL CNC controllers just moved the axis you typed to G commands and you could omit the other axis references from the line. As a note here that the machine moves indeed correctly if I always type in all the axis coordinates on all lines.

Any help would be golden here!

How did you get linuxcnc on the system?
This bug behavior seems familiar but should gave been fixed already.
Could you post your configuration fukes?

cmorley wrote:

How did you get linuxcnc on the system?
This bug behavior seems familiar but should gave been fixed already.
Could you post your configuration fukes?
 

Sure!

I used Rodw's excellent installation instructions on how to install the LinuxCNC on Debian Bookworm. So I installed Bookworm Linux first and then from the package manager the LinuxCNC. I have run the apt update/upgrade commands couple of time since installation and this is quite a new system anyway,

I packaged the Ini + hal files into a .zip package

 

JiiPee wrote:

I used Rodw's excellent installation instructions on how to install the LinuxCNC on Debian Bookworm. So I installed Bookworm Linux first and then from the package manager the LinuxCNC. I have run the apt update/upgrade commands couple of time since installation and this is quite a new system anyway,

Did you do a 
sudo apt update
sudo apt upgrade

This give you the absolute latest version of  V2.90 from the buiildbot (If you set up apt pinning as I describe in the getting linuxcnc docs.)
I finalised my ISO installer last night that bundles all of the techniques in the docs into an ISO. See the sticky under installling linuxcnc section.
Main recent changes were just around best practice with some of th eexternal repos it conencts with

I confirm the behavior on the latest 2.9.
I think the joint jogging code assumes X is always joint 0.
I'll look into it.

I'm curious why YYXZ is better then XYYZ ?

I pushed a (hopeful) fix for this.
Not sure how long it takes to come out.

Hello Rod!

I will check out the apt pinning. Could be I skipped such a step and I have indeed ran couple of times both of those commands but I might as well recheck. What would be easiest way to check and list out which versions I actually am using currently from all of the LinuxCNC components?

cmorley wrote:

I pushed a (hopeful) fix for this.
Not sure how long it takes to come out
 

Ok thanks!

I have no idea if there even is a difference between XYYZ or YYXZ. Actually that was the first part of my question that should I match the kinematics with actual reality or is it totally irrelevant when using trivial kinematics. With actual non-trivial kinematics like a 6 axis robot the order of the joints play a huge part on the calculations but I guess in this case it doesnt really matter. 

I was just wondering why joint jogging mode only allows jogging of X axis before homing is completed. The gantry (Y axis) I understand as it could misalign and bend but X and Z have only one motor and should be safe to jog even before homing. 

There is no difference with the joint order.
The Developers (Cmorely included ) missed a great opportunity with the release of V 2.8 and the new Joint axis by not configuring  stepgen and pncconf to use joint numbers (0,1,2) rather than x,y,z etc
I have done this, and it makes sense with ethercat devices where slaves are numbered from 0.

I find it makes  your hal file so much cleaner to read and then the only mapping that define which joint is which axis is the
COORDINATES =  YYXZ in the ini file

It will never change now.

rodw wrote:

There is no difference with the joint order.
The Developers (Cmorely included ) missed a great opportunity with the release of V 2.8 and the new Joint axis by not configuring  stepgen and pncconf to use joint numbers (0,1,2) rather than x,y,z etc
I have done this, and it makes sense with ethercat devices where slaves are numbered from 0.

I find it makes  your hal file so much cleaner to read and then the only mapping that define which joint is which axis is the
COORDINATES =  YYXZ in the ini file

It will never change now.

Heh missed opportunity!

I have actually 4 ECT86 Ethercat drives here for my steppers/hybrid-servos. My lcec slave numbers are 0 = X, 1 = Y1, 2 = Y2, Z = 3. Would it then make more sense to indeed use the standard XYYZ kinematic mapping or did I understand your reasoning correctly?