THC experimental

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.

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 isThis opens up this axis screen that comes complete with a demo axis sim that plays with the Z axis


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.

I look forward to seeing the results!

I saw some notes about zeroing the offset and on the very last line of
ocs/src/motion/external-offsets.txt

Dewey says
" More complex hal implementations (like eoffset_demo.ini above)
+allow zeroing offsets without requiring a 'Machine-on/Machine-off' toggle."

So the answer is in his ini file somewhere

Found it I think. In the same doc file, he says

BigJohnT wrote:

I think that is so when you power up you don't get an unexpected movement. I need to remove the offset after the cut is done either as the torch moves up (like I did in the current thc component) or at some safe Z height.

JT

I understand, so the tricky bit will be sensing a safe height. Best of luck with it.