Help with QTplasmaC

bevins wrote: Why dont you create a 3 axis 4 joint machine with axis working first. I agree it is a bit confusing but, plasmac started in world mode with the 4 joints showing then you home and it changes mode and you see the three axis.

You really mean that axis or gmoccapy started in world mode. This was dependent on how the GUIs were set up, and also is dependent on settings in your ini file. The plasmac component was loaded on top of axis or gmoccapy.

I point that out because I think there is sometimes confusion around what QtPlasmaC is responsible for, and what it is not. Similarly there is probably some confusion around where the line between Axis or Gmoccapy ended and plasmac began.

QTplasmaC doesnt show that, I believe it is starting in world mode and shows the three axis and you can jog but will rack the gantry until you home all axis. If your ini and hal file is correct, it will home the tandem axis properly. Once you have a working 3 axis tandem machine then install QTPlasmaC.

You can prevent racking the gantry by having a negative sign in front of the HOME_SEQUENCE variable for the joints that make up your gantry motors. A byproduct of this is that it will prevent jogging until it is homed. (you can read more here: linuxcnc.org/docs/html/config/ini-homing...l#sec:homing-section )

I use this on all 3 of my axes (personal preference) so the user can not jog anywhere until it's homed. That prevents running off the track, etc.

Example:

Joint_0 (X for me)
HOME_SEQUENCE = -2

Joint_1 (Y for me)
HOME_SEQUENCE = -3
Joint_2 (Y for me)
HOME_SEQUENCE = -3

Joint_3 (Z for me)
HOME_SEQUENCE = -1

This will require homing before jogging of all three axes. Further, it will home Z, then X, then Y.

Clive S wrote:

snowgoer540 wrote: Just took a peek at your config.

For Joints 2 and 3 (Y) you have STEPGEN_MAXACCEL at 1250. Whereas for Joint 0 (X) you have it set to 2500.

I remember when I was chasing a following error in the past, PCW had me raise the stepgen_maxaccel values. Try making Joints 2 and 3 STEPGEN_MAXACCEL match what you have for Joint 0. This could be why you can jog in X but not in Y.


It's impossible for me to say why your config for PlasmaC worked without seeing it to compare to the QtPlasmaC config you've been hand editing. Is it possible for you to post that here?

Yes there are different motors and drives on the gantry. They work fine with the above

My apologies, I saw this post forum.linuxcnc.org/plasmac/42283-help-wi...smac?start=30#206352

and then the one after it saying you were going to do hal plots. I missed where you got it fixed! Glad to hear you got it going then.

snowgoer540 wrote:

bevins wrote: Why dont you create a 3 axis 4 joint machine with axis working first. I agree it is a bit confusing but, plasmac started in world mode with the 4 joints showing then you home and it changes mode and you see the three axis.

You really mean that axis or gmoccapy started in world mode. This was dependent on how the GUIs were set up, and also is dependent on settings in your ini file. The plasmac component was loaded on top of axis or gmoccapy.

I point that out because I think there is sometimes confusion around what QtPlasmaC is responsible for, and what it is not. Similarly there is probably some confusion around where the line between Axis or Gmoccapy ended and plasmac began.

QTplasmaC doesnt show that, I believe it is starting in world mode and shows the three axis and you can jog but will rack the gantry until you home all axis. If your ini and hal file is correct, it will home the tandem axis properly. Once you have a working 3 axis tandem machine then install QTPlasmaC.

You can prevent racking the gantry by having a negative sign in front of the HOME_SEQUENCE variable for the joints that make up your gantry motors. A byproduct of this is that it will prevent jogging until it is homed. (you can read more here: linuxcnc.org/docs/html/config/ini-homing...l#sec:homing-section )

I use this on all 3 of my axes (personal preference) so the user can not jog anywhere until it's homed. That prevents running off the track, etc.

Example:

Joint_0 (X for me)
HOME_SEQUENCE = -2

Joint_1 (Y for me)
HOME_SEQUENCE = -3
Joint_2 (Y for me)
HOME_SEQUENCE = -3

Joint_3 (Z for me)
HOME_SEQUENCE = -1

This will require homing before jogging of all three axes. Further, it will home Z, then X, then Y.

Axis starts in world mode because of the tandem axis and shows the joints instead of the axis like QTPlasmac. If you jog a joint in world mode it will rack the gantry no matter what settings you have in the ini, That's not negotiable. At least thats the way it is on the 20+ machines I have done. If you start QTPlasmac on a tandem axis machine and jog before homing it will rack the gantry.

From the link about homing I posted above:

Joint mode jogging of joints having a negative HOME_SEQUENCE is disallowed. In common gantry applications, such jogging can lead to misalignment (racking).

Other source: My table is set up as I typed out above, and it definitely does not jog at all before homing, let alone rack the gantry.

snowgoer540 wrote: From the link about homing I posted above:

Joint mode jogging of joints having a negative HOME_SEQUENCE is disallowed. In common gantry applications, such jogging can lead to misalignment (racking).

Other source: My table is set up as I typed out above, and it definitely does not jog at all before homing, let alone rack the gantry.

I am pretty sure (with plasma with axis) can be jogged before homing BUT it uses different keys than when it is homed .

This is with the normal setup ie -ve sequence for the gantry and +ve for the Z etc.

[kins]
something something kinstype=both
That at the end will decide if you can jog or not while in Joint mode before homing the machine.
I always set it so it can not jog Y (tandem) axis without homing, but X and Z can be jogged before homing.