Advanced Search

Or not. it still faults randomly on xyz. we did not find a fix, but we did find the "cause" and created a patch plan which I will do in the morning.

Basically, if you watch PLL error, you see occasional spikes. Spikes that hit a threshold of about 100000 (this number is relative to the refclocksynccycles) trigger a DC phased even dropping it to 0. these only last one frame. They do not seem to ordinarily cause an issue. Once in a while (could be a minute, could be an hour) we get a joint error on one or all of the xyz axes which are omron, but not the A which is leadshine. When you look at this error in the scope, it comes a few frames after a pll error spike, and it EITHER sends the position feedback to 32 bit int rollover, OR to 0. Hence, joint error. I did notice that SOMETIMES we get a bad position value that does NOT roll over or go to 0, and this then gets corrected the next frame, and there is no joint error.

We can induce more events by changing refclocksynccycles form -1 to 300, and a value of 1 totally prevents anything from starting for more than a few seconds.

Why this occurs seems to be about timing, or maybe interference or noise corrupting values. hard to say still. Why is it seeming to be only the omrons? Other people have reported joint errors as well, perhaps we need to compare notes.

ANYHOW... the solution is just to filter the "actual position" feedback and remove any invalid frames. They are pretty easy to spot, if you are at 8000000 counts, and suddenly it goes to 0, or 2.1 billion, we just replace that value with the previous. Since we are in CSP mode, this doesn't have any effect.

The filter needs to be a bit smart, and check back 3-4 frames I think to detect the trend of motion. I shall figure that out in the morning and once it works, post the hal file here so others with this issue can use it.

This should also at the same time eliminate idle random soft limit errors, which happen for the same reason. (it wont really help with soft limit errors when right on the limit of course)

Thanks for all the help in the various threads and discords.

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.