Problems with plasma-thc (thc300) Configuration

WoR wrote:

Another thing is that when it starts up it goes into joint mode, i do not want this, and i honestly don't know exactly what it is for. Also the acceleration in the axis gui says deg/min (or sec i forget). Why is it not in/min or sec.

Firstly, gantrykins is a kinematics module that allows you to map any number of "joints" to any number of "axes".

You have a 3-axis machine (X,Y,Z) with 4 joints (0,1,2,3). The kinematics.hal file links joints 0 and 3 to X, 1 to Y and 2 to Z.

Joint mode allows you to move each motor independently. Homing in joint mode should then auto-square your gantry.

There are a few issues in your config files which need sorting out to operate a gantry properly (stepconf is not really aware of non-trivial kinematics machines).

Firstly, you don't have an A axis, so should change the AXES = XYZA to read AXES = XYZ
The [AXIS_N] sections of the ini file are actually miss-named. They really should be called [JOINT_N] but are named as they are for historical reasons (don't change them).

Homing happens in Joint mode, so you need to have the same homing sequence number for joints 0 and 3 (in [AXIS_0] and [AXIs_3] in the ini file to avoid twisting the gantry during homing. Having no homing sequence defined (as you have) should also be fine.

I am afraid I am not sure how a gantry config is meant to work, I rather feel it should automatically switch to "World" (XYZ) mode after homing, but would need to experiment with a config to find out.

In any case, after homing you should be able to press "$" to switch to "world" mode, and I think you should then be able to jog without following errors. The following error is due to the stepgen.0.pos-fb and stepgen.3.pos-fb positions not both matching the X-axis position (if they are different, then clearly they can't both match).

With a basic configuration using the stepconf wizard it works fine. I set the X axis to the A pins and invert the direction so the gantry moves fine. And the Y and Z move fine. But i can't get much to work right with the thc300 config.

It doesn't really matter that your hal files call the X2 axis A, but it might be clearer to change the names to X1 and X2 throughout. (the signal names, which are the first item on a "net" command line, are freely choosable by the user). You have motor.3 linked to stepgen.3 and that is what matters.

I am afraid that this is a rather rambling post, and might not have clearly explained even the things I am trying to explain.

Is quite a nice explanation of the difference between Joint mode and World mode, on a simple system where they are clearly not the same thing. Part of the confusion with Gantrykins is that the joints and axes are so very nearly the same thing that is it not clear what the difference is.

WoR wrote:

t
net xenable => parport.0.pin-04-out
net xenable => parport.0.pin-05-out
net xenable => parport0.pin-17-out

I wasn't clear how many enables you needed for your 4 motors, but if they each have a enable pin, then clearly they need connecting too.

You can check that emc thinks it is setting them using the HAL meter, Halscope or Hal Config viewer in the "Machine" menu.

andypugh wrote:

Firstly, you don't have an A axis, so should change the AXES = XYZA to read AXES = XYZ

This appears to be incorrect advice. I am experimenting at the moment with a similar simulated config to try to understand it.

In the longer term, the ja3 branch of EMC2 will break the implicit link between joints and Axes. However it is not recommended to use that branch at the moment.

For the time being you will need to keep the AXES=4 and COORDINATES=X Y Z A and just ignore the A axis. (it should never move)

You will start in Joint mode, then when you home you can switch to World mode with "$".

Any time the motors get out of step with each other you will get a following error, and EMC will stop, not letting you re-start. The trick when this happens is to switch to Joint mode, where there will be no f-error and then re-home the gantry axis, at which point you can switch back to World mode and there will be no f-error any more. (manually jogging the joints in joint mode so that their positions are very close will also work, if re-homing the axis is not a good plan at the time)

WoR wrote:

I just wish it didn't have that many hal files to make it work. The hal's have parts commented out that are placed in other hal's and it just gets confusing lol..

It is, and I found it confusing too. This seems to be a consequence of the way that the wide range of sample configs are assembled.

I would suggest combining them all into one file. In fact in my setup I pretty much ignore the INI file too, and edit direct in one HAL file, just so I can see all the parts.

If you look at the parallel port enable pins in Hal Meter, do they behave as expected?

The "enable" connections on my amps are active-low. There is a +5V supply to the opto-isolator, and the P-Port pin connects to the low side and then current flows through the LED when the pin is low, and not when it is high. This is because P-Ports are a lot better at sinking current than sourcing it.

However, if your Mach setup works then it seems unlikely to be an issue with the external wiring.

This might be helpful: wiki.linuxcnc.org/emcinfo.pl?Parallel_Port_Tester