Hello Guest it is March 28, 2024, 06:41:25 AM

Author Topic: Open Source Mach3 Usb Plugin RFC  (Read 17205 times)

0 Members and 1 Guest are viewing this topic.

Open Source Mach3 Usb Plugin RFC
« on: January 05, 2013, 09:52:26 AM »
Hi All,

I recently decided to try my hand at building my own stepper controller board. I wanted to use USB as a communications medium and found that Mach3 doesn't support motion control over USB. I've been researching what I can find on implementing a USB motion plugin for Mach3. I've read all I can find on the subject and have installed older versions of MSVC.  I was about ready to start writing code when it hit me. I could be providing a solution for others and not just myself.... Being a fan of OSS and already working a couple OSS projects I decided this would be a great OSS project. So I wanted to do a RFC to get feedback on how I plan to implement my solution.

1. First, it seems that Mach3 holds timed step information in a ring buffer that gets filled by Mach3. The motion driver must take this information and feed it to the hardware. So my plan is to take the information from the ring buffer and compose messages to send over USB to the hardware.

2. It seems that USB has a poorly named communications mode often referred to as interrupt mode. However, this mode does not possess any interrupt ability. Instead it simply tries to service the USB port at a regular service rate, which is not guaranteed.  Due to this the timed step information taken from Mach's ring buffer cannot be sent in a timely manner to the hardware. This delay can cause issues with stepping. So the hardware must buffer this information before attempting to drive any motion or the motion may be rough and jerky...

3. Another issue caused by the delay is that of input response. Using USB as the connection medium means that the input data from devices such as limit switches, e-stop switches, probes, etc is delayed before being returned to the computer. This means the hardware must respond to the input before Mach has any idea the input has even occurred. So it seems that the hardware should store the input and axis positions at the time the input signal is triggered. This then can be sent back to Mach3 for further processing.

4. Actual communications protocol: After looking at various solutions with a wide breath of complexity, it seems that due to speed requirements and needed flexibility with hardware, a simple non-complex protocol is needed. However, some form of error checking should also be included. I like the basic idea of the Modbus RTU protocol. While it lacks specificity, its power is in its simplicity. Supporting a sub-set of this protocol over USB would allow for the greatest flexibility in hardware. However, computing the CRC on a large register block transfer may overwork some hardware devices popular with experimenters. So I wonder about simply replacing the CRC with parity which is easier to calculate IMHO.

5. Configuration of the driver would allow for byte and axis order and the maximum buffer size located on the hardware to be changed. The bits used in each byte to represent each axis' step, direction, and enable bits are stored in the axis structures stored in the ring buffer and would be used as packing values for a register value (registers are 16 bits wide). The same is true of inputs. The various bits set in Mach3's ports and pins configuration dialog will be used for bit position in a sixteen bit register. I do wonder if this should be expanded to two registers (32 bits) for maximum flexibility at the cost of slower communications? Information must also be returned to Mach3. So before sending motion information and when motion information is not available, The plugin will poll the hardware for input. The hardware response shall follow the same format similar to Modbus RTU...

6. Communications with the hardware would first send a byte wide device address, then a byte wide command code, word wide register address, and word wide register count. Next, a sixteen bit value containing the step, dir, and enable axis information just as it would look if seen form the parallel port's pins (ordered as the port/pins configuration defines).


This is my current intended approach. If anyone has comments or input relating or feel they may find this useful, then I would love your input on this project, your hardware, and your use of Mach3. I intend to make this plugin freely available as open source software. So your input is valuable to ensure the project is as useful to anyone who wishes to use USB as a communication medium for Mach3. It is my hope to provide a simple drop-in solution for USB communications for hardware experimenters using Mach3.




 

Offline poppabear

*
  • *
  •  2,235 2,235
  • Briceville, TN, USA
    • View Profile
Re: Open Source Mach3 Usb Plugin RFC
« Reply #1 on: January 08, 2013, 08:10:05 AM »
Hi,

     That sounds good!!  A good open source motion control plugin would be nice!

Just an FYI though, USB for motion control is maybe at best ok for small machines, i.e. desktop style stuff.
But others here have done the USB route for motion, i.e. Smooth Stepper USB, and a few others, it is just NOT
reliable on a larger machine, especially in any kind of electrical noisy environment. Thus the ESS (Ethernet Smooth Stepper),
FINALLY came out.  Other solutions like the Galil are also good.

     If you do go with USB ( I would target both 2.0 and 3.0 USB ), also, stay away from commercial stacks like FTDI, and go with an open USB stack or,
write your own. I don't know what chip set on your card your considering, but I like the PIC 32 stuff ALOT. Well, let me know if you choose to pursue
this, I post up a while back about doing an open source example (template) style motion plugin, WITH DOCUMENTATION!!  But, a guy started that, and
then decided to sell it instead, it then of course fell flat down. I am not complaining about that, just knew it would come out that way.

Later,

Scott
fun times
Re: Open Source Mach3 Usb Plugin RFC
« Reply #2 on: January 08, 2013, 10:12:58 AM »
Thanks for the input Papabear,

I am aware of the speed and timing issues raised when using USB as a transmission medium for motion control. First, using usb the OS controls when information will be sent. Though you can request a particular timing, it is not guaranteed. I would think that the same issues would arise using either-net. What are the advantages of ether-net over usb? Why does it work better?

As far as my plans. I am not targeting large machines. But experimenters looking to learn by doing. My hope is to produce a buffered driver board using the ST32F100 and L6474. Though least common denominator will be the various pics and atmega chips. I have done some very simply messing around with props and arduinos. For all but the simplest needs they fall short.

Can you comment on why I should avoid FTDI stack and why Ethernet is so much better?

Thanks!

Re: Open Source Mach3 Usb Plugin RFC
« Reply #3 on: January 15, 2013, 06:49:55 PM »
that's wonderful idea, hope you can complete it. there are a few commercial card $100+.
There shall be enough buffer for the input data from PC, then send out motor signal in constant speed. many products use FPGA, and can support 200KHz clock (Parallel port is 25K or max 100K). FTDI is slow, MPU w/ USB may be ok, but many one of USB 2.0 supports 12Mbps only.

« Last Edit: January 15, 2013, 06:53:47 PM by lastguy »
Re: Open Source Mach3 Usb Plugin RFC
« Reply #4 on: January 15, 2013, 07:26:52 PM »
Thanks,

I've been working on the hardware end for my own board. But the idea for the OSS USB driver is to supply the software and perhaps a couple hardware designs with different performance and complexity levels. I want to make the USB driver universal and as flexible as possible.

As for the hardware, I've incorporated an ENC28J60 Ethernet to SPI controller in what I expect to be my most complex design. A proof of concept design was done with the Arduino and followed with a prop version of the same circuit. Again, the Arduino lacked processing power.  But I've thought about using two arduino pro minis. The first would handle nothing but receiving data from the PC and storing it in ram. The second would take the data from ram and drive the motors at a constant speed. Something like the CAT24C208 dual port ram would work nicely for this.

I haven't done a lot of hardware hacking in many years and I find myself now rekindling that passion... So I have a half dozen or so breadboarded ideas working. I've also figured out that with the use of attiny mcu to do boot config on the L6474 it is possible to use the L6474 just as you might use older simpler driver chips like the SLA7078 driving it directly from port signals. A wrote a little python app to allow me to change the config. Once I narrow down the approaches that seem to work best I'll post my eagle files for the hardware. The firmware will take a bit longer as I need to turn my hacked code into something presentable.

Re: Open Source Mach3 Usb Plugin RFC
« Reply #5 on: February 07, 2014, 05:53:30 PM »
No discussion here for a while.

The arduino based rambo card has usb communications, and is programmable to accept whatever and control motors directly.
But if you just want to talk to a parallel interface, I'd suggest a look at the arguino type generic boards that have a USB for input and lots of programmable input/outputs.
It would have the smarts you programmed in, and could handle things like end stops.

Having a mountain of ignorance about mach3, still it appears it can do higher level output than parallel via usb, so the low level stuff can be handled
on a programmable card. Probably cheaper and faster than maiking hardware do it, and easier to adapt to new CNC milling hardware.

just a thot.