A tool changer a differnt way...

Hi Pete,
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 serially 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 a carousel ATC.
I can remember years ago downloading a Git file with the Zbot build on it but alas it has vanished with age.

Ideally i want to leave PP untouched, pyton i know very little about and linux even less.

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 (everybody spit) 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 ?

[quote="MrJTJinx" post=166946
On a side note, Is there anyway of automatically homing axis in PP instead of pressing each axis ref key one at a time.


+ what is charge pump output for ?[/quote]
Yes , you need to have homing switches for all axis and have home_sequence set in the ini file for all axis.
It sends a constant frequency to the enable the drives, so in case of something going wrong that frequency or pulse train stops, hence the drives will be disabled.

Thanks Tom,
The further i get into PP the more im learning, thats a good thing right.
I just discovered yesterday that the coolant and spindle direction pins go logic high as soon as power is applied to the PC motherboard and dont extinguish until the GUI is up and running, a tad annoying to have coolant spraying everywhere until the system is up and running i thought.. The PP breakout board appears to be doing quite a bit of trickery with the charge pump signal.
So my progress (not very much). I have created a rule for the USB device. (I coppied the rule for the Zbot ATC) and changed the configuration of the CP2102 USB bridge device to what i thought would be similar to the zbot usb device - this might not make sense to some but i have done it before with FTDI devices and tools to give periferals a dedicated serial. Im sure this is going down the right path. It sounds like tormach are getting their devices already serialised going by the description in the header of the rules.d file. As yet im having no joy its not transmitting to the device for the handshake/hello im expecting PP to send. I may have it wrong, perhaps the ATC initiates the coms and then gets told to be quiet by the response. As the Zbot is a usb connection to PP im anticipating serial commands, any help in this direction would be much appreciated.

Pete
Are you using serial or Lan, I have downloaded your files for the robot arm and read through them but cant see anything which looks like serial commands.
The USB IO expansion is waiting for command (serial.available) and expects to see VE being transmitted, it then resonds withthe version string "teensy for tormach I/O ID=0\n"
PP must send somthing different to Zbot ATC? otherwise both devices could respond at once.
Just to lay the cards on the table, im nothing more than a hobby programmer of a basic level but i am a damn good all round mechanical and instrumentation guy. I know coders hate helping those they deam incapable of programming but hey what can i say, techies can be useful sometimes as well. The mechanics of building this ATC are a walk in the park. Looking forward to your input.

I think a charge pump would stop the unwanted logic...e.g. don't supply power to any of the relays until a 50hz square wave is detected.

I know it's a bit late.....sorry 'bout that..

Best, Ian