Snuggly's Plasma Build

GPIO11 is _not_ the input common pin (nor is the input common pin readable)

GPIO11 toggles because you are reading one of the SSR output driving pins (which are 1MHz square waves) so you will read random high/low values on this (and other) GPIO pins that are not associated with actual simple input pins, that is, all pins are readable as GPIO even if they have alternate functions.

You can for example also read the stepgen output pins as GPIO...

interesting. So it looks like everything is wired properly and the joint 3 limit is caused by something else.

Increasing soft limits didn't relieve the issue unfortunately. I've commented the line out for now while I figure out my z axis crashing issue.

I don't believe Snuggly has an actual limit switch on his Z axis.

The THC.hal he is using sets all three joint.3. hal switch pins to true when the logic thinks there is a Z axis error OR when it thinks the float switch (FloatSwitch) pin is true AND some logic of the M3 code (spindle.0.forward) and the torch state.

net TriggerLimit or2.2.out => joint.3.neg-lim-sw-in joint.3.pos-lim-sw-in joint.3.home-sw-in

net FloatAndTorchOn and2.5.out => or2.2.in1
#net LimitZ hm2_7i96.0.gpio.006.in_not => or2.2.in0

This is Tommy's hal so I will leave the logic functional details to him.

John

I've been trying to make sense of the code and my intuition was the same on the FloandAndTorchOn. I do have a limit on my Z axis, but it's commented out right now.

I cannot, no matter what I've tried, figure out why my Z axis crashes into the material and starts dragging itself across the surface and if I stop it, it locks up the machine. I've slowed the acceleration, increased it's soft limits checked ferror and nothing...

Why won't it offset after it hits the float and then try to fire the torch?

Do you have jogging control over the Z axis when in manual mode? This must work first!

Review all the notes in the thc-toma-stepper-final package. Make sure that your values make sense for an imperial units system. Pay particular attention to the signs of the parameters you enter. The switch offset (SwitchTravel) and pierce gap (PierceGap) both can cause big problems if the signs are wrong! Slow your Z axis response way down for openners, use a velocity of .1 ips and an acceleration of 5ips^2(these must be changed for both the axis and joint in the .ini), you can set it back to the correct range you established during your initial calibration after the motion is correct.

Manually create a simple Gcode file to test with. Just a single cut, either a straight line (6" to 8" long) or a rectangle. You will need the single straight line file for speed/voltage testing later anyways. Copy the format Tommy used in the cncbytoma.ngc file ( this file appears to have been generated by Gcodetools), this is in the thc-toma package, your file will have only one cut and only be a few lines long. Post the file here so we can see what is supposed to happen. A detailed description or video of any problems using the simple file will help the group figure out what may be wrong. Also single stepping the program will help determine which action is the problem.

John

I can jog every axis. I did adjust the inputs on the THC gui to imperial and specifically to my system. I will slow the z axis down further and write a simple gcode linear cut as you suggested. If it does not work properly, I will upload a video showing the error.

Thank you.