11-08-2020, 07:34 AM
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.
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.