Advanced Search

thank you very much for that info, that should get me close to getting this working. One question i still have left open is why the motors don't enable when i have the pins set right for the amp enable. Or is there something different with this type of setup to enable the drivers? The thc300 config was missing the enable parts in the thc300_paraport.hal so i added the

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

as was in the simple configuration that worked fine moving the motors.

but when i hit the power button i don't get the normal hissing/ringing sound from the steppers and they will not move when commanded to.

I will change the things you suggested this evening.

Thanks again, really appreciate the help

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.

So i heard that EMC2 had a new configuration to start with for torch height control and i wanted to use it on my plasma table. I'm not liking mach3 much and i really want to get back to using EMC2 (before i had no THC and i had to switch to mach3 to get the functionality).

So i started with the thc300 config and found the pins in the .hal files and made them right. But for some reason it seems as though it thinks i'm running servo's with feedback going to emc because i get joint following errors. Also i can't get the motors to enable when i turn on the "power" (logical in emc).

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.

Here are the specs of the machine we built:

4x8 Gantry (dual motors on gantry (X axis).. )
THC301D connected to a second parallel port
A cheapo TB6560 4 axis driver board on the first para port

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. The ESTOP and Touch Probe inputs work fine so i know i have the right address for the 1st para port. And i'm using the same port # for the 2nd port as is in mach3. I confirmed the port with "cat /proc/ioports" and the address are correct.

Attached are the ini and hal files i'm using. any help would be greatly appreciated..

members.cox.net/jdsanchez473/cnc/axis_manualtoolchange.hal
members.cox.net/jdsanchez473/cnc/estop.hal
members.cox.net/jdsanchez473/cnc/kinematics.hal
members.cox.net/jdsanchez473/cnc/stepper.hal
members.cox.net/jdsanchez473/cnc/thc300.hal
members.cox.net/jdsanchez473/cnc/thc300.ini
members.cox.net/jdsanchez473/cnc/thc300_parport.hal
members.cox.net/jdsanchez473/cnc/thc300_vcp.hal

Well I'm kinda stuck

I'm at the point of removing any correction after the torch goes off and as the Z moves up.

I have a global variable last_z_pos and need to compare it with z_pos_out to see if the Z axis has moved up. Math is not my strong subject so I have to use brute force sometimes to figure it out.

So if last_z_pos < z_pos_out tells me if Z has moved toward the positive direction I need to remove some correction until correction == 0. I don't want to remove it so fast that if I had a positive offset when the torch turns off that I slam the tip into the material. Actually I don't what to remove it so fast as to cause a move in the negative direction...

Hints are welcome

John

And another piece of the puzzle falls into place this morning thanks to Vq^, SWPadnos, and Pythagoras of Samos. Thanks guys.

To get the actual XY velocity I sent the axis.0.motor-pos-cmd signal to a ddt component in to get the velocity out for the X axis and did the same for the Y axis. Now I have the velocity of each axis. Next I had to get the absolute value as I don't need direction information.

I did this in the THC component with:
Next I needed to find the combination of X and Y's velocity. As Vq^ mentioned that X and Y are orthogonal and that I needed to use the Pythagorean theorem to find the velocity. The SWPadnos offered up enough of the formula for me so I could figure out the rest.

using that I added:

now I have the velocity in user units per minute or in my case IPM.

All in all a very productive morning.

Thanks guys
John

Progress has been a little slow on the THC component but non the less progress has been made.

I used the lowpass algorithm on the input velocity to smooth it out just a bit and that works well. I've made up a test panel with pyVCP and can see the correction being created. I have a full PID in the THC component but so far have used only the P part. I also added a cap to the I so it won't just keep on adding up.

Next up the XY velocity... I need to compare the actual XY velocity to the set velocity and if I'm within range allow the correction to be applied if the THC is enabled.

John

At divide by 128 I get a resolution of 0.05 volts which is REAL good.

John

I tried the V-F board with a BOB and the parallel port and with the divide by 128 selected the pulse frequency was too fast for either the BOB or the parallel port or that computer so I gave up for the moment on that.

Moving on I connected the V-F board to the 5i20 and still in the divide by 128 mode the velocity numbers are rock steady and the voltage in to frequency out is flat as a pancake.



I'm excited now...

The next thing I figure is I want the THC to only be on when the spindle is on and I'm running a program. So I add an and2 component and hook halui.program.is-running and motion.spindle-on to the inputs.

loadrt and2 count=1
addf and2.0 servo-thread
net thc-prg-running and2.0.in0 <= halui.program.is-running
net thc-spindle-on and2.0.in1 <= motion.spindle-on

Now for this work I add a mux2 component.

loadrt mux2 count=1
addf mux2.0 servo-thread
setp mux2.0.in0 0
net thc-enable mux2.0.sel < and2.0.out

and I change the offset line to

net zpos-offset sum2.0.in1 <= mux2.0.out

and I change the input line to

net z-input mux2.0.in1 <= pyvcp.OffsetDial

So now if the program is running and the spindle is on the input from the offset dial will be added to the Z motor position command.

So far so good. Now I need to figure out how to prevent the Z from moving when the spindle goes off. For example if the material is warped up and I'm above Z0 and the torch goes off I don't want the offset to suddenly disappear and the torch slamming into the material. I gotta think on that one a bit... all suggestions welcome

After some thought on the way to work it seems like the best plan is to slowly remove any offset after the torch is off (M5) as the torch moves in a positive direction perhaps over the distance of 1/2" to the safe Z height.

John

I'm working on a Torch Height Control for my plasma cutter. My intent is to use an input into EMC to raise and lower the Z axis as needed to maintain tip voltage at the set point. I plan on using a velocity number from a 5i20 encoder as the signal to base the need of raising or lowering the torch. The 5i20 will get the pulse signal from a custom board into an encoder component.

The V-F board takes in 0-10vdc. It has 100K input resistance so an external 300M resistor will give a 0-310vcd input range. The V-F board is nominally 100 KHz to 1 MHz range for hardware inputs. The board has postscaler to divide the requency down to 32/16/8 full scale for software (parallel port) counting with a lower resolution for a given sampling rate.

Dallur has done some fantastic work on integrating commerical THC controls with EMC and Axis. I hope to expand that a bit for my application.

Well it seems to me the first place for me to start is to hijack the axis.2.motor-pos-cmd. The stock StepConf Wizard I started with generates the following for the Z axis.
net zpos-cmd axis.2.motor-pos-cmd => stepgen.2.position-cmd
net zpos-fb stepgen.2.position-fb => axis.2.motor-pos-fb

I added a sum2 component and I changed to:
net zpos-cmd sum2.0.in0 <= axis.2.motor-pos-cmd
net zpos-sum sum2.0.out => stepgen.2.position-cmd
net zpos-fb stepgen.2.position-fb => axis.2.motor-pos-fb

Then I added a pyVCP dial for my offset input:
net zoffset sum2.0.in1 <= pyvcp.OffsetDial

Now when running and I move the dial the Z axis will be offset by that amount.

So Far So Good...

John