forum.cncdrive.com

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





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

Daywalker wrote: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

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.

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.)

Daywalker wrote: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.

sebba wrote:

Daywalker wrote: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.

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.

After opening or closing the drawbar I would check the sensor.

I did it via LED query, since UCCNC doesn't have a sensor query internally, but I saw that you wrote an #Event to decode the sensor port/pin on the LED.

Example:


Open

//activating drawbar pentru eliberare scula
if (Debug) exec.AddStatusmessage("Debug: ---Activating drawbar");
exec.Setoutpin(Chuckopenport, Chuckopenpin); // Opens power drawbar to ensure that the new tool can be accepted
exec.Wait(delay); // Wait 500msec

// Check Drawbar Opened
if (Check_Drawbar_Open){
while(AS3.GetLED(LED_DRAWBAR))
{
exec.Wait(1000);
if (AS3.GetLED(LED_DRAWBAR))
{
exec.AddStatusmessage("Drawbar not Opened !! (No AIR?)" );
}
if(exec.Ismacrostopped())
{
exec.Clroutpin(Chuckopenport, Chuckopenpin);
exec.Wait(10);
exec.StopWithDeccel();
exec.Setvar(0, 100);//stops manual change macroloop blocking the output for eject
MessageBox.Show("Tool change was interrupted at collet open!");
break;
}
}
}

Close:

// Clamp Tool
exec.AddStatusmessage("Debug: ---Deactivating drawbar");
exec.Clroutpin(Chuckopenport, Chuckopenpin); // Close the chuck with pneumatic valve

//Check Drawbar Closed
while(!AS3.GetLED(LED_DRAWBAR)) // check Collet has Closed
{
exec.Wait(1000);
if (!AS3.GetLED(LED_DRAWBAR))
{
exec.AddStatusmessage("Drawbar not Closed !! (FAILURE !)" );
}
if(exec.Ismacrostopped())
{
exec.Clroutpin(Chuckopenport, Chuckopenpin);
exec.Wait(10);
exec.StopWithDeccel();
exec.Setvar(0, 100); //stops manual change macroloop blocking the output for eject
MessageBox.Show("Tool change was interrupted at collet open!");
break;
}
}

For the tool query, I would check whether the tool sensor is off when getting a new tool.

When the tool is the tool loaded the sensor is on

And when a tool is put down, the sensor is off.

This also applies when changing manually.

That's my idea or would I implement it.

doable, but I'm little bit busy for the next 2-3 days