Yes, that would be super great! And would also integrate well with the conversational API -- assuming you mainly cut X material (6061, or A36, or whatever) then you'd set a "default RPM" for the tool, that the conversational system would pick up.
I slightly disagree. I've been testing an experimental probe and it is a pain that the probe screens only work with tool 99. For my situation it would be great if there were a way to set max RPM for each tool. That is, probes, drag knives and drag engravers would have a max of zero RPM and things like the SuperFly could be limited to perhaps 3000 RPM.
Yes, that would be super great! And would also integrate well with the conversational API -- assuming you mainly cut X material (6061, or A36, or whatever) then you'd set a "default RPM" for the tool, that the conversational system would pick up.
Some interesting ideas... Some harder than others to implement.
MANUAL means "MAN, U Are Liable" or "operated or controlled by hand, rather than automatically or electronically". You want the best of both worlds
1) Without changing the control board only 2 options come to mind. A relay in series with the drive door switch or in series with the start switch (which if I remember correctly is soldered to a daughter board on the cabinet door). Either would work, but neither are really elegant! Controlling the relay from PP wouldn't be quite so easy. There are no pins free on the parallel connector but you could use the second connector on the Mesa board or a USB I/O board. Then modify PP to drive the relay depending on the states you choose - I'll come back to these states later on in 3). Not really straightforward.
2) I'd probably set them both when the probe routines start. PP prompts the user to insert the probe tool if not already the current tool, and set the initial feed rate. Not too difficult (seems to work - unless I've missed something). It would however conflict with 4) if using multiple probes - guess how I know
3) If you're referring to the spindle lockout, how would PP know when the probe is in the spindle? The only possible method that comes to mind on a standard mill would be to check for normally closed contacts on the accessory port. This wouldn't work for an active probe and you wouldn't be able to leave a passive probe plugged in while machining. Everyone's needs are likely to be different. I can think of ways of achieving something like this but I'm not sure they'd be 100% reliable, and would also require mods to the PP similar to those I described in 1).
4) I'm working with 2 different probes and identify a probe by the tool description instead of tool number. Any tool containing the text "probe" in the description is accepted.
5) I'd say setting different maximum speeds for each tool is a different use case. I suspect this would also require changes to linuxcnc in order to enforce these limits, otherwise they'd only work with conversational code verified by PP itself.
Interesting discussion but I think we've hijacked the original thread
Step
Continuing the hijack:
Does that mean that one can access the tool description in gcode? If so how?I'm working with 2 different probes and identify a probe by the tool description instead of tool number. Any tool containing the text "probe" in the description is accepted.
It is a different use case which also includes preventing destruction of a probe due to accidentally starting the spindle. For example spinning a drag knife is almost as detrimental as spinning a probe. Remembering the maximum RPM for each tool is not part of LinuxCNC but could be very similar in implementation to Tormach's addition of tool descriptions.I'd say setting different maximum speeds for each tool is a different use case. I suspect this would also require changes to linuxcnc in order to enforce these limits, otherwise they'd only work with conversational code verified by PP itself.
MANUAL means "MAN, U Are Liable" or "operated or controlled by hand, rather than automatically or electronically". You want the best of both worlds
I like this definition, so true..................
mike sr
Not that I'm aware of - I used Python.
Tool descriptions are just for our convenience. Max RPM could be added the same way but it would need to be evaluated by (presumably) the preview functionality when loading a new file from any source, be it CAM, hand written or conversational. I'm assuming this feature would always need to be active and not just for use by conversational routines. The source for the module running the preview isn't provided (or at least I haven't found it) but it appears to be related in some way to the core LinuxCNC. I see what appears to be evidence of Tormach involvement. Yes, of course it can be done, but if the probe is in the spindle and the machine thinks it has tool "1" it still won't prevent the spindle starting.
I just thought of something interesting to try - that will keep me awake tonight!
In my previous post I wrote:
Well, I did miss something. I thought it would be possible to modify just one subroutine but some lines are in the wrong order for this to work, so every subroutine would have to be modified. Python code would also have to be modified anyway, so I implemented it all in Python and returned the subroutines to their original state.
Step
I was just making an observation, but lockout can be done a few ways.If you're referring to the spindle lockout, how would PP know when the probe is in the spindle?
A simple RFID chip on the holder and a reader on the spindle could do it. That's not even particularly expensive. However, it has drawbacks:
1. The RFID chip would unbalance the toolholder, which is important for high-RPM spindles
2. It only really helps for manual tool change setups, which might not be a thing worth optimizing for (for Tormach)
3. You would end up having to number your tool holders (where the chip is) rather than the end mills. I e, if I stick a 1/4" 3-flute in another holder, it now has a different number. (I have to re-measure the new mounted tool anyway, so perhaps not that bad)
Another option would be image recognition. Five years ago, that would have been science fiction, but a $35 Raspberry Pi with a $18 camera is plenty capable of recognizing different kinds of tools, and especially recognizing the difference between "probe or not," just by looking at them, these days. Especially with proper training sets. Lighting could be pretty consistent in this setup, too.
Another interesting opportunity in this case is using a zoom lens that lets you get a very close-up view of the tool/workpiece interface. In fact, you could conceivably do metrology this way, with proper calibration!
4k pixels wide focused on a 2 inch area gives you about 1 pixel per half-thou.
Interesting ideas! Why would the RFID solution only help for manual tool changes?
For point 3 you'd just need a table to map from ID to tool number. Change the end mill and just update the mapping table. Could be prone to error if the table isn't maintained correctly.
I'm not sure I'd rely on a camera to identify a particular tool like a probe. I'd rather identify all other tools and if in doubt assume a probe as the "worst case". If a finger obscures the tool and the system is relied on to positively identify the tool as a probe it could give a false negative. This fail-safe approach would probably limit its use to detecting one group of tools.
If you implement any of these be sure to post a video
By the way, you don't need to calibrate a camera to do metrology!
Step
Well, yes. More accurately: You need to calibrate the software that processes the pixels that come out of the cameraBy the way, you don't need to calibrate a camera to do metrology!
(I built my own 3D stereo camera back in the days, it was an exciting process to get pictures of flat surfaces to come out as flat after reconstruction )
Regarding "this mainly is important for manual tool changes," I'd assume that if you have a tool changer, then you won't have the problem that the machine says "tool 4" but the tool in the spindle is "tool 99."
Because if the machine says "tool 4" then that will be inserted by the tool changer. (Or you get a "tool not mapped" exception.)
Don't know what the Tormach ATC actually does for un-mapped tool changes, though; this could be a real problem there too?
I'm using a completely different approach to metrology using a camera. It requires no calibration and is very accurate, even over large distances. Apart from measuring distances between any two points it can also measure angles between any two edges, distances to angled edges, diameters and centres of holes or bosses, but I've never actually used any of those features. I only use it for measuring thread mill profiles and setting up lathe tools.... I guess I'll have to make that video now....
I agree with you on the ATC. If you ask for tool 4 and that tool is in the ATC then you have to assume the machine will do its job properly - otherwise the ATC would just be an ornament. There's always operator involvement at some stage in the process, but if I were to implement anything like this (which I'm not planning on ) then I'd consider it to be what we call a *safety net": not something you should plan on using, but a system that's likely to catch you if you make a mistake.
Step