ATC - new approach

[sebba]

Hello people,

I have a big dilemma: to post in Macros or Screensets? Nevermind...
I did it here...

I am talking about an ATC solution, made with a lot of macros and some modifications of the Defaul2019 screenset.
Maybe a future version will be different but for now this is what it is...
https://github.com/Haimana/HTM_ATC

I am somehow in the "alpha" release but I made some successful tests today so I decided to "make it public"
The main "features" and "ideas" of my approach are somehow borrowed from MachStdMill screenset, made by Calipso Ventures long long time ago and - unfortunately - discontinued.

Obviously, I had to make some modifications (macros, brains and screenset editing) for MachStdMill to have a proper ATC environment. My previous implementation can be found here: https://github.com/Haimana/MSM_ATC and should be considered as the basement of current work.

But too much it too much, so, the main features are:
- can handle a rack with 10 tool holders and up to 96 tools (why 96? I'm wondering too, but I don't want to force UCCNC's tooltable, for safety reason)
- can handle tools which are repeatable (RH, Repeatable Holder tools) and NRH (Non Repeatable Holders) in the same time.
- can handle slot sensors for safe reporting
- ...
- and many to discover

main ATC screen

ATC setup page

unfortunately I have no time right now for writing a documentation but I'll be happy to answer any question here

still, for now, the screenset is made for UC300ETH_UB1 board. so if you want to test it on different board you have to use the screenset editor and copy it for your board.
the slot sensor inputs, for now, are coded to port 5, pins 2-11.
and yes, some parts are unfinished (edit current tool button), some are unfinished and some are not working at all
other things to mention: for best results, it needs a fixed probe in TCP (Tool Change Position) where tools are measured or loaded/unloaded (if available but not into the rack)

happy milling,
Seb

[sebba]

Unfortunately I also get an error message when I use the newer version when loading the M99998 macro

yes, I am able to reproduce this error for a new installation.
I'll check what is "lost" and hope to have a fix asap

[sebba]

quick and dirty fix: add a value for 20330 in [UserTextfields], something like -100, let's say
it fixed for me
I'll check tomorrow for a better fix for future versions

20330 store the position of the TCP-TP (Tool Change Position - Tool Plate), a different name for a fixed probe.
it's position is determined by using a "Master Tool" which have a known length and after that it is used for measuring the other tools.

[Daywalker]

So, after the PM here's a picture and my modified M6 macro.

Maybe there is something or a way to implement this, if it is possible. Otherwise I'll adjust accordingly.

What I noticed is that there is no built-in error detection, i.e. if you start the tool change but abort/stop it via Stop/Reset, the machine stops, but the tool is changed in the software.

Perhaps it can be solved with an “error check” or variable check after each step. (like "Visionforge" once built it into an ATC macro.)

[sebba]

What I noticed is that there is no built-in error detection, i.e. if you start the tool change but abort/stop it via Stop/Reset, the machine stops, but the tool is changed in the software.

Hello,
I just added this but is not yet updated on Github. Soon, very soon!
Regarding your needs, I'll do my best. I don't want to do this only for me so, let me know what exactly do you need to add/modify.

[Daywalker]

Regarding your needs, I'll do my best. I don't want to do this only for me so, let me know what exactly do you need to add/modify.

DeDust means Airblow, which is already included.

Sensors for the drawbar and tool clamp would be nice.

The pneumatics story with sensors for magazine retracted (IN) or extended (Out) and output for the valve would be secondary or is more specifically tailored to my magazine and I could install it myself.

[sebba]

ok, my sensor's "logic" is like this:
- for returning the currentTool into the rack, if have it's own slot (already declared in rack) or find an unoccupied slot (with no tool set on)
-- check the slot's sensors for "free". If free, continue movement. If not free, wait some time and report error with Abort/Retry/Ignore dialog. Abort will cancel the TC operation, Retry will wait one more period for sensor readings and Ignore will continue movement.
-- after tool is returned in position and drawbar activated (for releasing the tool) the machine will move at "checkZ", few mm above "rackZ" and check again. This time is checking for "occupied slot. Same like before, if status is not as expected, will have that Abort/Retry/Ignore option.

- for loading a tool from rack is almost like before, just reversed. First time will need an "occupied" report for the corresponding slot. Abort/Retry/Ignore if status is not as expected. After the drawbar is de-activated (for grabbing the tool) the machine will raise at "checkZ" and expect a "free" slot report from sensor.

So, let me know when your sensors have to be checked and what status is expected.