Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Information for shelf types in tray_6in.py needs to be available to other functions #68

Open
julianstirling opened this issue May 21, 2024 · 2 comments

Comments

@julianstirling
Copy link
Collaborator

Currently the information for how each individual shelf is built is held ad-hoc in a set of functions in tray_6in.py. Some of this information is needed for other parts of the orchestration.

For example if the shelves are broad they need to be a added into the rack before the top is put on. Therefore the instructions need to be different.

We will need some way of holding the information for the shelves in a way that it can be polled without having to run the script the builds the shelf.

@drayde
Copy link
Contributor

drayde commented May 21, 2024

Is there more than the broad type information that would need to be available?
One way to tackle this would be to structure the assembly instructions so that all types are assembled the same way (start at the bottom, work up to the top most shelf, than add the top.

If we really need that info outside of the build functions, I would like to do the code refactoring

@julianstirling
Copy link
Collaborator Author

Is there more than the broad type information that would need to be available? One way to tackle this would be to structure the assembly instructions so that all types are assembled the same way (start at the bottom, work up to the top most shelf, than add the top.

If we really need that info outside of the build functions, I would like to do the code refactoring

Either way we will need the information available because they will slide over the legs rather than slide into the front. We need this sort of information so we can do exploded renders and renders of each assembly step happening.

The code must be written from the perspective that the final goal is to have step by step rendered instructions
image
This is simply not possible if parameters are hard coded into the the functions that CadQuery process.

We have done significant refactoring already to try to centralise parameters and there is still a huge amount to be done before we can get the CAD side of this project back on track. Any refactoring must be done with a proper understanding of what information is needed where, and probably won't happen until I have done a significant amount more parameter centralising.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants