Interface Design for OS CNC Controller System

Status

Integration with the Arduino is essentially done. The latest version includes an interface board that plugs into the Arduino, like an Arduino shield would. Next Steps:

The end stop sensing has been integrated in hardware and firmware. Including coming up with a special algorithm that Chuck was working on to align the two motors on the x axis. I wouldn't call this tested and complete, but the hardware for the next rev is designed and Chuck can advise on firmware, but I believe he has that essentially done. Next Steps:

Trigger, I assume you are referring to turning the torch on and off. This is trivial, there are two expansion ports on the StepperNug Interface board to plug daughter cards into. One of which can be used for torch control, the other was intended for height control. Next Steps:

Height Control. This is the one non trivial task left as far as hardware is concerned. It has required access to a torch, which Chuck and I don't really have. Next Steps: Hardware to be researched; electrical connections required from Interface: 2 signal, 2 power, and 4 from a Steppernug stepper driver output.

In summary, I have most of the design work done, but before having the next board built I wanted to make sure the height control has been prototyped and tested. That has been holding up development of the hardware side.

Firmware Status

Marcin, Darren,

Firmware status:

The homing is now functional on my mockup using one optosensor on each
motor. I did a little development on limits a while back but they are
not fully implemented.

We made a choice a while back to implement an I2C interface bus on the
board. This turns out to be a little more complex than I expected and
has been a time sink, but I still support the design decision as it
makes it easier to add more I/O features down the line. As noted
above, we are successfully running home switch input operations
through I2C; however we can't yet interleave output operations (e.g.
"start torch") with input operations in real time.

I am fully employed and unfortunately not finding much time to work on
this project, maybe a few hours a week. A possible place to look for
firmware coders who are already up to speed is the grbl site at
https://github.com/grbl/grbl . I would definitely like to see this
come to fruition.

Cheers,
Chuck

Controller Update, 3/30/13

Sorry for the delay, I will expand on some topics later. But to give you some idea of what Chuck and I were working on:

The torch height controller would benefit from being a self contained system that communicates over I2C with the arduino. For two main reasons. The Arduino Uno is quickly running out of room in the flash as new capabilities are added to grbl. By moving that function off the chip it alleviates future compatibility issues with grbl. Isolation is built in to the StepperNug interface right now, if the arduino is tasked with handling analog we would have to come up with an analog isolation method which is non-trivial. Right now we have I2C isolated, so it is a reasonable path to follow to get the torch height correction values back to arduino. Lastly, the cost is equivelant between an ADC to read the torch height, and a microcontroller to do the same. If a microcontroller is utilized, might as well implement a PI controller there and send the correction values instead of ADC values as the microcontroller would be under utilized just sending ADC values.

Documentation is almost nonexistent. There is some for the first interface board, but I will hold off on creating much for the new rev until the design is finalized.

Heat sinks are included in the current design, enclosure has been considered during layout, but not implemented.

RF shielding is in the design. However, the physical location of the isolated Arduino may be an issue that needs to be addressed during case design.

I haven't been spending much time on this design as of late. I don't want to design boards without the requirements fully defined. Once we do that I will send out the next rev of the interface board to be manufactured. In order to get the design requirements defined there has to be someone with an oscilloscope and a plasma torch in the same room. Chuck got the chance to look at the DC portion of the torch signal, but the portion that will drive the design is the AC portion. I have looked, and I can't find an data on this.

Lastly, what other developers do you need?.?. I personally like to split a project like this between hardware and firmware. If I were to split the project up, I would split it there.

Cheers,
Darren

More Info

Here's some stuff that was on another page and I'm consolidating. I'm not sure if it's up to date.

Serial connection

When electrical noise is not a problem, the simplest connection from PC to steppernug is through the Arduino's native USB port.

For longer runs (to keep PC out of dirtiest areas) and better noise immunity, steppernug interface board will support an RS422 differential balanced serial line. Then the PC end would need a full-duplex adapter like this.