Gmoccapy - A new screen for linuxcnc

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

Actually the stepgen has similar issues to a full servo system in that the offset has to be appled to both command
and feedback signal. Newer stepgen configs use the PID component so are not really any different than servo configurations.
with some minor changes (The stepgen has built in acceleration limiting while servo systems do not is one difference)

Is the plasma.5i20.hal config the best way to start, or is there a better way to tie in THC?

I'm willing to do some experimentation and testing.

By the way, the mesa cards are great, I went from 250 IPM rapids using mach and geckos to 1600 IPM rapids using Linuxcxc, AMC drives with the existing motors and encoders! ( it flies! )

Todd

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 )

Ah Todd now if you told me that you are using servos on the plasma machine I would have told that that the component only works with steppers.
If you want to use servos then the Z axis is handled as a separate entity that does not form part of the motion system. Unfortunately I am still working on the component that will handle that.

Are you capable of writing C or python code? If so I could help you in the right direction.

I did mention that plasma screws with the rules hey

mariusl wrote:

I did mention that plasma screws with the rules hey

Plasma really does change the rules, I have things almost functioning, but it is far, far from correct. I've had to set the servo ferror and min_ferror to ridiculously high numbers because Linuxcnc sees the THC offset as a ferror. I've also had to set the Z soft limits to huge numbers, because the offset is cumulative.

I think the worst problem is there is no speed or acceleration when the THC offset is turned on or off, it just bangs the z axis into position 1000x faster than a rapid speed. It slams the 4" of travel on the z into position in milliseconds, I had no idea it was capable of moving that fast. I'm sure it wont last long if left this way.

I can muddle through C and Python, any tips, ideas or pointers would be greatly appreciated, I would like to set it up as a separate entity if possible..

Todd

Plasma really does change the rules, I have things almost functioning, but it is far, far from correct. I've had to set the servo ferror and min_ferror to ridiculously high numbers because Linuxcnc sees the THC offset as a ferror. I've also had to set the Z soft limits to huge numbers, because the offset is cumulative.

As I mentioned you have to apply the offset to both the command and feedback signals in hal so linuxcncs motion component sees no
change.

I think the worst problem is there is no speed or acceleration when the THC offset is turned on or off, it just bangs the z axis into position 1000x faster than a rapid speed. It slams the 4" of travel on the z into position in milliseconds, I had no idea it was capable of moving that fast. I'm sure it wont last long if left this way.

This is because the thc component uses the stepgens acceleration limits. for a servo system you need to limit acceleration
when you apply and remove the THC offset. It might be that the easiest way is to add a LIMIT3 component to replace the stepgens accel limit
(just like using an external PID comp is probably the easiest to get full proportional control)

PCW wrote:

As I mentioned you have to apply the offset to both the command and feedback signals in hal so linuxcncs motion component sees no
change.

(just like using an external PID comp is probably the easiest to get full proportional control)

If the offset is fed back to both command and feedback, the z will do unlimited acceleration on initial g1's ignoring the "F" setting, also the g92's and any offsets or Z movements go completely wonky, you really don't have any idea where the z is going to go if you do a G01 Z0.

I am very interested in using your idea of an external PID comp, I just need a nudge in the right direction.

Thanks again

Edit: OK, I just found info on the LIMIT3 you mentioned, I will dig into it.

Edit #2: I think the reason the z numbers go crazy has something to do with the DRO's showing the offset reading, but the height on the preview screen does not change., also it seems like calling a z movement while there is offset applied will trip a limit, even with the soft limit set at -10, +10 inches