EMC on FPGA - real time

Hi there,

I am planing to kind of divide the EMC software in two parts, where the first one would be the GUI, Configuration, non-time-critical-stuff and the second one the Interpolation and other stuff that has to be processes fast. this part will be implemented on a FPGA Cyclon II Board in VHDL.. the communication will be over ethernet probably. The advantage would be, that it is hard-real-time-processing so that professional cnc-mills could run with higher dynamics.later i will include some force,acceleration and velocity sensors on the system.
Now my questions are:
1. Has anybody tried something like this before?
2. how would you divide both parts? between the EMC and the HAL or, somewhere else?
3. Which IDE was mostly used to design EMC? (thats not that important, but makes it easyer to adapt)
it will of course all be OS..

thanks in advance..

Hi goaran,

I want to try something similar - at least the part of splitting HAL from the rest of EMC.

There are three approaches I'd like to explore (with the 3rd being the FPGA idea):

1. Use an Ethernet Parallel Port Print Server.
I know everybody is saying it can't be done over Ethernet, but consider this... I have an HP Jetdirect 150 (very old) and I've successfully done IO on it using this approach: hackaday.com/2007/02/21/printer-networked-light-control

I noticed that it has a large buffer and if I pulse the Busy/Wait pin with a square wave, the data will exit the buffer and appear on the port in a completely controlled way. I went up as high as 100 KHz using this method. This might even work for a PC parallel port as well - who knows?

This basically means that the data can arrive at the box at any rate, but be clocked out at a very exact rate - something that EMC needs. In this case HAL will still run on the PC, but it may send the bit patterns over Ethernet - and be somewhat convinced that it will be streamed out at a known rate in sync with the HAL clock. For multiple axes one would need to sync the clock on multiple print servers - but I think it can be done. The benefit of this is the protocol is extremely simple... just send RAW bit patterns as ASCII over port 9100. A Linux LPR print driver might even work. The trick is of course the oscillator on the far side to clock the data out.

Input is another story... I can get the values of the status lines using SNMP - but this is done by polling and relatively slow - so perhaps good for a console button, but not good for limit switches or encoders. If there's something that will physically stop the motor on limit, then maybe - but I'd probably not risk it.

write_port (in the HAL driver) will basically work like this (I think)... You need to know the period of the oscillator that will clock the data out. Say it's 100KHz. If HAL asks for pattern 0x1 for 10mS then you'd buffer 1000 characters and send. This will easily fit in a 1500 MTU in one TCP packet and you know you can drive 4 steppers with 1 parallel port.

I understand the HAL example with write_port, but there is talk about accessing shared memory... can anybody perhaps tell me how this works and what information needs to be written back into shared memory, if any?

The HAL documentation says buffering controllers is a bad thing - can anyone explain why? I can understand it is bad if there is no synchronisation with HAL, but if the two are in sync, it shouldn't be a problem should it?

---

2. Move HAL to an embedded controller

I'd like to think it should be possible to run HAL on a dedicated machine - particularly a Linux-On-Chip solution like this:
deviceguru.com/tiny-6-chip-open-computer-runs-linux/

or even this www.lantronix.com/device-networking/embe...rvers/xport-pro.html

Does anyone know if this can be done and what protocol can be used between the EMC console and the remote HAL? I'd think a type of RPC call should work?

If HAL can't be seperated over Ethernet, perhaps another approach would be to run a bigger part of EMC on the Linux-On-Chip, but control it using the Telnet console. It gives "screen scraping" a whole new meaning - with a milling bit

No idea if this will work or what the resource requirements would be.

--

3. Implement HAL on a dedicated device.

I originally thought that I could use a PIC micro to implement a HAL and use USB. The thing here is that (a ported version of) HAL runs on the PIC - not the PC - and simply gets instructions from the PC on what motions to perform. This gets rather complex, so your idea with the FPGA is probably better. The trick in both cases would be to find a suitable place to seperate HAL from the rest of EMC and find an efficient protocol to communicate instructions.

I guess the answer will be in the sourcecode itself... Please let me know if you make progress and I'll do the same from my side.

A more modest goal would be to come up with an ethernet-based I/O board for EMC2 (the FPGAs now available all communicate through parallel port or PCI AFAIK). It would need to have real-time communication to EMC2, which probably means working with real-time ethernet drivers both on the EMC2 side and the device side?.
An FPGA would be nice for I/O (encoder counters, pwm-generators, etc.) could then be used on the device. Maybe even the existing hm2 VHDL-code could be used on the FPGA?

Anders

@rializer...

i'll just read the code a bit, if i find anything out i'll report it here..

@awallin

that would be a nice first step. i dont know why the vhdl should not run. where can i find it?

We are working on a FPGA card or two that will be suitable for accessing HM2 over Ethernet

We have chosen Ethercat as the protocol for a couple of reasons

1. Technical superiority, true realtime (10 KHz update rates possible)
This is not true of "XXXIP" solutions, they all have workarounds like timestamping and motion extrapolation because their inherent non-realtime nature

2. No switches or their store-forward delays

3. Open source driver available

4. Standard Ethernet card is all that required in the host

5. Ethercat peripherals are daisy chained, so adding more I/O is easy

EMC has some EtherCat support now. I think Ethercat is an ideal expansion "bus" for EMC as it can support true realtime, has huge expansion capabilities, Is electrically robust (isolated/differential), has excellent hardware discovery (COE), and opens up a whole new world of realtime hardware that EMC can support, from high end Ethercat servo drives
to simple realtime I/O points. A lot of the Ethercat hardware is pretty high end, so we think our Ethercat interfaced FPGA cards will fill a niche for retrofits and for use with lower cost drives
(basically a Ethercat --> analog servo, step/dir, SPI, resolver, quad encoder, SSI encoder, etc etc bridge)


For our FPGA cards we have no intention of doing anything but "dumb" I/O, I think that HAL belongs on the PC where you have fantastic processing power,
an open and comfortable programming environment where a wide variety of people with different skill sets can contribute, and a single locus of control, rather than a mix of control points with communication delays.

Peter Wallace

I'm still new to this, so please excuse the ignorance...

Does EtherCat take the latency problem away by being able to move data from PC to card faster than the servo-thread interval? So in other words, it can keep up with a step/direction pulse stream of 10kHz generated by HAL?

I still don't get why the latency problem is a problem... If EMC can give an instruction to the hardware device, and the hardware device can guarantee a coordinated motion within a certain timeframe on all axes, EMC should be happy shouldn't it?

I'd love a more technical explanation of the problem with realtime ethernet and why 10kHz is a magic number.

Is it about the PC having a certain latency sending out packets? Or is the problem with the upredictability of the packets arriving on the other side? Surely there's more than enough bandwidth to set up a "phased locked loop" with the other side in the data to ensure a continuous stream? I'm thinking a scheme where a clock is extracted from the data stream should provide the necessary predictability - provided there's enough redundant data in each packet.

All this now got me thinking about something else... A soundcard can produce a 24 bit pattern at 44.1 kHz. That's enough for 12 axes at twice the best step rate I've seen on PC. An S/PDIF stream includes a synchronous clock. What about decoding S/PDIF in an FPGA and "play the music" on a mill

Is there something I should know about motion control to enlighten me on this topic?

Moving the data faster is not really the issue, 10 Mbits/sec is more than enough for most CNC machines (Ethercat is 100 mb/sec)

Latency is an issue because EMC does real time control therefore it needs the ability to receive and react to external events in real time (less than the servo period for servo devices)

10 KHz is not a magic number but a good upper limit and one that many EMC platforms can support.
It's a lot of work to support a real time Ethernet framework and I would think that work should go towards
systems without built in limits. As a rule of thumb the sample rate of a servo system needs to be about 10 to 25 times the systems mechanical bandwidth
so a 1 KHz servo rate is fine for ballscrew/servo systems with their typical 50-100 Hz bandwidths. but what happens if you use a linear motor with torque control?
now you may have a 300 Hz mechanical bandwidth and need a 3 KHz to 7.5 KHz servo loop.

This may be doable with RTNet or some other realtime Ethernet (maybe just UDP) just not the IP varients

As far as a phase looked loop goes, I think you are thinking of a buffered system, and this is not a good match to how EMC works

Not sure about SPDIF I suspect the hardware is built on a buffered model but might possibly be usable if you can send a single packet at a time (perhaps via DMA).
The FPGA side is trivial but I don't know what the host side hardware looks like.

Thanks for the lead on EtherCAT. It looks like a really nice solution to solve the "controller over Ethernet" problem. I think if there's a hobby board, with integrated stepper and IO controller that supports this it should be a hit - especially when the good old parallel port is slowly fading away.

I found these documents very insightful:
www.ethercat.org/pdf/english/EtherCAT_Introduction_0905.pdf
www.ethercat.org/pdf/english/ETG2200_G_R..._ImplGuide_Slave.pdf

Just to get back to one of the original aspects of this thread... Do you think it is possible to embed a part of EMC - particularly the HAL and motion components - in a remote embedded controller or FPGA?

I see the different configurations as follows (please comment on feasibility)

1. Standalone: Entire EMC running on host PC - parallel port output.
- Pros: Simplicity. Machine tool feel.
- Cons: Not all PC's work - and laptops definately don't work in this configuration. Extra cost for dedicated high-end machine, screen, keyboard etc. Electrical mistakes are expensive.

2. Remote Controlled: EMC running on host PC, parallel port output, but UI running remote. VNC seems to be the tool of choice or Telnet.
- Pros: Use existing hardware for UI. Can use laptop for UI. Any old decent PC for controller. No screen permanently in the garage.
- Cons: Connectivity issues. Can't use client-attached joysticks and machine consoles.

3. Remote Port over Ethernet: EMC running on host PC, "parallel port" on embedded controller. Linked by EtherCAT (or other comms protocol)
- Pros: Use existing powerful desktop PC in study - Clean. Simple to add axes - scalable. Save cost of controller PC.
- Cons: EtherCAT controllers may be more expensive than a dedicated PC. Can't use WiFi - must use cable.

4. Distributed Components: Axis running on UI tablet with WiFi, EMC core on shared application host, HAL running on dedicated controller. Motion controllers star-connected to HAL controller.
- Pros: Use best tool for the job: touch tablet/pads for user input (no parallel port required), powerful PC for core functions and processing (but keep it clean), cheap but dedicated and rugged hardware in garage - with parallel port.
- Cons: Complex. Multiple points of failure. Can HAL be seperated out at all? Which protocol to use? Latency issues.

The reason I like no. 4 is simply because I have a very nice "HAL controller" (www.embeddedpc.net/Vortex86DXSPARK) - but it seems to struggle under the full Gnome GUI - and a nice tablet (with no parallel port) and a home PC. I'd like to use them in the most efficient combination possible.