[dakiller322]

Hi all,

I'm working on building a fairly basic XYZ CNC mill/plotter, stepper motor controlled, all fairly basic. Now controlling it with EMC2, I want to be able to send all the commands via the PC serial port to a microcontroller and have it manage the stepper motors there. coding micro's and building all the hardware is no problem, but I'm a linux noob and setting up the HAL driver to send commands serially is a little beyond me right now.

I've got the latest Ubuntu CD with EMC bundled on it and have booted it in a virtual machine at the moment to have a look at it, but I'll probably make a dedicated install if it gets too hard trying to talk through the virtual machine drivers.

So has anyone got any tips on setting up the drivers to send commands via serial? I just need to get them out of the PC, decoding their function at the microcontroller is no problems. And how about communication in the other direction, limit switches and stuff like that?

Thanks,
Dan

[Jeff Epler]

In emc2, the PC interprets all the gcode, and then the realtime portion of the software produces a "commanded position", typically every 1ms ("commanded position" includes helical arc interpolation, blending, acceleration & velocity limits, and so on). It compares it to a "feedback position" just as often, issuing a following error if the difference is too great.

You can put whatever you want between "commanded position" and "feedback position" -- for instance, servos controlled with a PID loop and PWM, steppers controlled by "step & direction" signals generated at 50kHz, and so on.

So back to this device you'd like to build. You've said it will use the "PC serial port". emc2 doesn't yet include any hardware drivers that use the serial port and can't use linux own drivers for realtime tasks like motion control, but since you're familiar with programming microcontrollers, you should understand in general what it takes to write a hardware driver for the PC's "16550" serial chip. http://www.beyondlogic.org/serial/serial.htm

Now you need to figure out all the details, like the format of the data to be transmitted between the PC and your device. At 115200 baud (the maximum supported by a standard PC serial port) you get about 10 8-byte characters each way per 1ms under ideal conditions. Conveniently, this fits within the 16-byte FIFO of the 16550. One possible format would be a series of 3 or 4 signed differences in position (one per axis you control) with the rest of the bits left over for misc digital inputs and outputs.

Then all you have to do is write all the software and hook up the HAL driver. Documentation for writing HAL drivers is on the linuxcnc.org website: http://linuxcnc.org/docs/2.1/html/hal/comp/

[fenn]

a good place to start hacking might be the serial port component:
http://linuxcnc.org/docs/html/man/man9/serport.9.html
this driver currently only gives you access to the raw bits of the serial port. it doesn't expose any FIFO buffers; you would have to add them to the list of functions as new "inb()" and "outb()" methods for example. also you will have to come up with some kind of protocol like jepler described, and that is best done in C rather than trying to glue stuff together in HAL.

[John3]

..... Then all you have to do is write all the software and hook up the HAL driver. Documentation for writing HAL drivers is on the linuxcnc.org website: http://linuxcnc.org/docs/2.1/html/hal/comp/

Jeff,

Just tried the above website.....NO-GO! Is it mistyped / down / or do I have a bum connection?

John

[acondit]

John,

I just clicked on the link and it worked for me.

Alan

[John3]

Its working for me now......

[dakiller322]

Thanks for the posts, I've read through a bit so far and I'll see what I can make of it

[HelicalCut]

dakiller what are you running on the serial port, is it an ocean controls or silicon chip type serial command interpreter?

You will have to write a device driver for the HAL, I am looking at the same thing. It is not quite as simple as just moving the comands to the serial port, the parallel inteface has step and direction info with acceleration max step rates etc handled by the host machine (one running EMC) the ocean controls serial board offloads this to an embedded micro.

I havent looked at the internal architecture of EMC yet but it may be that all that is required is a simple command interpreter and a serial driver.

[dakiller322]

I've been going over how to do it and have basically come up with the idea to take the parallel port step/direction commands as well as the other standard bits and just put them in two bytes and just send them via serial port to the micro. Makes for easy programming and I don't need to calculate anything and leave it to EMC to do all that.

Going with this SERPORT driver, is this already built in? Looks like it already has the read-write functions built in and I don't see how I need a FIFO as it wont be necessary for the output bytes to the micro to be exactly timed (everything can be synced to latch out there) and as long as I read any byte in in enough time I'll be right? Or is the FIFO always active and going to make more complications?

Sorry for some of the stupid questions, linux is new to me and so is HAL

[Jeff Epler]

the serport driver is only for the rs232 control lines; the "TX" output pin does not send a byte stream, it just sends MARK or SPACE according to the value hooked to pin-3-out. Think of it as a crippled parport with only 4 inputs and 3 outputs, and at inconvenient voltages.

If you want to send streams of bytes, you will have to write your own serial driver.

In any case, the idea of sending a stream of bytes where bit 0 is "X Step", bit 1 is "X Direction", and so on is attractive but unlikely to work very well in practice.

The first kind of problem you will see is that at the 16550 FIFO's maximum rate (115200 bits per second) you can only command very low step rates. If each byte can command a step, then the maximum step rate is 11520 steps per second--OK for a slow machine or a machine without microstepping, but also easily attainable with a parallel port.

The second kind of problem you will see is in the timing of things. HAL threads run at a particular rate, called the PERIOD, which is a multiple of the period of a high-resolution timer in the PC. The 16550 FIFO has its own timer to determine the start of each transmitted bit. Now, you need to configure HAL so that it is activated exactly as often as the 16550 transmits a byte. In HAL, you put a new byte on the transmit FIFO. BUt what if these two clocks can't mesh exactly, every time? If the 16550 clock is the tiniest bit slower than the HAL clock, you will eventually find that the 16550 transmit FIFO is full. What do you do? You are faced with either skipping a byte (and thus losing steps) or trying to delay until the FIFO is not quite full (and eventually miss realtime deadlines). Another solution is to arrange it so that the 16550 clock is always faster than the HAL clock, but that will erode your already-low steprate.

That's why I believe that any driver using a serial protocol will have to adopt a packet structure like the one I outlined tersely in my earlier message. The packet structure will have high-level information (like velocity request and position feedback), fit within the bits available, and by having slack time it will avoid the problem of skew between the HAL and FIFO clocks.

[sansbury]

Out of random curiosity, why is it that you want serial port control?

[dakiller322]

Out of random curiosity, why is it that you want serial port control?

Hoping to run it off my laptop which doesn't have a parallel port, thought it would be a good learning exercise as I haven't done much with rs232 before and I always like to do things different

Anyway, I've dropped the serial port idea and just sticking with parallel port step/direction

This is actually for a uni project, so here are a few pics of it so far if anyone's interested