[Fish4Fun]

I have been reading, reading and reading about alternate methods of getting step pulses to my G540 (methods other than a parallel printer port). I FULLY understand the problems of USB/Ethernet latency/timing. I also (sadly) understand the same problems exist with the parallel port with modern Windows OSs.

My small A4 router sits in a big box in my "game room" with a desktop sitting right next to it, why am I worried about a USB/Ethernet based controller for it? Several reasons that have NOTHING to do with my A4 :-) We have a lot of company visit us, and people see a PC and they want to check their e-mail, play a youtube video or check their facebook. That is just life in the 21st century. Currently I have two hard drives installed in the PC, one with Win7U for "guests", the other with WinXP for running my A4. But Win7U and WinXP don't "play nice" even on separate drives. WinXP views Win7U's access to its drive as an invasion, and on boot-up in XP it wants to scan the entire drive. This is an irritation that I can resolve, but it is an irritation none-the-less. (The main problem is I have almost everything disabled in XP, ethernet/USB, so I have to transfer files to the XP disk from Win7, then reboot in XP...)

More importantly, I do all of my CAD/CAM work on my Laptop, and I would really like an "easy" way to migrate that work to the A4 or A4 PC. Ethernet would be great for me, but anything has got to be better than my current situation. (I know, just build another PC exclusively for the A4, but I don't like that answer for aesthetic reasons.)

Finally, With the G540 and 12TPI acme screws about the best I can get my current machine to do without "missed steps" is 30ipm. It should do twice that, but it simply doesn't. It will run @ 60ipm for a good while, then that horrible noise and a ruined work piece, but this thread is not about tweaking Mach3.

The problem seems to be addressed in three distinctly different approaches:

1) Attempt to work around the problems on the PC side with drivers/DLLs etc. for a specific target controller.

2) Move the gcode resolution to a uController/FPGA removing the PC from the timing loop.

3) Develop a PC front end that resolves the g-code into higher level commands designed specifically for the target controller.

Each approach has strengths and weaknesses. #1 has the appeal of "universal acceptance" and backward compatibility with existing software/hardware. #2 & 3 are the most logical and straight forward, but are also the most likely to leave people "stranded" if the support goes South.

At the end of the day, uControllers//FPGAs are the MOST NATURAL choices for precision timing. Even modest uControllers are very comfortable in the nano-second time domain. The problem is that uControllers//FPGAs require complicated firmware, specially designed PCBs and typically proprietary PC applications to control them. This makes them expensive on the front side, and in danger of continued support as the product matures.

So, Who has a USB/Ethernet Controller that can report on the pros/cons of their experience? I like what Kroko has done with a #3 solution, and am considering it. I also like the kflop solution and like the idea of using a Mach3 plugin, but worry that my parallel port problems will continue. Warp9 and the smoothstepper seem to have a fairly large following, but appear to have some ongoing issues as well.

The first part of this post ends here with:

Please, owners/makers of various controllers Please share your experiences/thoughts about your hardware/firmware/software. I am going to buy something soon and would really like some input from people using the various products.

************************************************** ******

Part 2:

The goal: An open source discussion/development of a controller interface that is not timing dependent on the host PC. That is, step data can be sent to the controller all at once (buffered) or in large "chunks" via any available means (LPT, USB, Ethernet, Flash Drive etc, etc.) The purpose is to find a way to bridge the PC to the drivers that is platform independent.

I have several ongoing projects, so I am NOT planning on undertaking this any time soon, but I am hoping that an opening dialogue might stir some interest in an open source approach to this ever escalating problem (newer OSs not playing well with LPT ports, and the eventual demise of the LPT port in future MOBOs.)

The three approaches outlined above are the most obvious ways to remove the LPT port from CNC. If there are other approaches that deserve consideration, please share your thoughts. Of the three, the first is a non-starter because it does not address the demise of the LPT port, so that leaves us with PC based gcode "compilers" and external gcode interpreters (ie, the uController/FPGA resolves the gcode).

There is an open-source gcode interpreter project for the Arduino. I think the AVR family of uControllers is fabulous, but under-powered for such an undertaking. I also think that a firmware gcode interpreter could severely limit compatibility and would lend itself to highly proprietary purposes. It is certainly possible to overcome these limitations, but it does not offer a solution that lends itself to platform independence, it simply uses Ucontroller power to replace the PC.

I think Kroto's approach has the most merit for an open source approach. What is needed is a defined communication protocol between a PC and a controller that is independent of the controller. To envision how this might work we only need look at the origins of gcode. The original idea of gcode was to create a series of commands that a controller could resolve into pulse streams, but since gcode's inception PCs and electronics have made huge strides, and we now want features like acceleration, forward looking algorithms, etc, etc that simply aren't practical in firmware (not for general purposes). Abandoning gcode altogether is silly, there is far too much momentum in existing software.

To bridge the gap between gcode and controllers I am suggesting a standard protocol that includes timing along with step and direction information and includes feed back to the host PC about the actual position in the execution. Let's take a standard 4 axis driver like the G540. For this driver we need up to 4 bits each for step and direction, or one byte of data for any given step. Obviously we would also need timing information for each step. At the end of the day, we need to ensure that the data throughput does not exceed normal communication protocols, and that a reasonably priced uController/FPGA could handle the data throughput. The process might go something like this:

Set step timing to 10uS (one byte instruction)
Set Dir to + on Y axis, + on X, - on Z, + on A  (one byte instruction)
Set Step Counter to 100 (one byte instruction)
Set Pulse Train Counter to 4 (one byte instruction)
Step Pulse train:
0001 0001 ; moves A two steps of 100 pulses (one byte pulse)
1001 0101; moves Y & A 100 steps then moves X & A 100 steps (one byte pulse) 
1010 0010; moves Y & Z 100 steps then moves Z 100 steps (one byte pulse)
0001 0001 ; moves A two steps of 100 pulses (one byte pulse)

Next would come a "setup instruction" that would change parameters as required.

Obviously there needs to be "Modes" of operation that include moving 1 to Max axis within a given "setup instruction" data group. For instance, if A & Z are to remain "fixed" for the duration of the instruction, then only two axis of pulse streams are required, and a mode could be selected where 4 pulse strings per byte of data could be generated. Obviously for curves more data is requisite. There would also need to be support for more than 4 axis, but this is fairly trivial, it just increases the data throughput.

These are just examples of a possible protocol for producing a relatively compact, non-time dependent data stream to a controller. From the controller's point-of-view it doesn't matter if it is getting the data Via LPT, USB, Etherner, Flash drive etc. Defining the protocol is the important part, this would allow developers of applications like Mach3 to offer a "compiler" (or atleast an output format that could be compiled using an open source compiler) using their existing software, and hardware/firmware developers to offer their products to the community w/o the community having to worry about compatibility issues.

I see no reason a compiled "protocol" would need to be more than 10x larger than its corresponding gcode file, and could actually be very close to its size and perhaps even smaller in some cases. "Tricks" to avoid overhead involved with acceleration might include an auto-incrementing pulse train mode, so that the time between pulses increases/decreases every data byte until some maximum/minimum is reached. Features such as "supported modes" can be hardware dependent and software selectable, allowing room for more advanced features and firmware designs.

Feedback to the host PC is not particularly time sensitive for graphic interfaces, and could be as simple as absolute pulse count from "zero" in all axis along with switch/relay/etc data every 100mS or so (this would be a fairly small amount of data).

I have droned on and on, apologies, but I think as a community we need to be working on this, that is defining a protocol/language whatever we want to call it that will free us from the vagaries of the LPT timing issues. If this protocol is defined in an open source//open forum then software developers and hardware/firmware developers can work things out on either end because we, the consumers, will insist on it. The way things stand right now a new solution HAS to either comply with existing hardware/software OR attempt to develop both simultaneously and then convince us that they will support it in the future. If WE define the protocol, then hardware folks can focus on what they do best, and software developers can focus on what they do best, and if someone on either sides goes away, we aren't left holding the bag.

I guess I really should have made this a separate post ;-)

Fish

[JerryBurks]

I started using the Planet-CNC USB controller (mk2) a few months ago and it works just fine. It has its own microcontroller on board for independent timing of up to 9 steppers, a decent PC user interface and is quite inexpensive (about $250 with shipping IIRC). I run it on a pretty slow netbook and the controller has a ample in/out for independent limit and home switches, hardware jog buttons, pendant, spindle control, e-stop, coolant control and the like. If you provide separate power (e.g. from a cellphone charger) you can even disconnect or turn off the PC and still jog while keeping the zero-position.

Only problem I have infrequently is a loss of the USB connection and I suspect my netbook is on the way out. But even then the controller just stops, keeps the zero and I can start over with the G-code. So, I am very satisfied and see no need to deal with a parallel port and Windows timing. I am not familiar with e.g. Mach3 and can not compare the software features but it does more than I need to do incl. auto-home, auto tool length and zero sense. It does not do slave axes, I believe but the seller is updating the software about every month.

I am wondering to buy an Acer Iconia Windows7 touch pad PC to run the software and get rid of the keyboard and mouse in the shop.

[judleroy]

I have not used the k-flop but have the original k-motion board from dynomotion. The software updates come regularly an Tom always adds new features and fixes any issues. The updates work flawlessly even with my older board. The system output is lightning fast with amazing performance. It allows you to use steppers, brush and brushless servos. You can use Mach 3 but I'm very happy with there free k-motion Cnc software. It can do spindle control, tapping, motor slaving, backlash comp, and just about anything else. The best part is the prompt and unrivaled support from Tom the owner and developer. I have yet to see anyone offer any controller that can even come close to the power or customality of dynomotion unless you move into overcomplicated high dollar industrial control systems. (many of those can't even compete with dynomotion imop). I don't have any affiliation with dynomotion other then my own experiences using there system. I do know quality and dependability when I see it.
Judleroy

[Drassk]

The KFLOP is a very good controller, and can handle some serious speeds. I'd put it up against most anything out there, and I'm talking high end industrial controls as well. I retrofitted a 1994 Fadal VMC with one and it absolutely cooks now, the acceleration it's capable of with fully smooth motion is just silly.

[Druid_ON]

Fish,
A big "Thank You" for starting this thread. I'm a newby to all this control stuff and appreciate your additional explainations on usage and setting up of the KFlop controller. I have a heavy learning curve ahead but am keen on retrofitting an old Matsuura MC500 V with a KFlop/Kanalog and Mach3.
I will look forward to reading all of your postings.

[Al_The_Man]

I have a heavy learning curve ahead but am keen on retrofitting an old Matsuura MC500 V with a KFlop/Kanalog and Mach3.
I will look forward to reading all of your postings.

There is a also new Dynomotion/Kflop/Kanalog forum now.
Al.

[Druid_ON]

There is a also new Dynomotion/Kflop/Kanalog forum now.
Al.

Thanks Al! Perfectly timed for my project!

Keith

[Fish4Fun]

Druid_ON,

Here is a link to my "How To" thread on the KFlop in the Dynomotion forum. I have quite a lot left to explain in it, but the thread is moving along nicely.

http://www.cnczone.com/forums/dynomo...mach3_how.html

Fish