nophead / nopscadlib Goto Github PK

That is allow /*! ... */ comments, so

/*!
blurb
blurb
blurb
*/

could be used as well as

//!blurb
//!blurb
//!blurb

This would make editing documentation much easier.

Had an error when running libtest.scad on a Linux machine running OpenSCAD 2019.05
I changed line 76 to use a capital S as follows: use <tests/Swiss_clips.scad> and the error went away.

I'm sometimes getting this error

 File "../nopscadlib/scripts/tests.py", line 59, in compare_images
    pixels = int(f.read().strip())
ValueError: invalid literal for int() with base 10: '1.06957e+006'

Seems to be an issue with how python deals with literals, floats and ints, see https://stackoverflow.com/questions/1841565/valueerror-invalid-literal-for-int-with-base-10

I think you need to use pixels = int(float(f.read().strip()))

As in the title :)

I'm planning to make RPi4 10x Cluster with PoE, all ready but I'm working on the case/cluster model.

While useful, the diff files produced by magick compare are not always required. Sometimes it would be better to have a faster build.

Using SHOW_THREADS means there is a possible (although unlikely) clash with another program. Also, if anyone lists their environment variables, it's not obvious what program uses SHOW_THREADS. I suggest it is changed to NOPSCADLIB_SHOW_THREADS .

I find it hard to figure out which values to use for pose() - do you have some hints to do that without the need to do make_all to see the result?
I can not figure out to zoom, so I only show some part of an assembly. I would like to zoom in where a small part is fitted onto a much larger part. Is there a way to do that?

OpenSCAD supports multiple directories (separated by ;) in OPENSCADPATH, see https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Libraries . However, it seems, exports.py and views.py assume that OPENSCAPPATH only contains a single directory.

It is currently 2.5mm, which is more than M3_cap_screw or M3_dome_screw. It looks a bit odd as it is, and also it means there is interference when a grub screw is used without making a corresponding hole in a vitamin. I suggest it is changed to either 1.3mm or 1.0mm.

This is required, for example in certain forms of coreXY. See image, the current belt gaps are highlighted in pink.

Fix will be submitted soon.

There is some inconsistency in how objects are centered on the z-axis. For example rods and studding are centered about the origin, whereas comp_springs are drawn starting at z=0.

This is just the first instance I have noticed, I imagine there is more inconsistency. It would be good to at the very least identify and list the inconsistencies, but hopefully they could be corrected before the library becomes too widely used.

It would also be good to consider implementing a center parameter (like OpenSCAD does) for some if not all objects.

I rendered an STL of my full assembly once many months ago but I'm having a hard time figuring out how to do it now. Is this something that is supported by NopSCAD or did I manage to hack something together back then?

Quite often it is useful to have variants of a project. At a simple level this could an item in different sizes, but items could be customised in various ways.

I suggest something like the following:

1. a new variant parameter to the scripts (eg make_all.py). This is passed on to OpenSCAD as $variant which can be used as desired.
2. when using a variant, the build scripts look for $variant_assembly rather than main_assembly, ie if the variant was called small, then it would look for the small_assembly() module.
3. the generated output files are put in a variant subdirectory, eg small/readme.html, small/stls etc.

Would this be feasible? I'd find it very useful.

I'm sometimes getting a FileNotFoundError in tests.py when doing a make_all, see error trace below. I haven't been able to track down what exactly causes this to happen, but do have a fix, see at end.

magick BC200/assemblies/main_assembled.png -trim -resize 280x280 -background #F8F8F8 -gravity Center -extent 280x280 -bordercolor #F8F8F8 -border 10 tmp.png
Traceback (most recent call last):
  File "../nopscadlib/scripts/make_all.py", line 47, in <module>
    views(target)
  File "C:\Users\martin\Code\GitHub\OpenSCAD\nopscadlib\scripts\views.py", line 199, in views
    update_image(tmp_name, tn_name)
  File "C:\Users\martin\Code\GitHub\OpenSCAD\nopscadlib\scripts\tests.py", line 68, in update_image
    shutil.copyfile(tmp_name, png_name)
  File "C:\Users\martin\AppData\Local\Programs\Python\Python38\lib\shutil.py", line 259, in copyfile
    with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
FileNotFoundError: [Errno 2] No such file or directory: 'tmp.png'

The addition of two checks of if os.path.isfile(tmp_name): fix the problem.

def update_image(tmp_name, png_name):
    """Update an image only if different, otherwise just change the mod time"""
    # print("in update_image\n")
    # print("tmp name =", tmp_name, "\n")
    # print("png name =", png_name, "\n")
    diff_name = png_name.replace('.png', '_diff.png')
    pixels = compare_images(png_name, tmp_name, diff_name)
    if pixels < 0 or pixels > threshold:
        if os.path.isfile(tmp_name):
            shutil.copyfile(tmp_name, png_name)
        print(Fore.YELLOW + png_name + " updated" + Fore.WHITE, pixels if pixels > 0 else '')
    else:
        os.utime(png_name, None)
        os.remove(diff_name)
    if os.path.isfile(tmp_name):
        os.remove(tmp_name)
    print("\n")

The use of the height named parameter in linear_extrude is unnecessary and results in oddities such as linear_extrude(height = thickness), linear_extrude(height = depth) and linear_extrude(height = length). These would read better as linear_extrude(thickness), linear_extrude(depth) and linear_extrude(length).

I made a makeshift 6808 bearing using

ball_bearing(["6808", 40, 52, 7, "black"]);

but the rings are oddly wide. I see no way to change them directly - or is there one?

The colour of PNG files is hardcoded to [0, 146/255, 0] in render.py. It would be useful if the user could override it so that it was the same as pp1_colour, perhaps by a command line option.

Assembly titles are formed by splitting the assembly function name on underscores and then title-ising the result. So, say, PSU_cover_assembly becomes "Psu Cover". This is unnecessarily restrictive to the user, they may prefer "PSU Cover" or "PSU cover". Also title-isation doesn't really confer any benefit - the user could manually get the same title by choice of assembly function name. I suggest the title-isation is removed.

Could be as simple as adding this to rails.scad:
MGN12H_carriage =[ 45.4, 32.4, 27, 13, 3, 20, 20, M3_cap_screw ];

and

MGN12H= [ "MGN12H", 12, 8, 10, 25, 6.0, 3.5, 4.5, M3_cap_screw, MGN12H_carriage, M3_cs_cap_screw ];

views.py contains some logic to decide if big or small assembly pictures should be used. However this logic is not always correct and there is no means by which the user can override it.

I've got a project with some tests in the tests directory. tests.py cannot currently be used to run them, but a few small changes could rectify this. In particular:

1. tests.py does not search the project tests directory. Adding tests/ to the locations array fixes this.
2. The output is hardcoded to readme.md, which means it overwrites the output from make_all.py.
3. libtest.scad is required for tests.py. This is not required in the general case.
4. The heading blurb is directly encoded in tests.py. It would be better if it was scraped from libtest.scad - this would have the added benefit of making it easier to maintain the blurb.

Using this example code, the first pulley in the path should be "outside" the loop of the belt, while the other 3 are inside the belt.

path = [
  [0, 0, pulley_pr(GT2x20_toothed_idler)],
  [50, 0, pulley_pr(GT2x20_toothed_idler)],
  [-100, 0, pulley_pr(GT2x20_toothed_idler)],
  [-100, 100, pulley_pr(GT2x20_toothed_idler)],
];

belt(type=GT2x6, points=path);

The belt path generated around that pulley is:

Which puts it on a completely different path than intended on the machine.

I'm not really sure if this is a supported use case, but it's come up in a project I've started working with. Thanks!

In

I noticed this since OpenSCAD was complaining about not being able to open rounded_rectangle.scad.

Not generally a problem for assemblies, but it does make the exploded view in build instructions look a bit odd. For efficiency it would be possible to only show the bolt hole in the exploded view.

The generated markdown does not show nicely in all viewer.

Tables should have at least 3 dashes, eg not |:--| but better |:---|.

Would you like a PR? I have also made a carbon tube, would you like PR for stuff like that?

There is a similar project called BOLTS (also GPL-3.0). How about merging to it?

Quite often it is useful to add text after the parts list, for example to describe possible alternatives for parts, or where to source difficult to obtain parts.

Some minor changes in the grouping

1. Move variacs and transformers to the right and put the iecs up below the power supplies
2. Move the cable strips to the right and put the blowers to the right of the fans
3. Swap the block containing the extrusion, panel meters and stepper motors with the block containing the bearing blocks, the pillow blocks and the sk_brackets. That groups things that have to do with rods nearer the rods.

I see that you have

function inch(x) = x * 25.4; //! Inch to mm conversion

I use

function inch(x) = x * 25.4; //! Inch to mm conversion
function foot(x) = x * 25.4 * 12; //! foot to mm conversion
function yard(x) = x * 25.4 * 12 * 3; //! yard to mm conversion
// (For fractional inches, 'inch(1 + 7/8)' will work as expected.)

function mm(x) = x * 1.0; //! mm specified
function cm(x) = x * 10.0; //! cm to mm conversion
function m(x) = x * 10.0; //! m to mm conversion

While they aren't strictly necessary for my scripts to work, they make it perfectly clear that a number I'm using is a vector of the specified type rather than a scalar. May I suggest adding them?

Does that make sense?

Thanks for providing this great library!
I'm using it for the first time and I believe my design follows the documented methodology. However I'm stuck with a run-time error, when I try to execute make_all.py:

$ make_all.py 
openscad -D $bom=2 -D $preview=true -o openscad.echo scad/bom.scad 
Generating bom ... done
Traceback (most recent call last):
  File "...library path.../NopSCADlib/scripts/make_all.py", line 39, in <module>
    views(target)
  File "...library path.../NopSCADlib/scripts/views.py", line 111, in views
    assemblies = bom_to_assemblies(bom_dir, bounds_map)
  File "...library path.../NopSCADlib/scripts/views.py", line 73, in bom_to_assemblies
    ass =  flat_bom[-1]
IndexError: list index out of range

The design I'm running this on is can be found the following Github repository:
https://github.com/hotwolf/DIYLaserBed

Also, the bom.py call in the beginning generates an empty BOM file.

I'd appreciate it if you could give me a hint, why this is not working or what I'm doing wrong.

Thanks!

Duet 3 - Duet 3 Mainboard Dimensions & GrabCAD STEP model

Split out of #7 so that issue can be closed.

is there a way to grok a tree from here? Openscad is good but the taxonomy is actually more distinct. #CADQUERY #CQPARTS

I'm getting the following error when it gets to the codespell part of the make script. My python experience is limited, so I'm not sure how to resolve this.

codespell -L od readme.md 
Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 582, in _build_master
    ws.require(__requires__)
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 899, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 790, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.VersionConflict: (codespell 1.17.1 (/home/ben/.local/lib/python3.8/site-packages), Requirement.parse('codespell==1.15.0'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/codespell", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3257, in <module>
    def _initialize_master_working_set():
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3240, in _call_aside
    f(*args, **kwargs)
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3269, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 584, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 597, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 785, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'codespell==1.15.0' distribution was not found and is required by the application

My system defaults to python 3, but I've done a pip2 install codespell and pip3 install codespell to make sure both bases are covered.

I have noticed that sometimes make_all.py fails to generate renders of the assemblies. At first I assumed that I had something bad in my .scad files so I did a git bisect all the way to the first commit where I was able to generate images (I had generated some in between as well). Every single commit I tested failed to generate images. Then I reset everything back to how it was before the git bisect and suddenly I got image generation again. It just happened to me again now and I decided to try cloning my project into a new directory and it is still failing there.

The output status of the command is 1, but I'm not seeing any errors in the out (other than "target missing", but I'm not sure what exactly is missing).

Any troubleshooting suggestions?

Not sure if this is a good idea or not. What about rotating each layer of a polyhole, like is done with the poly countersink. I think there are three possible advantages:

1. Cosmetic. When viewed from above on a printed part, the polyhole will look more circular.
2. It might give a better "grip" when used for self-tapping holes?
3. It might bridge better, when drilled into a bridge.

What do you think? Is this a good idea or not?

I don't think you've added threads to the bolt holes on the stepper motor.

In pulleys.scad GT2x16_plain_idler is specified as 7.0, whereas GT2x20_toothed_idler, GT2x20_plain_idler, and GT2x16_toothed_idler all have a width of 6.5. Additionally my GT2x16_plain_idler and GT2x16_toothed_idler pulleys have the same width, and I have seen spec's on the web stating it should be 6.5mm.

A project may include parts that are not part of the final assembly, for example jigs to drill holes, or to align parts. Also there may be alternative parts, eg the same part with self-taping holes or threaded inserts.

Is there a recommended way to include these types of things in the BOM?

NopSCADlib creates a number of different temporary files during the build (eg tmp.png, png.scad etc). These are created in the root directory of the project, which creates at least two problems

1. If you interrupt the build, the temporary files need to be cleaned up.
2. You have to add the temporary files to the .gitignore of the project.

I suggest the temporary files are created in a tmp directory, so the root directory isn't cluttered by them. Specifically, for projects without variants, the directory tmp would be used, for projects with variants the directory variant/tmp would be used.

In particular stls/printed and dxfs/routed are not created.

"The travel prpoery is how far it"

Downloaded NopSCADlib today, gets:

And similar with stls/printed/times.txt

If I manually create the missing directories it works.

From this image:

It looks like the bearings in the long versions are recessed a lot further than the short versions but pictures on the web don't look like that https://www.makeralot.com/scs12luu-linear-slide-block-p8/

I checked the dimensions of the SCS12LUU and LM12LUU bearings and they both seem correct, for the short version I get 3mm each end but for the long version I get 6.5mm each end. So from the dimensions our picture is correct but it doesn't seem to match reality. I also can't see why the recess would need to be any deeper for a longer bearing.

Does anybody have any of these parts to check. Is the embedded bearing actually longer than a normal long bearing?

Hi,

due to a measurement mismatch I investigated why the KP08 pillow block was 3mm too high.

Seems that KP08 is specified differently depending on which one you buy. Sometimes the distance from the bottom to the center of the hole is 15mm, sometimes it is 18mm.

I think the "problem" should be documented in the README file, and perhaps a variant of the KP08 pillow block to reflect the height (for example: KP08-15 and KP08-18).

As I don't know which of these is standard, or even if there's a standard, I didn't submit a PR yet.

Currently lead nuts are a dark grey. Shouldn't they be brass coloured?

I'm finding I have to offset my countersunk screw holes by layer_height to get the screws to lie completely flush (fortunately this is possible because the countersink cutout is reflected in the xy plane).

I think the counterbore associated with the countersink is off by one layer. This may be a rounding issue - I tend to print with a layer height of either 0.4 or 0.5. Certainly I am seeing this with a 0.4 layer height, I haven't checked for 0.5. I suspect that a calculation that is correct for a layer height of 0.25 may be out by one for a layer for a layer height of 0.4.

I hesitate to raise this as an issue, since I generally have a rule not to argue about anything that can easily changed with a script.

NopSCADlib's use of colour is inconsistent with OpenSCAD's use of color. This can grate, especially in statements like color(pp1_colour), or even color(colour). Also NopSCADlib is not itself consistent, since we have microswitch_contact_color, d_pillar_color and other _color constants.

Note also that NopSCADlib is not consistent in its use of UK English spelling: center is used instead of centre.

The scripts for generating BOMs and other documentation items are great, however they are lacking documentation. It would be good to improve the documentation for those tools, because it would make creating projects with nopscadlib a pure joy.

Some items to consider:

• bom.py, make_all.py and others don't really have a usage doc/man page
• There are some undocumented constraints (eg. for generating STLs, your files must either be under ./scad or ./scad/printed; this constraint should also be addressed at some point)
• There is no documentation on how to set up a project in a way that would make the library and tools work best
• Certain dependencies are not obvious (python dependencies not listed in scripts/readme.md, dependency on image-magick CLI tools also not obvious)

I have problem generating DXF for routing and the "box example" doesn't have any dxf("that") to look at nor test it on my system, as I suspect that I am missing some dependency somewhere.

nuts.scad is missing an include of washers.scad