I designed a drop in crosshairs doohicky so that one could center the maslow.
Mostly worked well designing it. Haven’t had a chance to cut it in the real world yet. This design would work best with wood stock that is close to 1cm thick.
1 Would it be possible to make the black and purple information windows in the bottom half of abundance resizable by pulling on their corners? Sometimes I want to be able to read more especially when making a read me or entering variables. Variable names get cut off. Sometimes it might be good to shrink so that one could see the project. Wouldn’t add any buttons or visual clutter.
2 In the cut layout info screen we can already change the angle and position, could there be an option to change the orientation of each piece? I really need this for abundance to be a realistic cutting option. I need to be able to choose which side is up for finish surface and machining grooves.
Bug report:
1 Cut layout and gcode are appearing as mirror images? Pictures below
2 Also the gcode wants to return to the origin every time.
In a more general discussion Are the drawing tools and shapes provided a kind of turning complete set for drawing? If they are, is it easy to get to all of the possible shapes? I think one should step back at some point and think through if they are able to draw all possible things. Currently I can make a triangle happen by subtracting rectangles from each other so that is good but clunky. very difficult to define a triangle with set side lengths. Maybe good enough. I could make pyramids and three D convex polyhedrons the same way, I found it very difficult to easily define concave polyhedrons. Booleans make lots of shapes possible. Lofting can make three d curves but maybe not very good at curves with curvature in two directions? Just thinking through what is possible
Here is the cut layout on one side of the origin and the gcode on the other with the weird long paths back to the origin.
Yes, BUT it should be intelligently picking the side that has groves in it to be up. Is that not happening?
Can you explain this one more? I forked the project, but everything looks right to me.
Yeah, this one is a bug for sure, that’s getting fixed. We updated Kiri:Moto and for some reason it’s doing that now
No, I don’t think so, it’s more of a starting set. I made github molecules for a couple of different types of triangles that are easy to import. There’s also a lot of other things like rounded rectangle that are possible to make, but hard so I made one to import. Sphere is impossible I think so there is one that can be imported.
The built in tools are just meant to be a starting point. Think of it like a programing language which lays out the basics, but if you want to do something fancy you will want to import a library.
So I think they are not mirror images but are appearing on opposite sides of the origin. I guess I was expecting the gcode to overlay the cut layout. It looks like one is using the top side of the board to be cut at the origin and the other is using the bottom? Here are two screen shots without moving the viewpoint. Still usable but especially with a small cut in a big board I have been losing track and it is a bit difficult to navigate in the viewport so If I am comparing layout to gcode it requires a lengthy trek to get back and forth between them. In my oiginal post above cutting on a default 4 by 8 sheet of plywood. the cutting layout and the gcode are 8 feet apart.
In this one it picked up on the grooved sides and put them both up but in my x frame design it was not. I may go try to run that again to see if an update in the layout code makes it different. When the abundance code changes what changes happen to older models? Do they automatically update?
It will be interesting to see how abundance matures with sets of loadable tools. I do think there eventually needs to be some organization to the molecule library world for that to work.
It looks like it is drilling all of the holes and is cutting the grooves on the outside of the shapes but is not attempting to do the countersink holes at all. It did flip them so that the countersink is on top.
Yeah, I would expect that too. It used to work that way, let me look into it!
Yup, they should update. If the input changes so much that the parts aren’t in the same order then the layout will end up messed up, but it will be updated.
I’m trying to take a look at your project but because all your projects parts are separate repositories I’m having a hard time navigating through them. What is the project that has the parts which are being laid out in the wrong orientation? Also, can I ask if there’s a specific reason you’re doing it this way (each part or operation as a separate project) instead of nesting everything inside one project?
Just added a feature to expand the menu to make long variable names visible etc. You can already collapse the menus using the small arrow next to the menu title. Thanks for the suggestion.
There are two main projects in this forum thread. The thread is mainly about the small crosshairs which laid out mostly correctly but did have overlapping pieces.
Bar was asking if it was flipping pieces over to have the grooved sections on top. I went back and tried it with my other project to check and it was not flipping them.
The project that I am having trouble with is an x frame for the maslow.
So I am learning how to navigate and use abundance.
I built a central beam and then I made separate modular pieces as separate projects that I can then call and have cut their own slotting spaces in the main beam. The idea is that I could swap them out or change them individually. Four of those completed arms are then brought together to make the final project. I am only trying to cut one of the arms.
Seemed a natural way to work. I would like a way to make a folder in the abundance library to keep all of the parts in. I also work this way because It lets me organize each piece and then call different groups of them for assembling differently arranged parts. Also I can make copies of a part and then make variations of it. For example ach of the hinges is a copy of the first one with the parts rearranged.
I can’t cut the parts individually because they interact with each other for assembly.
There are 96 wooden pieces to the final project.
For the x frame I made a new project in order to do the cut layout partly because my model was complicated and full in the window allowed already and partly because I didn’t want to mess it up.
I also made a new project so that I wouldn’t mess up the manual layout that took several hours.
I was kind of wanting to cut each arm on a sheet of 4 by 8 plywood,
Most parts have grooves cut into them on one face that needs to be face up. Looking at the cut layout from top and bottom one can see the grooves on the bottoms of the pieces.
I had a thought. I work on old computers that aren’t very strong and it takes a long time to compute things like the layout. I noticed this time that it renders as it computes so that it starts with everything at the origin and then slowly moves things out. I wonder if it is running a save cycle before it has a chance to get everything shuffled around.
I made a new project for doing the layout and gcode for it this is what is not laying out correctly. It doesn’t matter if I do it here or in the original file though it is always overlapping and with pieces upside down.
This rides up and down on the tower to make the anchors the right heights. This part also has grooves that need to be flipped. They are on the bottom side in the cut layout.
This is one of 8 parts that stacks to make a hinge. There are 8 parts on each beam and then four different stacks in different orders to make the complete hinge in the final assembly. These also have grooves on one side that are on the bottom in the cut layout.
Each of these is a module that I can switch out so it has been designed separately.
The parts are brought together to cut into each other in this project to make one arm
Four slightly differently arranged arms are brought together to check the model and make the final project. I am not trying to cut the whole thing at once:
Just pushed some changes to the gcode generation that should fix your countersink issue. Could you confirm if it looks like it’s generating correctly ?
Super! It looks like it fixed the issue I was having with it not drilling holes in the x frame layout too. Very cool. Thank you. My only suggestion is that the yellow trace lines are really hard to see.
I think there’s quite a few things wrong with the layout right now so i wouldn’t sweat it regarding computer power. I had a chance to test some smaller layouts and the bug where the pieces are being laid out on the wrong face seems to happen even in small or even one piece layouts.
I hear that. I’m not sure that we have plans to change the main screen organization since each project is already a folder for molecules and I think we are generally trying to get to a place where Abundance works well enough that you only need one repository per project. This would allow others to navigate your project easily if they were to fork it but i understand why you are working this way and the desire to reutilize parts in different arrangements. And maybe seem like would be helpful in the future would be a feature for working with branches, that way you could work on multiple versions of the same project without having multiple repositories, which is something we have talked about possibly implementing.
I guess I am confused. If you are working towards having everything for a project in one repository that makes a lot of sense to me but functionally what I am doing is what abundance was made to do, reuse and adapt parts of projects in other projects. Whether I make the parts and then combine them or if I am using someone else’s parts and then combining them the result is still a project that is built over multiple repositories.
I guess to make it all in one repository there would need to be some sort of organization and copying of referenced pieces into the project. I think this is a good idea
The limitation of viewport and programming space in abundance also limits how I can work. I think the project organization might need to take place one level higher than the programming window.
For me a repository folder on the file end would let me collect, manage and make my own stable copies of assets so that my project wouldn’t change automatically when the source asset changed. The node based programming window is good enough for making things but not good for understanding the hierarchy of referenced molecules.
The confusion you have understanding my project is exactly what a structured file system would address. Especially as people start making projects using projects built out of other projects other projects. We need a way to view, edit and archive the system of information that an abundance project is built with.
Thanks for the suggestion.
