[(EVE)Shadow]

Hi all,
I have an idea for a device that I think could prevent some types of machine crashes (e.g. most of those shown in video below). The basic principle of operation is measuring the distance between the tool and part (fast and in real-time). If the tool comes within a few mm of the part during a G0 move the device will automatically E-stop the machine before the tool can collide with the workpiece. I'd like to get an idea of how useful this could be in real-world circumstances before I spend too much time figuring out the technical feasibility of building the device. Thoughts?

Thanks!!

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

[deadlykitten]

hy / if there would be a device, that would measure the distance between the part and the tool, than also there must be a "decisional process" within that device, that should take a decision

this "decisional process" will behave conditionally, and the "limit value" should vary from tool to tool, from operation to operation, thus that "device" should comunicate with the "program"

fact is that the "device" will always be one step behind the program, thus the machine will try to move, and the device will analyze that movement after it has begin


there already exist such "devices" that work one step before the program, that the device analyzes the potential movement, and if all is ok, than the program is allowed to continue

kindly



ps : 0:43 is wrong is terrible wrong - there are real situations that lead to cnc crash, without being the operator fault; in mass productions, stuff that happens only once at thousands (eq) of parts may lead to signifiant downtime, missalingments, etc ... there is always a 1st time for everything

[(EVE)Shadow]

Thanks for the response. You are correct that there will have to be some "decision process" in the device. I think that this could be quite simple or quite complicated depending on how adaptable the machine controller is. Let me clarify a bit: the "decision process" will have no dependence on the tool or operation because the device will always be measuring the shortest distance between the tool and workpiece. Let's define a "crash distance" which is the minimum distance the machine needs to decelerate to 0. My assumption is that there is no circumstance where you want to make a G0 move within a "crash distance" of the workpiece. Therefore, the decision process can simply be: if (machine is in G0 mode && distance < "crash distance") -> E-stop the machine. This paper has more details that might make it more clear:
https://www.researchgate.net/profile...hine-Tools.pdf

[deadlykitten]

hy shadow / if you use a short drill to cut 30mm deep, and after that another drill will continue, that 2nd drill will rapid in ( or fast feed in ) until circa27mm

this particular case can not be protected by that device, simply because the 2nd drill will go fast among a toolpath that goes through the "crash distance", and even futher

also, there are many other common situations for rapid within a "crash distance" : for example repositioning movements when milling something, etc




newer machines have torque limits, and once the effort goes over those limits, the machine stops : of course, the higher the speed at the impact, more trouble will occur : a collision at 100% rapid may break a tool, and lead to cnc missalingment, but it should not call for cnc spare parts however there are cases when something needs to be replaced : for example, on a lathe, it may be possible to crash the turret into the chuck, the turret will be ok ( maybe a bit missalingned ), but the spindle bearings won't be ok

it is possible to lower that torque limit, so to reduce the "threshold value" : generally, main issue is not the "threshold value", but the speed of the impact as a consequence, a crash at "slow speed" with "high threshold value" is softer than a crash at "high speed" with "low threshold value" ; dynamical factors = static * 2-5-7

going fast & safe is kind of a bet




i don't wanna say that what you wish to do is not ok; i hope that you'll find something usefull in all of these, and tune your approach kindly

[(EVE)Shadow]

Your point about the drilling case is a good one. So this leaves us with decision logic that is more complicated than I originally imagined - you would need to find a way to ignore G0 moves within a crash distance of the workpiece (actually if they use a rapid feed move that is fine because we are already ignoring feed/G1 moves). This seems like a solveable problem though. I'm imagining an addon/post for CAM software that can perform the necessary logic. If we can overcome that hurdle (ignoring false positives due to G0 within crash distances of workpiece) I think we are still left with a fairly broad class of preventable crashes, right?

Thanks for playing devils advocate. It's just what I need to help refine the thinking.

Cheers

[deadlykitten]

hy shadow / few persons dig cams, and most of them are satisfied with the standard experience, or they wish but don't have time to modify the CAM
... so modifing a CAM is possible, but unfortunatelly is not common

you focus on the area of "wrong G00 comand inside a small clearance zone", and this area is only a piece of a puzzle

if someone uses a CAM to create a program, that CAM should not output "G00 within a crash zone", so tuning it's post to prevent this, is a bit ... with a little bit of ... and more ... you got it, right ?

so your idea is ok, but you can not implement it inside a CAM : simply because the CAM creates a nice program, while the collision won't be the CAM fault

i read also that article you shared; there is an approach about minimizing damage when a crash occurs, and it involves "senzors" and "signal comparison" :
... "signal comparison" and some "senzors" will react only after the collision
... some other "senzors" will react before the collision; why don't you dig this ?

i don't know, contact Volvo, those guys are experts who knows ? kindly !

[hanermo]

You have an interesting idea !

I feel it will not work.
Based on shops I have seen.

Crashes occur because of bad planning/jobs/programs or something braking like tools/jigs/fixtures.

E.
If a drill gets dull on deep drilling, esp. in SS, the part heats up a lot very fast.
This makes the drilling progressively harder and heats even more.

Both hole size and other later machining ops get less accurate on hot SS parts.
Until something fails..

.. or fail on other stuff.
A client was very upset their custom made 3000€+ diamond tools were getting trashed.
Normal lifetime was 1 yr plus on 100k+ units production per tool per yr.

I have been contemplating anti-crash stuff myself..
and it would be relatively complex, not cheap, and need to address all the typical issues above automatically in real time.

[awerby]

It's a good idea in theory, but I'm afraid that in practice, it would be a royal PITA, always triggering false alarms and shutting down a program when you want it to just keep running.

[(EVE)Shadow]

i read also that article you shared; there is an approach about minimizing damage when a crash occurs, and it involves "senzors" and "signal comparison" :
... "signal comparison" and some "senzors" will react only after the collision
... some other "senzors" will react before the collision; why don't you dig this ?

i don't know, contact Volvo, those guys are experts who knows ? kindly !

Just to reiterate, what I have in mind is something related to what is presented in that paper - it can detect the distance between tool and workpiece, thus allowing you to stop BEFORE a collision occurs.

Let's say the problem of false triggers due to G0 moves close to the workpiece is solved (e.g. in the CAM software we are able to output a G/Mcode indicating when the sensor should be ready to catch a crash). I think that still leaves many crashes that can be stopped.

E.g. user enters wrong tool number
E.g. user enters wrong tool offset
E.g. fixturing is not exactly the same in reality as it is in CAM (clamps in different position etc.)
E.g. fixture breaks during machining severely enough that the tool would collide with it during G0

Any time the machine is making a quick (G0) move and the tool is more than a "crash distance" off in actual vs expected position.

Cheers

[deadlykitten]

hy shadow / stopping before the colision is a nice thing to do

i don't believe that you will be able to involve a CAM; also there are other methods to create a program, so what will you do with those that don't use CAM ?

you should not consider a CAM, because it is not on the cnc; you need to conect to something that is on the cnc

so why don't you conect to the encoders directly ? there are guys delivering cnc_park_management solutions, that simply conect to any kind of cnc; thus, you may conect that way, so to read the speed of the cnc axis as it occurs ( or whatever data you wish, and is possible to read or to calculate ) : when you read a rapid, or a fast feed, ( or any kind of movement ) simply activate also that senzor of yours it may work

i have some contacts:
... https://machine.report
... screw the website, talk with this guy : [email protected]

i believe you should read data from the cnc controller, and keep the senzor active all the time during rapids ( and maybe fast_feeds ), and use some constrains, like to ignore detection when machine is near the cabinet wall, or near the ATC door ( depends on detection radius/sphere of your senzor )

kindly

[(EVE)Shadow]

Thanks for the tips! I will give them a shout.

Cheers

[deadlykitten]

guys from "machine.report" are from Bulgaria, and it may be a bit too far from you i don't say that you should not talk with them

they just connect somehow to the cnc, but i can not tell anything more about it


however, on okuma controls, is no need for such extra hardware and software connections, because the control itsself has an open arhitecture; so you may gather " somekind of data " from a standard machine; if you wish to go deeper, and acces more important values, you will have to use the API library, which allows acces to more "underthehood" options

i don't have experience with API, but i can recomand you the guys from Morris Midwest; unfortunatelly, i don't have a contact inside if all works well, a programmer shuold alow acces to those datas, and you may need am interface software, to connect it with your program / just saying

i have recently installed API so to achieve cnc protection, by "signal comparison" method, but god knows when i will have time to dig this




by the way, that senzor of yours, what radius of detection does it have ? also, what reaction time ? is it big ? can it be installed easy on a cnc ? detects metal / plastic / etc ?

[(EVE)Shadow]

That's good to know about okuma... interesting. I will look into that a bit.

The device doesn't exist at this point ) so unknown detection radius. It will only detect metal.

[deadlykitten]

ok shadow / all the best

it was nice talking with you

[(EVE)Shadow]

Thanks for the advice!!

Cheers

[StergiosCNC]

Thanks for the advice!!

Cheers

Hello to everyone! I just upgraded and using SolidCam2018...
I would like to ask about collisions between the stock and the tool.
On SolidCam2018 there is an option ''fixture collision'', which on pocket operation fixture collision is disabled permanent.
On 3d iMachining operation its enabled at the beggining but as soon as i choose my tool, fixture collision is disabled again...
Is any solution you can give me??

Thank you.