[gene-pavlovsky]

Hello,

I am wondering if there is a possibility to share the position information with another MCU (e.g. an Arduino). I guess it would be possible to do via the computer (to which both devices would be connected) and the API you provide, but is it possible to do it somehow directly? Is there any interface (SPI, I2C) on the PCB which I could hook into, using one of the existing 8P8C connectors, some internal connectors or pin headers on the PCB (I've got the unit open when I receied it, but didn't pay enough attention to what was on the PCB).

I'm planning an electronic leadscrew (ELS) controller for my Hobbymat MD65 lath, to replace the original change gear mechanism.
Here's an overview of the project (for a different lathe) that I plan to base my efforts on.

An idea came to my head, that if the ELS controller could get the coordinates from Caliper2PC, a couple of neat features would be possible to implement. By knowing the X axis position, the controller could suggest optimum spindle speed and feed rate (depending on material type and turning operation to be performed, to be selected by user on the screen). The controller could even set the spindle speed automatically, if the lathe's spindle motor is a 3-phase unit powered by a VFD, and the controller is hooked up to the VFD. In this case it would be also possible to implement constant surface speed, e.g. when taking a facing cut, the spindle speed can be automatically increased as the X axis reading changes.

The ELS controller can also monitor the Z axis coordinate from DRO and check that they agree with the coordinate that is calculated based on how many steps were sent to the leadscrew stepper motor driver. This way the controller can detect if the stepper motor loses synchronization (e.g. lack of torque, overspeeding, power feed clutch and/or half nuts - if present - disengaged by user), and take appropriate action (e.g. stop the feed and/or spindle, display an error message).

Best regards,
--Gene

[Tomer]

Hi Gene,
 
Your project sounds very interesting.

A direct hardware output of the values comming from the Caliper2PC interface is not implemented. The protocol used for communication between the Caliper2PC interface and the host PC is an internal protocol and is not open, published or communicated with users.

The Caliper2PC system supports many devices using different protocols. The data provided from all channels is packed into a stream that is then sent to the host PC. Depending on the devices connected, the data is processed in the software and the output values are calculated within the Caliper2PC software.

The API offered facilitates interfacing with users' own applications and supports all input and output devices.

Additionally the software offers an TCP/IP Modbus interface with the MACH3 CNC software.

The Mach3 software is based on an open loop control system. The pulses are given to the motors and the software assumes that the steps are executed by the machine. It does not verify if steps are done by the mechanics. Sometimes the mechanics loose steps. The Mach3 software has no way to realize this. With the Caliper2PC system the machining process can be verified. In case of lost steps the Caliper2PC software can feed hold Mach3. Please note that this is not a closed loop system, because the Caliper2PC system is not a realtime system. Lost steps can be detected only after they were lost. A bigger damage to the part or to the machine can be avoided by feed holding Mach3. 

It might be possible, adding an output COM port to the software, so that values provided by the Caliper2PC software can easily be processed in projects using MCUs (e.g. Arduino etc.). On the hardware side, inexpensive USB to COM port adapters can be used (see picture).

   

The position and the values provided by the Caliper2PC software through COM port can serve as references for projects like your project. Would this kind of COM port implementation be useful? What format would you suggest putting out the data to best suit MCU based projects? A kind of handshake logic must also be thought of, so that data can be requested by the MCU.

[gene-pavlovsky]

Hi Tomer,

Thanks for such a thoughtful and detailed reply.

It's also very interesting to learn about the Modbus interface for Mach3.
There is at least one ELS implementation (e.g. John Dammeyer's ELS) that allows to switch between manual ELS mode and Mach3 CNC. The feature you mentioned could be applied in that case. I haven't decided yet if I want to plan for a possibility of using Mach3 in the future. It sure seems logical to do so, considering that the lathe will already be equipped with all the necessary hardware (a spindle encoder and stepper motors for Z and X).

A COM port and a USB-to-TTL adapter such as the FTDI-based one you've shown would be the way to go. Such support can either be added directly to Caliper2PC software, or implemented as a separate piece of software using the .NET API you already have. I don't have much experience in designing protocols for such communications. I'm more of a user than a designer when it comes to things like this. I can do some research, think about it / make some experiments with .NET once my project is somewhat realized. And if by that time you will have already implemented this feature, even better!

P.S. For some reason, every time I get a new message notification e-mail from your forum, Gmail thinks it's spam/phishing attempt, showing a message like this "Gmail could not verify that it actually came from caliper2pc@gmail.com. Avoid clicking links, downloading attachments or replying with personal information."
I wonder if you could do something to prevent this from happening.

Thanks
Best regards
Gene