Advanced Search

reboots wrote:

160V seemed reasonable for the 163V rating of my brushed DC servos.
 

Brushed DC servos, yes, that is correct, but not for AC motors:

Look at an oscilloscope trace of 120VAC sine wave. The tops and bottoms of the trace touch +/- 170VDC, you can't create that off 120VDC with an h-bridge.

This will also cause a bridge rectifier+capacitor to produce ~170VDC from 120VAC.

I still remember my first experience with a rectifier, how amazed I was to get about 17VDC when I powered it with 12VAC from a transformer. The 12VAC is the actual power, sort of an average. "Average" is not technically the correct term here, but it is the idea. RMS is the term normally used.

PCW wrote:

A 160V DC bus supply can only provide about 110 VAC to the motor
so you would be limited to about 1/2 the servo motors full speed.

Can you clarify this? I had thought DC servo drives were typically an H-bridge, which would make for +/-160VDC output minus power semiconductor voltage drops. (Bipolar transistors in my Bosch drive, so not negligible.)

160V seemed reasonable for the 163V rating of my brushed DC servos. OP has 210V brushless servos, so their supply requirements are somewhat different.

They are actually subroutine macros, the GUI is just generating the parameters for it based on the inputs. After that they are just called one after each other with a subroutine call.

Thanks, I understand it now. I have 1 more question.

Today I'm connecting the encoders and limit switches, but I have a question about the drive enables.

My machine has relays for the drive enables. Is it a good choice to keep those? 'Cause the 7i97T has optocoupled drive enables, but I don't know if it's a problem for the control or the board. I have to verify if the coil uses less than 50mA or buy new ones.

But is it good practice to have an extra layer of protection, or is it better to operate them directly?

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...