Connect limit switches to G540 Estop?

On a miller, I am installing separate hall-effect home (1 per axis) and mechanical limit switches (2 per axis).

I have the G540 controller and UC100 motion controller, so limited inputs are available.

In this configuration, the limit switches should never be actuated under normal conditions, so I was thinking of connecting them in one NC loop to the G540 Estop input, together with the Estop button.

I will then connect the home switches to other input(s), possibly using one input per axis.

An advantage is that if the limits are tripped, the G540 will halt the machine, without the intervention of the controlling computer. A disadvantage is that such a stop will be interpreted as an Estop by the controlling software (Mach3 in my case).

But I'm very new to this. Is there anything "wrong" with this approach?

taipan,

By any chance are you my friend from way back who gave me so much help with the FPGA programming for the G100? You have a very similar user name so I'm curious.

Sorry, must be a different taipan.

Coincidentally, I have done a bit of FPGA work in my time!

taipan,

I see nothing wrong with your limit switch scheme. Why shouldn't it trip an e-stop in Mach3? The limit switches should never trip in normal operation; tripping a limit indicates something went seriously south on you.

On the FPGA thing: You write in VHDL or Verilog?

Hi Mariss,

Thanks. This setup seemed ok to me. However most people don't do it this way, probably because they use combined home/limit switches. But I am a complete CNC newbie, so I thought I may have overlooked something.

It's a while since I did any FPGA work, but I wrote in Verilog and also used manufacturer (Altera & Lattice) specific design tools. My day job is embedded software development, but this sometimes overlaps into hardware.

taipan,

Right now we are using Actel FPGAs because they have an on-board Flash ROM for self-configuration. I'm looking at using the Lattice Ice40 FPGAs in the future; they have some very nice features that are attractive to me. We run our FPGas at a very low 8MHz to take advantage of the very low power consumption true CMOS designs offer. I write in Verilog as well and avoid behaviorals like the plague. I like the control assign statements give me regards to FPGA resource management.

Hi Mariss,

I've never had cause to use behavioral code, but I'm not averse to it - because I come from the software side I guess! I'm curious - do you use the FPGA for general logic, or for something tricky like pulse shaping? Some of the latest SoC FPGA devices with dual hard ARM cores open up a world of possibilities. Still expensive at the moment though.

I design all the way down to the gate level, the only exception being D-Flops. The design logic has to control a motor so what happens on each rising and falling clock edge is important. We use CPLDs, which are equivalent to a 32 LUT FPGA for our current drives. 31 of the 32 "LUTs" are used to squeeze a microstep motor drive logic circuit into it. The latest design (GM215) uses a 768 LUT FPGA and 90% of it is used.

My objections to behaviorals is this: Say a 16-bit adder is required and you write a behavioral for it. You will probably get an adder with high-speed look-ahead carry while a ripple-carry would be just fine with an 8MHz clock. The resources used will be considerably more than for a ripple-carry version. Worse yet, what if you need a signed multiplier and you know timing constraints would allow a "roll-your-own" serial-parallel Booth multiplier solution? Behaviorals are fast and easy but they come with a cost.

For the GM215 design core I use a 4-chip combination that seems to have a satisfactory synergy: An FPGA to do the high-speed logic, a PIC24F to do the high IQ stuff, an SPI serial Flash ROM to store a user program and an RS-485 transceiver to communicate with the outside world. This core works together so well that it will probably be used in all future designs.

As to FPGA design flow: I do logic schematics first, (all the OR, XOR and AND gates and INV circle symbols) for each function block. These function blocks are shown as interconnected boxes in the top level schematic. The schematic includes Karnaugh maps and clock level timing diagrams where necessary and there is a 90% certainty a circuit will work the first time after all this. I use AutoCAD for this part of the project.

Next comes translation from logic diagram to Verilog which is a simple and relaxing task. My daughter (who is not technical) enjoys doing this and I prefer it because her attention to detail is better than mine. After this is done, the code is JTAGed to the prototype target drive. I never use simulation in the IDE program. Unassigned FPGA pins are used as test points to ticklish parts in the code and a DSO oscilloscope (we use Tektronix TDS3014C scopes) is the primary trouble-shooting tool. A few iterations of the entire process is sufficient to cure all wrong thinking and flat out mistakes.

FPGAs with embedded MCUs are appealing but they can't compete with a $3 FPGA and a $1.50 MCU solution, also we need the PIC24F analog inputs. The PIC works hand-and-glove with the FPGA; there are 12 direct PIC to FPGA interconnections in brand new project and that's for a 28-pin QFN package PIC.

I read what I wrote and realize I have hijacked this thread. This may need to be moved elsewhere.

Thank you for your detailed reply. For me, it's always fascinating to hear the design decisions / philosophy behind equipment that I am using.

I largely agree with what you've said, and you've obviously arrived at a very neat solution for this application. But it's horses for courses. If I were developing a device with general purpose computing capabilities, together with many complex integrated peripherals, I would definitely be looking for a higher level of abstraction in my development tools.

Anyway, the G540 arrived today and it's a very nice piece of kit. Hopefully I will get it wired up this w/e.

For your information, the G540 has been out for years and is overdue for a major addition to its family tree and that will be the GM540. GM is our ultra-secret marketing code for "GeckoMotion"; any new product prefixed with GM means it has a built-in multi-axis motion controller.