Hello Guest it is March 28, 2024, 10:02:29 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Monotoba

Pages: 1
1
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.


2
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!


3
Mach SDK plugin questions and answers. / 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.




 


4
Thanks,

That is exactly what I needed since I can't go right to the buffer. What VB to C converter are you using?

5
Mach SDK plugin questions and answers. / Plugin Access to GCode Window
« on: December 26, 2011, 06:10:11 AM »
Hi, I am new to writing plugins for Mach3 but I have written a few simple wizards. I am looking to move some of my wizards to plugins because debugging in MachScreen is difficult for large wizards. Most of my wizards simple write to the teach file when a user clicks the "Post GCode" button. My first attempt at using the OpenTeachFile() and CloseTeachFile() methods with the VS2008 Plugin wizard failed with unknown function calls. So what I need to know is:

1. Is there a way to write text (gcode) directly to the code window in the main Mach3 screen?
2. Are there functions that can be used to write and load the teach file from a C++ plugin?
3. I have been able to run my gcode right from my plugin but this gives no visual indication of the code execution... If there is no way to load a file into Mach from a plugin like you can from a wizard, then is my best approach simply add a textarea code window to my plugin?

Thanks for your input.

P.S. I have searched for similar post but found nothing and I do apologies if this has been answered before and I simply did not locate the post, or if I have posted this to the wrong area.


Pages: 1