Advanced Search

Aciera, thank you for your reply.

While waiting for your reply, I also crammed on five-axis kinematics. Your suggestions are very helpful. Using computer-aided calculations can indeed avoid many errors, and I've carefully read the article, hoping to understand it.

Looking forward to my good news.

Respectfully yours.

 
Hi, looking for a cheap AC servo drive that works with an AS5047P magnetic encoder (ABZ output). Motors are 220V AC. Anyone found a working cheap combo?

1. Is it necessary to use the tool tip coordinate system as the basis for deriving the kinematics?
 

Not sure what you mean by 'the basis' but in a machine kinematic model we usually want to find a transformation between the work coordinate system and the tool coordinate system so in that sense I would say it is necessary to use the tool coordinate system.

2.  Note that the kinematic in the paper you refer to has both rotations on the work side (ie table rotations) while your setup has one rotation on the work side and one on the tool side. This means that both (tool and work) coordinate orientations can change with respect to the world coordinates ('world' can be seen here as the machine frame). I'll attach a different pdf that handles a very similar setup as yours. It is a bit more complex as it describes a nutating spindle joint but in your case the nutation angle would simply be 90°. There is also a second kinematic model that can be used for 'Tilted Work Plane' machining.



[edit]
There are a LOT of ways to get a kinematic model wrong so I would recommend using computer assistance to do the matrix calculations. You can find the corresponding jupyter notebook here:
github.com/Sigma1912/LinuxCNC_Demo_Confi...tary/xyzbc-sntr-docs

In an Ethercat world, I think you can use a Beckhoff 0-10 volt analog interface as it has similar over voltage specs as the THCAD. People have cracked the Hypertherm Ethercat machines here. But do use industrial Ethercat cables in a HF world

Todd wrote:

Wouldn't the proper way to invert a PWM be to use a negative value for the PWM scale? (setp pwmgen.N.scale = negative value)

I thought this too. But I was wrong!

PCW wrote:

For unsigned PWM when 0% duty cycle PWM gives you full scale output
and 100% duty cycle gives you 0% output, you would need to digitally invert
the PWM pin (and this is the situation here AFAICT)

Peter has it right. You need to use the parameter for the pin to invert it

setp parport.0.pin-01-out-invert 1

I recently bought an old plasma + oxyfuel machine to retrofit and resell. I awaits me first finishing some other projects. I plan to connect ethercat servos directly to a linuxcnc pc. I have not yet studied the serial interface for the big XPR plasma power unit that came with it. On a previous project I used mesa + THCAD, never heard any complaints from that one.

Welcome. Have a look in the ethercat section. There are a couple of stickies. There is a seperate Ethercat master application that runs on the Linuxcnc  PC and there is another driver that connects Linuxcnc to the Ethercat master which in turn talks to all your slaves. You should be able to use a Beckhoff analog input (0-10 volts) to read the divided torch voltage. Other than that, it will be similar to what Tommy described for Mesa hardware. The Beckhoff modules are rated for over voltage of 500 volts, same as the Mesa THCAD. I'm uncertain that other brands of analog inputs have this protection. I can't help with oxy.

how do i join it?

No worries, just trying to prevent you wasting time and wondering "why it does not work" if you make the same typo where it actually matters.

PCW wrote:

One advantage of the MPG encoders over the normal high speed encoders
is that the MPG encoders support the 1X mode, which means you get one increment
per click on standard 100 PPR MPG dials.
 

One advantage of the 1X mode is lack of direction information...
Standard encoders have no clicks...
In mpg encoder's count is scaled and can be divided by four... 
 

Ah, sorry, it was late. Of course, I mean "LOG_LEVEL = 0".

During cutting or at idle?
-
If during cutting, check grounding, if it is shallow under ground, the ground getting dry will cause that.
If at idle, there are a lot of things that can cause that, like other machines in the shop, changing the power socket, stepping on the wiring, wiring isolation failing somewhere due to fatigue and/or strain, and if in Europe, even your neighbor installing a new air condition unit, etc etc.
A simple solution to remedy the latter, use a 0.01 to 0.022 uF (also known as 100-220nF) capacitor on the THCAD input.
I use a 0.1uF electrolytic one rated for 50V but that might lower the reading speed, although for me it works perfectly fast till 6m/m, i have not tested it faster.

Hey when i first built my table my thc would read only + or - 1-2 volts over time its gotten worse and worse now it reads + or - 8 volts or so. Any idea whats causing this? Its running off raw arc voltage with a bunch of resistors in series. 

Thank you for your reply. Currently, my kinematics has coordinate offsets of (Xrc+Xos, Yrc+Yos, Zrc+Zos) when A=0, C=0. As you mentioned, "the coordinate values ​​remain consistent when switching between simple kinematics and RTCP kinematics." Therefore, it's certain that my kinematics might have a problem. I also have a few questions:

1. Is it necessary to use the tool tip coordinate system as the basis for deriving the kinematics?

2. I noticed an article on kinematics derivation, which I've attached. After deriving my machine tool kinematics using it as a standard, can I directly replace the XYZAC kinematics code in my code? Or do I need to do something else?

I will immediately put these two questions into practice.

Looking forward to your reply.

boink.
I think everything works now. got help with the correct updates on the ethercat patches/version. I geared down the 4th axis, so it can do 1600 turns now. not a proper fix, but it will get me cutting today and we can figure out a more correct rollover later.

As always, thanks for all the help.