Serial command set for ATC - Interfacing

Im trying to work out how to interface with PP to build an ATC.
The USB/serial device is a silicon labs IC, im sure that using silicon labs device tools i can reprogram the devices serial number to match the ATC device's serial number in the rules file.
what i dont know is what command PP sends out to check the ATC is there and what commands are passed back and forwards between the ATC and PP.
I have built a Teensy USB I/O expansion clone and dont see any reason why the same cant be acheived for an ATC.

I can remember years ago downloading a Git file with the Zbot build on it but alas it has vanished with age.
There is a guy called Pete who built a robot arm to do tool changes, I have tried to contact him without success. He is on this site, so Pete if you can please help.
To the rest of you guys, any help would be greatly appreciated.

On a side note, Is there anyway of automatically homing axis in PP instead of pressing each axis ref key one at a time.
GRBL used to have a home button which drove Z then X&Y. - not found anything in the book yet.

+ what is charge pump output for ?

I can't help personally myself. Have you seen the videos by Chad Downey who is making an ATC for his Tormach 1100? You might find some help there.

https://www.youtube.com/channel/UCaJ...y4nWnXshIEAr7A

Thanks Steve,
I have left a message on his channel and hopefully i will here back from him.
Progress so far - the reprogramming of the usb bridge's id didnt work very well, at all. The appear to have a serial number written in which says somthing like Z-Bot ATC device is set for 57600 baud n,8,1 and i have created a rule by duplicating the existing rule and altering to match my device. connected a usb serial device to it to monitor if any commands were being sent from PP - nada
as they say what we have here is a failiure to communicate. I have scoured the web and apart from the teensy I/O expansion ther is very little else.
I guess it will just take time to figure it out, problem is i will either end up too old to do it, the technology will have expired or or i will have treated myself to a Haas VF1.

I, for one, am eagerly awaiting any progress you may make on this. I've been thinking about building an ATC myself and ran across the same lack of info on the serial commands that cause the tormach unit to operate.

I have been working on atc for teh PP but have not gotten to teh hardware side of control( PLC) I have found PLCs that can run S/D drives and I/O. They can run serial or Modbus . I would be great if PP ran modbus but serial can do the job it is just more work and programming.

It would be nice IF Tormach would sell us their control board but I don't think that will ever happen as they just buy them from someone else . The Someone else will not release any as well. So it is back to teh DIY interface method.

I am willling to help work on an interface if anyone else is interested.

Just a thought, (;-) TP

Just another thought . You CAN run an ATC from Gcode and macros and not have to bother with a PLC interface. You just have to have enough extra I/O to run it all.

(;-) TP

I have been in touch with this guy - David
https://www.youtube.com/watch?v=nQDUkIXAy2w
He has designed and built a controller for an ATC based on the arduino UNO. it would depend on how much he is asking for the interface board.
The USB bridge he is likely to be using will be the FTDI chip, The arduinos only come with one of three/four devices the cheap CH340, an atmel and the FTDI ( there is an FTDI clone as well).
Its certainly easier configuring the FTDI to have the same settings (vendor ID, serial etc) than i have found with the silicon labs device - still working on it.
As for adding more control functions to PP this project works https://github.com/jwatte/teensy_tormach_usbio, im sure i found it on this site all credit due to its author. There should be no reason why other code couldnt be ran on the teensy as well as the I/O expansion, that way the Inputs and outputs could be used to perform other functions and then report back by outputting a signal.

Quote:

---

Originally Posted by vmax549

Just another thought . You CAN run an ATC from Gcode and macros and not have to bother with a PLC interface. You just have to have enough extra I/O to run it all.

(;-) TP

---

Jim's ATC is run by subroutines, Arduino and a Tormach USB I/O board.

https://www.youtube.com/watch?v=PQeydNMtN2A

> The USB bridge he is likely to be using will be the FTDI chip,

FWIW: All Arduinos since the Uno use something like a small USB Atmel chip (Atmega 16u2) for the serial part of the programmer, unless they have built-in USB connectivity themselves (like the Leonardo.)
The FTDI chips were the thing about 10 years ago :-)

ha ha the man himself, It is your teensy code is it not. jwatte. you are a god.
I was wondering tonight why i couldnt find an uno with an FTDI when i looked in my box of bits. I can remember back in 2012 FTDI getting pissed about clone devices and and altering their driver which ended up being pushed out by microsoft and killing loads of USB devices, was it not somthing to do with the US courts that made them backdown or something. The good thing is the FTDI chips are cheap and building a DIY Uno isnt so hard either. If only i could get a hint where to start. Once the device is visible and PP interogates it (sending VE ?) then finding where PP sends/receives commands to the zbot and what it expects to get back then the back of the project is broke. The rest should be academic.

Yes, that's my code :-)

It turns out that the protocol is super simple, so you can just go dig it out of the Python script itself, instead of having to "sniff" it.
(But sniffing is fun, too.)

While I've built my fair share of boards, these days I prefer to use a Teensy for most things, as its software is high quality, its performance is great, and I don't need to worry about anything around the microcontroller, and can instead worry about the thing I want to do.

Jwatte are you interested in producing an ATC interface board that is compatible with PP ??

(;-) TP

Any chance of a boot up the arse in the right direction. I keep scouring through any file which hints at a name with ZBot in it hoping to find "VE" without success (It may be different for the ATC)
loads of self put on stuff and defs but nothing tangible. My thought process is that the response will be constructed from a string detailing Zbot, the type of ATC (say 8 Tool) and version.
the latter being obtained from external (dll's - whatever python calls them).

This looks like that giant leap for man kind:devious:

Quote:

---

Originally Posted by mejasont

This looks like that giant leap for man kind:devious:

---

Looks like a very interesting file!
I'd nevertheless recommend you check out the PP code as well, otherwise you might find PP trying to update your firmware! There's also a nasty trick in there to adjust the step count on older versions - you probably want to avoid that happening to your changer.
As I mentioned in this post:
https://www.cnczone.com/forums/torma...ml#post2248900
the board in question was a "test for a more complex exercise" - so it should now be clear what that exercise was :) Unfortunately my ATC project has been shelved since June 2019 due to other priorities but I may take it up again at some point. I also couldn't decide on a hardware solution because I don't like how the standard 4th axis interferes with some tools in the ATC.
I initially programmed the interface on an Arduino Duo but the target would be a PIC. The i/o board uses a FTDI chip to emulate the Tormach I/O board, which is certainly the way I'd be going for the ATC as well. However while I waited for some new FTDI devices to arrive I just temporarily modded PP a little to get the Arduino up and running.

Step

Quote:

---

I also couldn't decide on a hardware solution

---

If I'm ever doing this, I'd very likely be doing it using an arm, not a carousel.
The protocol would then have to emulate the carousel interface. I don't know whether the "io" use goes all the way to the LCNC HAL -- if so, a better option might be to just implement a different M6 macro file ..