THC experimental

Andy,

Thanks for the link and info.
If that works as hoped it would certainly simplify things.

We did try a PID in the past with THC but was disappointed with the results. However I have limited experience with PID, and it may in fact work better with the new branch.

) After homing, support external axis offsets for
a) teleop (world) jogging
b) coordinated motion (gcode)

Not sure how coordinated motion would be effected with a THC comp or if that could effect blending.

Pretty sure you meant "G01 Z10 will move the axis to 10." not G10

Rick G

Hello

I am following this with great interest. I am afraid that some of the discussion here is quickly going far above my knowledge of lcnc.

FWIW my commercial THC uses the P and I terms of a PID control. The output of the control when servoing to the arc voltage is a position correction (encoder counts) sent to the servo motor controller (Anamatics Smart Motor).

I looked at Dewey's branch and it didn't make much sense to me because of my lack of knowledge of lcnc. Is the short summary of his work that he has modified the motion component to add an offset summer with scaling to each joint? The external connection is handled through a new HAL pin, axis.N.external_offset? I haven't gotten my head around the value being a fraction and the changes to the limits but I just started looking at this. Can the same general thing be done by connecting a sum2 component between the axis.N.pos-cmd motion output and the PID or stepgen input? Where one input to the sum2 component is the axis.N.pos-cmd and the other is the correction from a THC component?

rodw

The halcompile works exactly as in the docs. I have modified JT's THC so that it has pins that work directly with the Gmoccapy Plasma screen that I have modified. I have also added the arc voltage sample mode of operation to it. I appears to work with my simulation setup now. It is not a finished work as quite a bit still requires the correct connection of external hal parts between the GUI and the hal component. The short story is with the programming skill you have this is easy.

All is this a better place to discuss new THC related things or should I continue in the general and gmoccapy sections?

John

islander261 wrote: Can the same general thing be done by connecting a sum2 component between the axis.N.pos-cmd motion output and the PID or stepgen input?

Yes, but then you need to lie about the feedback, or you get a following-error.
To make that easier, the "offset" component exists.

However the problem with that is that axis travel limits, velocity limits and accel are not honoured. But they are with the external_offset pin.

islander261 wrote: Hello


rodw

have modified JT's THC so that it has pins that work directly with the Gmoccapy Plasma screen that I have modified. I have also added the arc voltage sample mode of operation to it.

John

John, I will be very interested in reviewing your sampling code. I've been a bit distracted as there is an error with homing in Gmoccappy which gets very confused if a Joint Axis exists. The most critical error is that it allows a user to home one side of a gantry without the other being moved which sounds very bad to me. I am revising Norberts code to do it properly in the hope that future upgrades don't break any changes to Gmocappy itself. You might like to check this with drive disconnected to your gantry.

Back on the experimental topic! I'm still waiting for a 64 bit ADC shield to arrive for my Arduino. I've played with the Arduino SDFAT libray and with a 16 Gb Class 10 MIcroSD card I have found it can write 512mb blocks of data at a sustained rate of 764 usec per block. That is fast enough to be able to log data during the cut for offline analysis. I was hoping this would help develop better height sampling and volt reading algorithiims.

Dewey is making progress on the external offsets branch but I've been swamped, still need to upgrade the plasma PC to Linux Mint 18 to be able to use the branch. I can't see why it won't be a winner with a PID thc component.

JT

Well, I finally worked out how to checkout another development branch today and had a look at Dewey's experimantal code. I thought I would report on some findings for those following along but not really knowing what to do.

Anyway, if you've compiled LinuxCNC from source, getting the code is dead easy.
To go back to master its just a matter of doing the same above but substitute the first line for
This extends the motion component and adds some extra pins for each axis.

Dewey has added a couple of sims to demonstrate external offsets and the one want is This opens up this axis screen that comes complete with a demo axis sim that plays with the Z axis
image missing http://i210.photobucket.com/albums/bb270/rodweb/Lathe/Plasma/jwp_z_zpsod6ys0hb.png

So run the gcode and pause it. Note you can change the offset spin box and each click of the increment or decrement buttons will move the Z up or down by the amount of the offset. You can see the white line is the commanded position, the red line is where we've travelled and that I've hit the increment button a number of times to move the Z axis up. Each time I hit the increment button, the axis moved up by the offset amount.

So can you see some similarities between this and a THC?

Dewey says: Here is what the jog wheel docs say on this link:
linuxcnc.org/docs/html/man/man9/motion.9.html

axis.N.jog-counts IN S32
Connect to the "counts" pin of an external encoder to use a physical jog wheel.
axis.N.jog-enable IN BIT
When TRUE (and in manual mode), any change to "jog-counts" will result in motion. When false, "jog-counts" is ignored.
axis.N.jog-scale IN FLOAT
Sets the distance moved for each count on "jog-counts", in machine units.

So to build a THC component on steroids, it seems it is just a matter of what is handled by the external offsets, the THC and the PID components. I hope that description helps some followers. It has helped me get a bit of clarity on this too. I've still got a lot to get my head around myself.