Gmoccapy - A new screen for linuxcnc

Hi Todd
Did you compile and install the component that I attached before?

You have to connect the set-voltage-in to the plasma screen tip voltage and then connect the arc-voltage-in to the analog voltage that you got from the mesa card. Now use the up and down signals to connect to the corresponding signals of the THCUD component. Do a "man thcud" to see what is required.

In short, the comp I attached will look at the incoming arc voltage and compare it to the set-voltage. If it is too hight it will set the "down" signal and if it is too low it will set the "up" signal. There is a signal called voltage-window. This allows you to set the window size for the comparator. The THCUD component will use these two signals to adjust the Z axis up or down and thus follow the material.

This thc200 component just replaces a piece of hardware that gives up and down signals. THCUD is usually used in conjunction with a hardware voltage comparator. thc200 is used when you just have an analog signal and simulates the hardware. For the rest you use THCUD as the help describes.

Hope this helps a bit. I should really do an example config for the wiki soon.

Let us know if you dont come right and I will try and do you a sample config.

Its a bit sad to use an up/down THC comp when you have the actual arc voltage.
Better dynamic performance would be possible by using a real PID loop
for the torch height.

I have to agree with you fully. There are several difficulties to overcome due to the fact that you are not actually controlling the Z movement through the motion software. We capture the Z the command, which is static value that never changes until the next pierce, and then we induce Z movement without having any acceleration or motion synchronized information. There is actually no Z movement when doing 2.5D cutting but there is a lot of probing and adjusting going on and then a G1Zxx is given before the G1XxxYxx is given. Z is not synchronized to the other axis at all.

Plasma and THC defies the rules of CNC in the sense that the work piece moves all the time and you dont have a static reference any more. At least in the Z plane.
We have s sort of acceleration compensation built into the THCUD component and that works really well. Not a neat and technical correct solution but it works.
I am working on a component that will attempt to control the Z axis in a more suitable fashion but I have a lot on my plate so it takes a while.

P.S. The more expensive PRO systems does not use the Z axis of the motion controller but has a separate hardware controller that drives the Z independently. It acquires information from the controller via serial comms or input pins and does its own thing from there. I.E. the M3 would give it the signal to cut and it would give a signal back when motion can continue.

LAIR82 wrote: CSS in Gmoccapy does not function correctly from MDI

What I found is, if you try to invoke G96D800S450M3, from MDI, it starts at 800 and stays there, at the cap speed, regardless of where the X axis is at, if and when you go back to MDI, and enter g92x.....z....., ( whatever the DRO says for its current position) then it will automatically kick the spindle down to whatever RPM it should be at for the given diameter is, it is sitting at, then speed up and slow down accordingly.

Apparently it is not looking at, or taking into account its position, to set it at the correct speed. So you cannot start in CSS from MDI to make a manual cut, or run from line with the spindle started correctly for the cut.

I verified this using the Axis GUI, and in Axis the machine will start off at the correct rpm for the given size in MDI, and go up and down accordingly.

I submitted a bug report for this.

Let me know if I can be of any help in troubleshooting Norbert.

Thanks

Rick

Hello Norbert,

Just wondering if you had a chance to look at this, or if you maybe had an idea of what may be causing it?

Thanks

Rick

One other question,

We just bought 2 vertical lathes, and they are both going to be retrofitted to linuxcnc, and we would like to keep the continuity thru the shop and stay with one GUI. How hard will it be to change Gmoccapy to to represent a vertical lathe vs a horizontal lathe?



Rick

PCW wrote: Its a bit sad to use an up/down THC comp when you have the actual arc voltage.
Better dynamic performance would be possible by using a real PID loop
for the torch height.

I agree, I have really been struggling with the thc.comp, it may work OK with steppers, but with a 7i77 and servos, the " Hijack positon command and feeback through thc " from the plasma-5i20.hal to linuxcxc throws off the servo feedback and causes all sorts of problems. ( I'm using the mesa.plasma-5i20 config file as a reference, but I am using a 5i25, 7i77, thcad setup )

I am trying to get this working correct in Axis first, then I can try transitioning to Gmoccapy.

It seems like a PID loop may be the only alternative on a servo system, but this is way over my head.

Todd