The TM245P is not the greatest machine. It's original software was awful, it had a wildly complicated multi-point matrix factory calibration which is unlikely to be replicated. It also lacked the vision system of the TM245V. The machine itself though, is very stout, very well build, and begging to be revived.

Can it be converted to OpenPNP?

TM245P Overview

This machine consists of an STM32F407 on it’s main board, an STM32F301 inside the head unit, unknown control systems in the feeders that all communicate with UART(*unverified) over CAN Bus (SN65HVD230).

There is an additional ‘Power and Communication’ board but it does not contain and MCU or CAN transceiver.

Code, notes, discussion

Two Paths Forward.

OpenPNP commonly uses the Smoothieboard as the hardware interface. This has been successfully ported to the STM32F4 in the Charmhigh CHMT26VA, which, as stated above, TM245P front unit is also running. This would be ideal and beyond the port itself, would require only translating incoming G-Code to packets to be transmitted over the CAN Bus.

The second path forward is to create a drop-in replacement board for the front unit. As the interface would become OpenPNP this would only require communication over the IDC connector and the LCD/Touch screen would become optional. This would also require Reverse Engineering the protocol or replacing all of the MCUs in the system. Not ideal.

We need the protocol.

Hands down, the best option is to reverse engineer this protocol in an effort to minimize overall work. So far the best guesses are it’s UART at ~512kbit/s, 1 start bit, (maybe?) two stop bits, but so far consistently good looking data has yet to come out. This is were you, Dear Reader, come in! Please take a look at the Issues list, particularly this one and please get in touch if there is any way you can help out.

Logs

What's That UART?

The groundwork for getting started on this project was laid out in this 2018 EEVBlog forum post. In it, Luiz Renault suggests the data rate is 512kbit/s based on the smallest pulse width. My results before vary slightly but should be in the same range. The minimal bit length looks to be ~1.740us, not far off Luiz’s 1.960us that can be seen in the scope shot in the second post. So 512kbit/s seems like a reasonable rounding point.