My DIY LCNC + Mesa machine - sanity check please!

I'm building a hobby CNC milling machine and am in the process of planning the electrical parts. I wanted to run my ideas by the forum to get a "sanity check" so to speak of my plans.

Something along these lines:

It's a servo machine; the servos are Yaskawa Sigma-series from Ebay. The spindle motor is also a Yaskawa servo. The servo drives are model SGDA and their IO look something like this:

* +-10 V either torque or speed (programmable) reference input.
* RS-422 quadrature encoder outputs A+B+Z (max 2048 pulses/rev, can be divided down by the amp). Nominal/max motor RPM is 3000/4500.
* Active-low, photocoupler Servo ON "/S-ON" (Enable) input.
* Active-high, photocoupler positive overtravel "P-OT" input (must be held low to allow travel in positive direction).
* Active-high, photocoupler negative overtravel "N-OT" input (must be held low to allow travel in negative direction).
* Servo alarm: active low photocoupler output.
* Servo ALOn: three open collector outputs to indicate the type of servo error.
* RS-232 programming connector that communicates with the SigmaWIN software.


This is my plan:

* LinuxCNC ("LNC"?) + Mesa 6i25 + Mesa 7i77 for control.

* ESTOP: The e-stop buttons will control a safety relay, which will in turn control contactors that break power to the servo amps. On power loss these go into regenerative breaking. So this part will be completely separate from LNC. If the ESTOP is actuated, LNC will only notice that the following error explodes.

* Servo ON: The ground for this signal will go through a switch on the electrical cabinet (with a corresponding LED), on through the 7i77 ENAx- => ENAx+ and to the servo amp. So both the manual switch and the LNC enable must be on for the servos to be actuated. I will flip the switch when changing tools (and possibly connect a door contact on the finished machine to this chain as well).

* Overtravel: NC switches on the machine pulls the x-OT servo amp inputs low. The inputs on 7i77 are current sinks, which makes things a bit complicated here (they cannot be paralleled with the servo amps' current sourcing inputs). The plan is to build signal inverters out of a PNP transistor + base resistor to invert the signals from the limit switches into sourcing outputs that fit the 7i77 inputs.

* Homing: Is it possible to use the limit switches + the encoder indices here? I.e. run the servos until they hit their limits, then back off and zero on the index pulses?

* Servo alarm: These servo amp outputs indicate servo error conditions like overspeed, overcurrent, overvoltage etc. I'm not quite sure what to do with them. When activated, the servo is stopped until the alarm is reset. I think I will want to know exactly what happened in these cases, so I will probably hook the servo amp up to a computer with the RS-232 programming cable to figure things out if an alarm goes off. I hope I can run the required SigmaWIN software on a virtual Windows machine on the LNC computer. Again, LNC should notice a huge following error if a servo alarm trips.


What do you think? Will this work?

One easy way to use sinking outputs with 7I77 inputs is to add a fairly stiff (say 1K) pullup to common control V+

Homing can home to index (see homing section in integrators manual)

I would not worry about the specific fault indication except maybe for initial setup
(and avoid extra connections from drive to PC for EMI reasons)

One easy way to use sinking outputs with 7I77 inputs is to add a fairly stiff (say 1K) pullup to common control V+

I'm just worried that this could keep the OT inputs active even though the overtravel switches open.

According to the manuals, 7i77 has 20 k input resistance. The Servo amp inputs are 4k7 (+ opto coupler). So if I parallel these 24/24700 = about 1 mA of current will flow when the limit switch is open, which IMO is way too close to the 5 mA when the servo amp input is pulled low normally, through the overtravel switch.

The addition of a pullup of 1 k in parallel with the servo amp input will lower the voltage over the input to < 1 V which should work, but if the resistor comes loose I might lose the function of the limit switch.

It seems safer to "decouple" the current sink of the 7i77 from the limit switch circuit, don't you agree? Especially since the cost is just a small PNP transistor...

Homing can home to index (see homing section in integrators manual)

I was more concerned about running the machine against the limit switch. Is there a way to ignore (or better yet, increase the allowed) following error while homing only?

I would not worry about the specific fault indication except maybe for initial setup (and avoid extra connections from drive to PC for EMI reasons)

Great!


Thanks for your input!

Whether a pullup resistor (and ~1V drop across the high side OPTO) works well really depends on if the OPTO LED has a parallel resistor
so it needs more than 1V to turn on.

Not sure why you would want to increase the following error during homing, The homing procedure with index first searches for the home switch
and then for index.

If you have shared limit/home switches, you will not be able to use the servo limit inputs

The opto LED only has the 4k7 series resistor inside the servo amp. The only parallel resistor would be the pullup resistor (in parallel with the opto LED + series resistor). But never mind, it seems as easy and safer to go with the "PNP inverter".

I am going to connect the limit switches to the servo amp as limit switches. But I do want to use one of the limit switches on each axis as a "home" input to LinuxCNC as well. However, when the machine runs against a limit switch, further movement in that direction will be blocked by the servo amp. The question is: will this be tolerated by LinuxCNC, or will it trip the following error? I'm guessing that LinuxCNC will want to stop and reverse the axis when the "home" switch is hit anyway, so it might work?

If I input limit switch signals to LinuxCNC as well, how are they used?

BTW, I found this, section 1.6.5 which is HAL code for something like what I want to do, I think. Seems it should be possible.

And He Who Googles Shall Find: Section 2.10.1 of the INI Configuration has info on shared limit+home switches. HOME_IGNORE_LIMITS seems useful! Still, there is the question of following error when the axis will refuse to follow the LinuxCNC retardation profile in the HOME_SEARCH direction after the switch has been hit.

I would simple not use the servo limits as they will make homing a _major_ nuisance
(unless you want separate limit and home switches)

If there's ever a time you want a cautious move with tight ferror limits, its during homing

I would simple not use the servo limits as they will make homing a _major_ nuisance

I'm afraid that without servo limits, a run-away servo, or just a moment of carelessness, could cause major damage. The peak force of the table is something like 6,5 kN, and the max axis speed (before the servo amp overspeed trips) will be almost 17 m/min. So I won't skip the servo limits. I'd rather add home switches if absolutely necessary.

But you are saying that what I worry about above is a real problem? And there's no (easy) way to get LinuxCNC to lax or ignore the ferror limits while homing?

Why would you want tight ferror limits when homing? I take it for granted that LinuxCNC use the fed back position info, and not the commanded position, to set the home position when the index is detected. (?)

Sorry for all these detailed questions. Perhaps I will just test and see what happens.

Best would be to have separate limits and homing switches.
If they are combined the, drive limits are just going to cause homing to be
compromised (or impossible without manual assistance) so IMO should not be used.

If you have separate switches, there is no need to even connect the limits switches to linuxCNC
since they will likely never be reached except in a runaway

andypugh wrote:

I think that you may be hard-wiring behaviour which would be more usefully implemented as raw inputs to HAL with the logic handled there. For example, door status and over-ride button could be individual inputs to LinuxCNC and how they are arbitrated can be set in HAL logic. It is much easier to change HAL than to rewire the machine.

You and PCW really do trust your software! I'm a software engineer by trade, so I don't. If I'm going to put my hands in the machine I want to be able to disable the servos in a way that the software cannot override.


Thank you for the comments on the spindle. The spindle is already made:

I had a vague idea of glueing plain shaft collars to the tools to get repeatable tool height. I'm not sure how well that would work though.


Perhaps a bit of background is in order: the only experience I have with milling is that I've used a small manual bench-top mill perhaps 10-20 hours. I've never used a CNC milling machine, so I'm not at all familiar with the work flow. That's really the big reason I started this thread; I'm not sure my set-up will be practical in use. Although tips on the purely electrical are welcome too of course!

As for the computer side, I've used Gentoo Linux on my desktop for several years, but not very much Ubuntu at all. I've also worked for several years with embedded linux and kernel development.

Electronics has also been a long-time hobby of mine, I have easy access to soldering tools, oscilloscope and such. Although line power and electrical cabinets is a new experience for me.