Hey I won't be much help but I would love to see how you did a break press gui!
On Sat, 23 Apr 2022, 03:26 Ted, <laser...@gmail.com> wrote: > Good morning! > > I've been working on converting an old Cordax CMM to more current > technologies and am wanting to start building out the user interface. > (The basic items like changing out for glass scales, reworking the air > bearing controls, tramming and getting a digital probe on the end, > initial interfacing to LCNC are already done and functional; it's now > time to get to the math taken care of). > > The TL-DR version of my goal is to create some version of a manual CMM > interface like MCOSMOS(tm) in function, (that software is one of many > popular commercial CMM control packages currently available today). I'm > not wanting this to necessarily become the next open-source CMM > alternative - just something that can be functional and extend the > knowledge-base with LCNC. Thus, it's a hobby project, not a commercial one. > > Note that this is NOT a probing-routine challenge; this is not meant to > retrofit a cartesian machine with the existing hole-probing under > machine control. In fact, I do not want it to be forced to be "CNC" (or > DCC for us old folks) - which is why I want to concentrate on the manual > math first. When it eventually becomes DCC, that's fine, but to try that > first would actually be a path that would involve a little cheating as > well as constrain possibilities. > > To that end, I'm looking for some assistance in a) where to get some > LCNC realtime variable data, b) how to deal with some certain variable > types in c (in a halcomp) and c) some thoughts on best practices for > that same programming. I'm quite familiar with John's gtk tutorial > (https://www.gnipsel.com/linuxcnc/gui/index.html) and have referenced it > many times (thank you!) while creating custom guis (such as for press > brakes and punches) and also like some of the info from (Presei's?) > qtdragon work > ( > https://linuxcnc.org/docs/devel/html/gui/qtvcp.html#_handler_file_in_detail > ). > > The first big math challenge I would like to solve, and something that > even MCOSMOS is a little lax on is vector-defined probing offsets. I > don't have a good name for that, but it's what I'm going to call it. In > a traditional in-spindle probing scenario, say a round hole, you set up > your probe with an assumed-diameter precision tip (ie ruby sphere), > calibrate using a ring gauge or similar artifact, then make a single > radial or a single length offset for that tip. In most cases, it gets > distilled down to an averaged radial offset and a single length offset - > since that is the base structure of how tools are handled, and a spindle > probe has to be fit into that construct. This does work ok for probing > to +/- a couple thou, and since that is often a good capability of > cutting, the results match up acceptably. On a CMM, we are not > constrained to a single vertical probe shaft, nor orthogonal probing > approaches, nor tolerances that can be averaged out to a single offset. > > For example, my CMM now has micron scales. The stylus has more than 1 > micron runout, and since it is not being spun, there is no averaging. > (Note: don't spin your probes in the spindle under power. I didn't mean > to infer that.) More so, I can approach a feature from any physically > available angle, which means I really do need to calibrate on multiple > points. This is known practice already, and if I were using MCOSMOS, I > could set up my stylus offsets for anywhere from 6 to over 30 (? - don't > know I've never done that many) approach offsets. I would like to do the > same in LCNC. As a side note, I don't think even MCOSMOS takes > vector-based touches into approach, I think it just runs a lot of > best-fit math because you can really confuse it if you try to measure an > inside bore when you specified an outside feature... > > So to get to the point (no pun intended) I am comfortable with the math > to infer radius and sphere centers from surface points (even though I > don't like matrix math) - but I need to find two more pieces of > information: > > a) if from a python (or c-ish) script get the current vector of travel > in 3d space? I am not sure if there is such a data value available, so > would I have to create some form of time-domain capture loop (say on 0.1 > second intervals) as you need 2 coordinates to infer a vector component. > Are there velocity variables exposed I could access, and if so, are > there any best practices on capturing that information? I think if there > has been any work done on profile probing that might be a reference? I'm > not sure if I've seen any hal components doing polar conversion math yet... > > b) how can I pass on multi-dimensional arrays through a hal component? > I'm not even sure what the workflow for this data is yet, but if I had > to make an example, a struct of a 4-component XYZQ vector (thus 4 > doubles or floats,the "q" is just a 4th future coordinate) that then had > 4 instances of that struct (to give 4 touch coordinates, or future > thinking, perhaps more) - how could those be programmed and passed to a > hal component? I have examples for single arrays (using the dotted > notation) but my first pass on doing multi-dim arrays using that type > (and simply by double dotting) was not successful. (I am comfortable in > c++, my python and ansi C is less refined...so variable typing knowledge > is google-fu dependent) > > For b) the intent is to be able to create smaller fast-run components > such as: > > "cmm-sphereo-from-4-points" - which takes in 4 coordinates and > returns center plus radius - note there is no approach vector info on > this one, it's 4-xyz's in, and 1 radius, 1 xyz out. > > "cmm-spherotouch-center" - which takes current machine coordinates, > known center reference coordinate, known radius (from above), the > approach vector coordinates and returns a difference which becomes an > offset for the calibration table. > > "cmm-coord-vector-offset" - which might take the approach vector, > the tool/stylus number, have to lookup a tool/offset table for > calibration data and then returns a single corrected xyz coordinate > > "cmm-3pt-inbore" - which might take 3 xyz corrected from above and > calculate an inner bore radius and center > > "cmm-6pt-inbore" - which might do same as above but finds an > evolving tolerance band based upon iterating through elements 1,3,5 then > 2,4,6 -(possibly more combinations) etc.... returning same as above but > largest fitting result and smallest fitting result. > > -and so on, which would also then permit creation of wizard-based > programming in the gui to create measuring recipes which could be saved, > edited, recalled, run, data output, etc. The important thing to notice > is the requirement for many multi-dimensional data values.... > > The functional result would be to: > > a) first use a probe of zero-size - not physically possible, but > lets substitute "really pointy". We can then calibrate the system to a > known sphere, eg a precision tooling ball, and those first captured > coordinates can then be fed into the sphere map to give us a confidence > on the size of the ball and its position. This is not really part of the > calibration procedure, but just to ensure that our basic programing > understanding is correct, and that we can actually figure out where the > center of a sphere is. We are restricted to points on the sphere the > probe can reasonably access, but hitting 40% on top is quite feasible, > assuming a vertically mounted probe. > > b) confirming the sphere properties, now we have a known/accepted > center position and radius, which we can now move to a non-zero-size > stylus (real probe ball) and using that known sphere data plus the > approach vectors, back-calculate the offset and stuff it into a > calibration table (note that this also takes into consideration the > probe actuation offset since it is unique to the approach vector). We > have made an assumption that the tooling ball is precise, and that is an > acceptable assumption. We are not assuming the ball is mounted in a > particular symmetric location, which is what a single radial offset does. > > c) now with approach vectors and a "Triggered current machine > coordinate" we can now forward-calculate a feature coordinate. I don't > need to know right now if it is inside a bore or outside a boss, it's > just the "real" world coordinate of some physical transition from void > to part, but we also happen to know the travel vector from void to > contact as a side-effect, so we could infer inside or outside based upon > if multiple approach vectors would intersect on an internal or external > virtual sphere.... > > d) now we have datasets to work with, whether that next step is > setting up a virtual work plane, or actually getting coordinates to > define a hole. > > There are other math items like what is the best fit for an approach > vector that is close but not exactly as calibrated? That is important > too, but baby steps, right? > > Thoughts and opinions appreciated, > > > Thanks, > > Ted. > > > -- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
