Jump to content
AutoDesSys Forums

¢hris £und

  • Content count

  • Joined

  • Last visited

  • Days Won


¢hris £und last won the day on May 9

¢hris £und had the most liked content!

1 Follower

About ¢hris £und

  • Rank
    Advanced Member
  • Birthday 03/20/1969

Profile Information

  • Gender
  • Location
    Westcliffe Colorado
  • Interests
    all things dirt, stone, metal, glass and wood

Recent Profile Visitors

8,178 profile views
  1. ¢hris £und

    fZ vs a Real build.

    Hey All, Here is a prototype project that I am working on. This is actually the 3 iteration (that won't work.). I think I am getting close, however. The other two designs were completely different. ver4 will be based off of this ver3. I get to use 3 of the existing parts (with modifications.). 5 of the 6 parts were produced on a manual knee mill and one part on a manual lathe. the other parts were purchased and modified to accept my parts. Ultimately, it will cut tubing to a prescribed length. (tubing shown in the OGL renderings, but not in the final attempt.) Currently we hand cut them at roughly 120k pieces per year. The device will be controlled by a microcontroller (small computer) that will require me to write the code. The code will be written in Python as well. Which is why I have been so excited for fZ to adopt Python. Even though this will not work as hoped/intended, I did learn a lot about machining and designing something to be so. And, had fun producing it. There is One major design flaw and a few minor ones. Too, there are 2 major execution flaws and a few minor ones (minor ones, I just worked around as I built it.) It is fairly small. In the photos, the grid is 1" There are two adjustable components on the mechanism. One: to adjust the height of the limit switch. This will control the length of cut tube. Yes, I am using stepper motors, where I wouldn't really need to use the limit switch. However, the tubing that I am cutting is kind of slick, so there may be some missed feed steps. Two: to adjust the pressure the feed drive wheel places onto the tube that is, well, fed. This part is hard to see in the images. Both of these adjustable mechanisms are spring loaded to maintain a tension/compression type mechanism to hold its position. I used 3 sizes of screws. 2.5mm for the parts that required them (motors and limit switches.) 3mm for all the fixed holding screws. and 4mm for the adjusting screws. I wanted to only use 2 sizes, but the feed wheel screws needed to be longer than the 3mm options I had. So, I made both adjustments use the same size for future ease of dealing with. It is this project that is inspiring me to write a set of scripts that will figure out all the drill sizes needed. Each screw can use 4 different drill bit sizes. drill to tap, close fit, free fit and head counter bore sizes of drill bits. For those interested in the details about the script, the text is at the bottom. (I don't go into the code, just discuss the details regarding dealing with all the screws). A couple of broken taps and a broken drill bit later, here we are. Version 4 (or 3.2 depending on how we look at it) will be simplified some. Mostly, the adjustable parts will be independent of each other. I Placing the different drill holes manually is pretty tedious.. This version I mostly did it manually. The next version, I hope to have the scripts at least functional. The scripts will use table data for all the screw data, Tap data, and drill bit sizes. These will include both ASME (imperial) and ISO (metric) data. (last image). There are currently 66 metric screws sizes (with Course/Fine threads) data included (this is important for tapping holes) and 56 ASME sizes (including Course, Fine and Extra fine threads). Tables don't have the screw you want? Just add it to the table and the script will be updated. Right now I only have tables for Cap Head Screws, as for the most part, that is what I am interested in using for my projects. Other tables can be made and even the current ones used as templates for new screw types, as much of the data is the same. Biggest difference will be the screw head and it' dimensions. The script should be easy enough to write to accept these other tables. I doubt I will build the tables, as that was days worth of work just for the two I have now. For now, I am not going to build in screw lengths, but will add fields for the user to input this data. This data so far has been a lot harder to gather. All told, I expect there to be around 800 Cap Head screws if you include the shank/thread lengths. I do intend for the script to build the screws for visual intent only. e.g. I am not going to technically build the threads as these should be not visible in projects. And, I think it is a waste of memory. So these scripts will build and deal with visual mockups. Someday, assuming the API will let me, I could have a map placed on for the threads. A drill bit table is also referenced so that in ASAE, the 3 systems of drill bits as well as ISO metric mm sized drill bits will be used. As well as use the closest counterpart across the measurement systems. Currently 680 drill bit sizes are included. from .0135" (.3429mm) to 2" (50.8mm)If you have a drill bit that is not in the table, just add it and the script/s will be able to use it. Too, the script will be able to cross over the two measurement systems without issue. (this project, the parts are built using Imperial tooling as that is what I have, but all the pre-manufactured parts including the Cap Head Screws are metric) In addition, I am going to write a script that will translate objects using the different measurement systems. This won't make up for it being built in, we can hope, but it should aid in dealing with projects that require both. (most of my projects will require both to some degree.) Now the bad news: I think this will take me a while to write, at least to it's completion. There is one issue that I don't see a solution to as of yet. This may take a workaround for the time being. I do hope to have a rudimentary version working soonish. Though, I already know it will require a lot more user input that what I intend to accomplish. Ultimately, I would like to have it hold the data for dimensioning and BOM. Maybe even figure out the screw lengths for us. (((Big if there, as I don't know how to account for all the variables.))) Hope somebody besides me could get use out of something like this. I am going to make it any way, for myself. Cheers! ¢hris (tedious) £und Metric Screw data
  2. ¢hris £und

    can someone make a material duplicator script

    John, Apologies, I have not had a chance to look into this. Good to know. And, good thing. Right now, there is very limited functionality for materials in the Python API. It may be possible, don't currently know. Though, one might be able to do it in the old FSL language. I haven't opened that book up in quite a while. ¢£
  3. ¢hris £und

    Rotation Failure

    Bo, reading through your first post again, I still think what you are seeing, in both the rotation case and the retrace points is that the display is flipping where is is drawing the "fold". Which of course, you don't care about since you are going to turn the shapes into curves any way. To be clear, it is an OGL display issue, not a rotation or a tracing of your points. Though, I do agree that 6 had a simpler snapping methodology. I have come to really like 9s. Especially when I turn off the guide snapping. If I don't that constantly gets in my way. Though, I don't think guide snapping is impacting you here. Too, I tend to bump up my numerical accuracy pretty high. I find that this seriously impacts my ability to snap. Pretty sure 6 did not have this issue. ¢£
  4. ¢hris £und

    Rotation Failure

    Bo, I too am using a M1 Mac mini with OS 12.01 (not 12.1, I do not see that this is available). And am not seeing the problems you mention. As far as updating, it should update at 4Mbp/s. I was able to update my 2012 Pro up to recently with lower speeds than that. We were lucky to get 1Mbp/s Though, now spaceX has shown me the way. So, can't say specifically to the M1. Sorry I misunderstood your needs. ¢£
  5. ¢hris £und

    Rotation Failure

    Bo, I think ZTEK is right about the triangulation. I attempted to stitch them together prior to triangulation and after. The before did not. The after triangulation worked. I don't think the issue is with the rotation but agree with ZTEK that it is because they are not planar. If you "show normals" on the object (stitched without triangulating). you will see that it still has 2 faces, but the system doesn't know how to display one of them. The normals are floating in space. But one of the faces isn't being displayed despite the information being there. Even as I attempt to rotate one of the objects into position, its displayed "fold" changes to between the other two points. Essentially f•Z is seeing the data as being nonsensical and is arbitrarily showing you where it thinks the fold should be. When I was still building the balloons, I primarily modeled this way (manually building and stitching things together). In OGL display mode, it is difficult to see these conditions. So, I would have to often flip back and fourth between wireframe and OGL. primarily working in wireframe. A habit I have not gotten over.
  6. ¢hris £und

    Off topic-sort of... Metric system users.

    Oh, I did find a table from a jewelers website that have far more granular drill sizes than the typical. Plus some odds and ends sizes that I will use. ¢£
  7. ¢hris £und

    Off topic-sort of... Metric system users.

    Whoa! That is a bolt alright! My guess is it is a prop of some sorts. Imagine the tool it would take to turn something this. But a quick search pulled up this: Also looks like props. Straps look a little puny. I don't think I will use these in my script. Though, all you would have to do is add it to the table data and it should work.
  8. ¢hris £und

    Off topic-sort of... Metric system users.

    I find that surprising. Even here state-side where "everybody" fancies themselves as a self reliant cowboy🤪, we have standardized tooling for machining quality precision. It is a bit of a mess of having 3 notations for gauge sizes (naughts, numbers, letters) and then intermixed fractional sizes. Still, the precision is there. At best, a machine shop would get locked into purchasing all their tooling from 1 company, or possibly a consortium that maintains a proprietary tooling set. And still, this would have to be published somewhere so that shops would know what to buy. At worst, each and every machine shop would custom build all their drill bits and gobs and gobs of other tooling. ??? Think of this, clearance fit, interference fit, transition fits and so much more, each kind of fit would have their specified sizes. On top of drill bits, all the Reaming tooling would have to be custom made too. Below you will see my 2 sets of reamers. And these only cover the fractional set. The large set is from 1/16" through ½" stepped by 1/64". The smaller set is the over and under by 1 thousandth". And only cover 7 of the fractional sizes. They also make these reamers in the gauge sets as well as over and under sizes. I don't own the gauge sets because I do not have enough money. If each machine shop custom built their own, or even if there were conglomerate level standardizations they would still be so damn costly, I am having a hard time imagining it. Despite that being an argument from incredulity. A good gauge drill bit set costs $600 and these are mass produced. (bottom picture, with a few missing from my set.) Santa, thank you for those two links. The first does help me fill in a bit more data and the second will definitely help fill some knowledge gaps. Tapped out... Yea, If you or anybody are interested, here is are a great couple of videos about the history of precision. We can essentially thank the leap of human progress in the last 400 or so years to this one concept. Personally, I find it fascinating. I guess for now, I will just build the script to the best level I can. Cheers, ¢£
  9. ¢hris £und

    Off topic-sort of... Metric system users.

    Thanks everybody! I think I should clarify a bit more. I have those tap charts, in fact a lot of my information that I built my look up table came from the Little Machines chart (Santas second submission.) I probably am getting a bit pedantic here, but I would like my script to eventually be useful for general machining not just bolt/screw sizes. And I guess I am getting tripped up by differences in precision between the two systems. And, I was hoping to build all of the tables ahead of time so I can just focus on adding features to the code later. So, to clarify, if you look at the Imperial portion of that chart. for example: A Number 4-48 uses a drill size for tapping of #42. and the next size larger bolt of 5-44 uses a #37. (I chose the two fine pitch bolts.) There are 4 whole drill sizes between the two bolt sizes. (38,39,40,41.) Most bolt size in imperial has a number of drill bits in between, like the aforementioned. Of course, being imperial, there is no consistency (in that regard, it is a complete mess.) Take a look at the full chart below. The green highlighted columns are the bolt sizes. The drill bit sizes often (though not consistently) have a step size of .001". (#s 71,72,73 for example). or .0254mm (not shown in this chart) So, what I am looking for is a "Full" chart of metric drill sizes that has the in-between drill sizes, not just the bolt sized drills (tapping sizes) used in machining. Like the imperial chart above. The best metric set I can find* is in .1 mm steps. or nearly 4 times that the imperial system has. (.003937") But, then again, stepping up by .1mm is pretty crude by machining concerns. and Stepping by .1 mm doesn't fill the needs for tapping all sizes of metric screw/bolts. as many of these are in .x5mm values. Considering the official definition of the inch is actually by metric value (25.4mm). I would assume that the drill sizes of the metric system would be superior. (finer) I suppose too that all holes could be bored to size. But that is an extra step in the process. A step that has a lot more setup involved. Thanks again! ¢hris -bit pedantic- £und * https://www.grainger.com/product/CHICAGO-LATROBE-Jobber-Drill-Bit-Set-2VTE5
  10. I have a question for the metric system users. I am working on a new fZ set of scripts for drilling and tapping holes (Machinist type work.) The base script will build a mockup of the bolt (for now, I am only doing socket cap head screws, but the script can be built to do others in the future)... No biggie here. But, I am also going to have the script cut the associated holes in the intersecting materials. These different holes will be, drill size for tapping, close fit, free fit and counter sink. All determined by the placement of the screw/bolt. I am not using the built in screw/bolt generator as I don't need a visual of the threads. I need the information for the hole sizes to cut. While I have not figured out how to go about doing everything, I am starting with building look-up tables for the sizes.I am tired of having to lookup in a table for the drill sizes, build the boolean tool based on what cut, on and on. for each and every bolt/screw. I have everything charted for the imperial system including metric equivalents. However, I want to make it work for native Metric system users as well. While as far as I am concerned, the metric system makes far better sense, I am having problems finding index drill bits for tapping metric sized threads. I can easily find sets that are in .1mm increments. But I need them in .05 increments or even better for drilling and tapping sizes. I would even like to get to .025mm increments for machinist level tolerances. As this is where I have the imperial information lookup tables built. When I search for such indexes, again, I find .1mm increments. Of course, since I am searching from within the U.S. I think my searches are getting generalized. I am having a difficult time believing metric system machinists track back and use imperial tooling. Especially since the metric system makes more sense to start. Eventually, I will have the script do the dimensioning and callouts (when permitted by the API.) As always, I will share my scripts. Thank you, ¢hris £und
  11. ¢hris £und

    9.2.01 Doesn't work on Monterey 12.3

    I suppose it is a damned if you do, damned if you don't type of a situation. On the secrecy side, we know how it affects us. However, development doesn't always go as planned. A problem isn't as simple as initially thought. Maybe even unsolvable for the current time being. The environment for a perceived tool or method changes. Other issues and or opportunities arise in the mean time, pushing or halting what was discussed or promised. Ostensibly, this is the case with Python integration. I don't like it, but that doesn't mean the company is going under. They do, just like any other company, have to pick and choose where applied resources will be of the best benefit. Quite frankly, if one of these scenarios (or others,) speculation is going to happen any way. My concern is, if the gloomers and doomers get loud enough, their POV becomes a self fulfilled prophecy. But, hey, if it comes to pass. They can sure feel good about themselves for being right. So smart and insightful to predict a downfall they essentially promote. As far as I am concerned, thinking based on fear, hopes and or frustration isn't rational. Of course, I am not saying that we shouldn't express our frustrations, certainly we should. Just know where to do it and don't let a wave become a tsunami. That wave, despite its size, is aimed at us just as it is aimed at ADS. Dan M. Please consider something. We know that PowerCADD is somehow going to be associated with formZ. Whether it is fully integrated, or a side car type relationship, we do not know. PowerCADD ,historically, was strictly Mac. Does it make sense to take on the burden just to dump its assets? PowerCADD doesn't have any PC assets. If ADS were to have the intent to dump the Macintosh, they would probably have chosen to align with a PC based CAD company instead. And I seriously doubt they are going to dump the PC. (I wouldn't expect PowerCADD to be part of fZ10. Despite that, I hope it is.) My 3.5 cents worth. 3.5¢ £und
  12. ¢hris £und

    Phantom numbers

    Lately, mine have been going away. Not sure why.
  13. ¢hris £und

    9.2.01 Doesn't work on Monterey 12.3

    One thing to consider, Python 2.x is no longer in development, and is not optimized for the M1. Hopefully this issue is compelling enough for ADS to update their use of python to 3.x. Which, in my opinion, they should have done in the first place. Dan, I suspect it a little early to predict the death of Mac development by ADS. With the Advent of the M1, Apples market share has gone up. Though, quit possibly not in this niche of the already niche market. ¢£
  14. ¢hris £und

    SpaceMouse Pro

    I don't have the device, but here are some troubleshooting tips. If you open your keyboard viewer. What does it show as the input? If it is showing something you are not expecting, then it is the device/OS interaction. If it is showing what you want, then it is fZ. Though, this doesn't fix it for you, it can show you where the problem is. You could try downloading "keyboard maestro" to see if it can resolve it for you. https://www.keyboardmaestro.com/main/ Good luck, ¢£
  15. ¢hris £und

    FZ / edit cone of vision issue

    Also working for me. Monterey M1-mini. ¢£