Gmoccapy - A new screen for linuxcnc

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