Driving Servos

[Mahan Bastani]

HELLO!

I'm trying to drive servo motors with the smoothie board...

I have servo drivers which work with step and direction pins, and this is the link to the datasheet of the servo drives:

www.leadshine.com/UploadFile/Down/DCS303m.pdf

Now my questions:

1-How do I calculate the microsteps/mm ? (I don't have steppers so I can't use the reprap online calculator :(   )

2-Even though the step and direction inputs are connected to optocouplers,  but the suggested input logic is 5v, 

should I connect it straight to smoothie board, or should I use a logic level converter? ( because the smoothie board's logic is 3.3v)

3-my driver has an error output so it can inform me something happened to encoders and etc... How should I implement that in the software? 

Do we have any pins assigned for it or do I just have to edit the code and compile the firmware ?

Thank You!

[Jetguy]

The math is no different for a servo than a stepper. You have to know the variables you put into the system.

For example, stepper motors come in all kinds of degrees per step. Some are 1.8 (AKA 200 steps/rev), some are 1.9 degree (AKA 400 steps/rev), some are oddball 37 degree, and who knows what else.

Bottom line, there is a steps/rev

In servo, the encoder setting determines this. When using a rotary encoder attached to the motor, the counts per rev is the equivalent of steps per rev.

Many are 2048, 1024, 512, but also 2000, 1000, 500 depending on what setting and device you have.

The basic math is simple. First, know the timing pulley pitch (space between teeth) and number of teeth. The idea here is to determine linear distance the belt will move for 1 rev.

The pulley at the motor is generally the one that counts, even in multi belt systems (assuming other ratios are maintained 1:1).

So that math is belt pitch times teeth count to solve for distance/rev

Then we determine the encoder count/rev. Likely this is from the data sheet when you set the options. Again, likely 2048, 1024, or even 2000, 1000, or some other value.

Simply take the logical count value and divide it by the mechanical distance value.

So a 2048 count/rev setup of the encoder with an 18t GT2 2mm pitch pulley (18*2mm=)36mm/rev mechanical is 2048/36=56.888888888888888888888888888889 count per mm AKA steps per mm.

Now, drivers like Gecko ALSO have a step multiplier function. Normally this is set 1:1 but the idea here is that for every step that goes in, you can multiply the logical value sent forward to the servo engine. There is good reason to do this. If you use very high count/rev encoders, then the pulse train of steps moving at high travel speeds will be very high. This often exposes limits of the controller. What this multiplier lets you do divide the above steps per mm value by the multiplier value. So say you use a 2X step multiplier, that would result in halving the steps per mm.

Given most current bots using steppers run in the 40-100 steps per mm range given microstepping and pulley/tooth count ratios, you logically should attempt to stay in that range with servo at the board interface between the drivers and the controller. Servo can let you use very high encoder counts. This simply lets the servo maintain tighter holding and accuracy.

Servo is simple. All servo does is try to maintain 2 values tightly together. The step pulse coming in increments a logical desired position value in the servo driver logic. The servo driver is then also trying to match the encoder count to that value. If the resolution of the encoder is extremely fine, then any error of position rapidly ramps up the error between actual (sensed) position VS target. Meaning, the servo driver KNOWS even the slightest position error and attempts to correct. By using the step multiplier, we still gain the precision control of the encoder, but don't over task the smoothieboard controller with insanely high pulse counts.

Also note, this is why setting the PID parameters on the servo driver must be adjusted "in system". A high encoder count is basically high gain. The tiniest movement generates a large count value. That large error count results in the logic driving the motor to maximum force in a short distance. So generally, the gain is turned down much further for all 3 values with a high encoder count. As encoder count is lowered, then "electronic" gain compensates for mechanical gain.

[Jetguy]

Other things about Gecko GX320s and likely true for any other step enabled servo driver (PIC Step comes to mind as another brand).

That error line is not going to work like you think exactly. To get the system to even enable from a power on, per the data sheet, you must hold that pin high to 5 volts. Then, after the servos do their initial startup, they self test and if all passes (they are checking the encoder and move the motor the tiniest fraction of  count just to see if the encoder increments in the correct direction) then the error output stays high.

IF, a failure is detected, then the servo drives that pin low to ground. This shuts down the servo holding function.

SO unlike stepper drivers, there is NOT an enable/disable pin for position hold. This can be quite annoying in your setup when you want to move the head or some axis without jogging by hand.

You can emulate but also NOTE there is a delay in the enable sequence so normal enables that worked for a stepper driver can miss those first couple of step moves resulting in a big fast jump on the first move and enable.

See, the target position is always being incremented via the step input even when the driver is not active.

I put a switch with pullups/pulldowns to give me control over the geckos rather than putting it to the controller.

You simply pull up the error line to 5 volts to enable, ground to disable the servos. Ideally, given the raw strength in the servo setup, for safety a big red E-stop button should be used such that you could kill the servos if a dangerous event happens.

[Jetguy]

Again, in my setup, I ONLY use the step and direction pins from the controller to the Gecko servo drivers. The enable pin and general logic we use is not compatible with the servo drivers. While one could come up with a scheme, that pin is bi-directional communications on both ends for proper operation. As such, it's not something like a simple code change.

Also, due to the self test sequence, you cannot exactly use it like a normal enable function either.

Bottom line- servo is very different from stepper and may require some "work" habit changes.

By all means, if you have the time and ability to sort out code to make enable pin bi-directional, include logic to enable at the start of any print or move and wait before sending step pulses, then maybe you can create a "system" that behaves more like steppers. I'm just saying this is one area to either get "right" or just leave it alone and implement the workarounds I have described relying on some level of manual control.

[Mahan Bastani]

Hello !

Thank you very much for the explanation about the belt system. 

About the gecko drives,

I bought two of those and tested them, they were the WORST and the STUPIDEST drivers that I have ever seen in my life, poor design! Even their tech support is really rude!

So I found another servo drive( which I have put the datasheet in the first post). That one is great and it has the same price, I recommend you buy those if you are building a new machine. They have a serial port which comes with a software, they automatically tune them selves and set the PID settings, they even have a small wave generator inside them for self testing. They also have SEPARATE  Error and Enable pin! Unlike the stupid gecko drives with that useless bidirectional pin ( btw, I wrote a program with an AVRmicro controller to separate that bidirectional pin into two separate pins, and it worked really good, if you want I can give it to you). These drives that I have actually have an internal DSP engine based on the datasheet for the self test, and I have tested them, when you pull up the enable pin it immediately goes enable(no delay), it doesn't take a long time like gecko, and also if you pull it down again it disables the motors, and during the start up it's enabled by default. 

So I don't have that issue, now what I want to have is an input for the error pin on the smoothie board so if something happened the belt system and somehow it failed I can stop the process from the smoothie board ( drivers have already stopped the motors, I just want to acknowledge the failure and let the user know why it has stopped).

So is there any way of doing this?!

Have you connected your drivers straight to the controller? Does it work with 3.3V Logic?

Also do we have a E-STOP input?! Or I just have to connect it to the power line?


Thank you very much again!

[Jonathan Lussier]

FYI for anybody looking to wire Servos into the smoothieboard, look here:

blog.bouni.de/blog/2015/02/02/driving-a-yaskawa-sigma-ii-ac-servo-with-a-smoothieboard/

Bouni posted a wiring diagram and some tips on configuration.

thanks

Jonathan

[Ryan Turner]

Driving servos is more a question about the servo than the smoothie.  The smoothie outputs completely standard step/dir/ena signals, and 95% of servo drives will accept them without issue.  There are exceptions, but if you go through the manual first it should be pretty clear whether the drive will work out of the box.

In most cases you can treat the error output from a servo drive exactly like a limit switch.  Generally they are designed to pull down and be in high impedance otherwise, which allows any number of error/limit switches to be connected to the same input.

The only real complication is the encoder index, should you choose to use it.  For the best accuracy when homing, you can use a homing pulse from the encoder instead of just backing up against the limit switch.  This is of course completely optional and would require a another input pin for the new signal.

[Mike Men]

Hello, 

I post here the broken link to Yaskawa - http://blog.bouni.de/2015/driving-a-yaskawa-sigma-ii-ac-servo-with-a-smoothieboard.html 

I recently purchased Yaskawa Servopacks SGDS-01A72, which require SynqNet  - for control and the question is will this work with Smoothie? 

I would like to replace X and Y axis steppers with Yaskawa Servos on my Open PnP.  

Thanks

Mike

[Mike Men]

the video link is here ; https://www.youtube.com/watch?v=zM838mYFjcA

Mike

[Arthur Wolf]

I don't know what synqnet is, but unless it's a synomym for step/direction signals, smoothieboard can't output it. step/dir is an industry standard, and a driver that can't read it is really a piece of junk trying to force you into buying more proprietary hardware ...

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

[Mike Men]

Hello Arthur, 

I was supersized with the answer from Yaskawa technical support ; 

SynqNet is the only way to control the SGDS-01A72AY539  (customized series- I didn't know..) drivers.  You will need a SynqNet controller to use them. The  Y539 suffix freezes the firmware and hardware at a certain revision.

2)      Yaskawa  SGDS-A5A12A - You cannot use these either.  Those use a different digital communication network which is called Mechatrolink II

From here it seams this Yaskawa - only Models OMRON SGDH-0xAE-OY or better only some models have  step/dir inputs to Yaskawa CN1 port.....

Mike

On Friday, 3 May 2019 10:35:39 UTC+2, Arthur Wolf wrote:

I don't know what synqnet is, but unless it's a synomym for step/direction signals, smoothieboard can't output it. step/dir is an industry standard, and a driver that can't read it is really a piece of junk trying to force you into buying more proprietary hardware ...

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Mike Men]

Hello - the following Yaskawa servo-packs accepts step/dir signal & could be used with SmoothieBoard:

SGDH-xxAE
SGDS-xxA01A
SGDV-xxxA01A
SGDV-xxxA01B002000
SGD7S-xxxA00A

Mike