BoardCAD 2.x and 3.0 roadmap

Welcome to BoardCAD forums Software BoardCAD developers BoardCAD 2.x and 3.0 roadmap

Viewing 15 posts - 16 through 30 (of 63 total)
  • Author
    Posts
  • #4192

    surfineurope
    Participant

    @mocol wrote:

    The only thing I am thinking now is, sounds like an awful lot of work to be done…

    Actually I think the hardest part was already solved with the Bezier patches last year, and I was a bit surprised that nobody showed any real interest in them at the time.

    Even the quick implementation that I did then creates a nurbs surface that matches the Bezier curves very well, maybe even closer than the current direct approaches.

    Just like the normal nurbs surfaces, the Bezier patches can be exported as a step-file and cut with the existing machine interface.

    Use the following script to create a Bezier patch in BoardCAD v2.0.


    import boardcad.BoardCAD

    boardhandler=boardcad.BoardCAD.getInstance().getBoardHandler()
    bezierboard=boardcad.BoardCAD.getInstance().getCurrentBrd();
    boardhandler.approximate_bezier_patch(bezierboard, False)

    #switch deck normals

    board=boardhandler.getActiveBoard()
    deck=board.getDeck()
    i=0
    while (i j=0
    while (j p=deck.get_control_point(i,j)
    deck.set_control_point(i,j, boardcad.myPoint(p.x,p.y,-p.z))
    j=j+1
    i=i+1

    deck.evaluate_surface()

    Here is an example of a board approximated with bezier patches:

    #4193

    surfineurope
    Participant

    Note especially that the rail is identical to the Bezier cross sections…

    /Jonas

    #4194

    surfineurope
    Participant

    @mocol wrote:

    CAM:
    – Bezier cam;
    – Nurbs cam;

    Do we really need 2 CAM modules?

    No probably not. I don’t think it is a problem to have several tool path algorithms, but we should have a single machine configuration and user interface. Hopefully we can use HÃ¥vard’s gui when it is ready, but I’ll wait for him to explain how it works since I still haven’t figured it out and I don’t have time to look at the code right now…

    @mocol wrote:

    Haavard where are you!! Hope you are well!

    I got a mail from him today so he is alive and well. I understood he was very busy though, but hopefully he’ll find some time to write something.

    /Jonas

    #4195

    sm02463
    Member

    As far as your design goes, I think you need a new class for CAM and I don’t mean the Machine class. There should be a class called Board, and one called Machine that know nothing about one another. A higher level class called BoardCam (or whatever) ties the Machine and Board together and does things like GCode generation, board flipping and positioning on machine supports.

    #4196

    surfineurope
    Participant

    @sm02463 wrote:

    As far as your design goes, I think you need a new class for CAM and I don’t mean the Machine class. There should be a class called Board, and one called Machine that know nothing about one another. A higher level class called BoardCam (or whatever) ties the Machine and Board together and does things like GCode generation, board flipping and positioning on machine supports.

    Yes, that seems like a good idea. I would still like the CAM module to be a bit more general than just cutting BoardCAD boards though, but I don’t think that is incompatible with what you suggest.

    Sometimes I get boards designed in other CAD-systems that people ask me to cut, and sometimes even completely different things that they want cut. The models are typically step or stl-files. I don’t mean that we should have a single generic tool-path algorithm that works for everything, but in future versions of BoardCAD I would like to be able to import and cut step or at least stl-models…

    /Jonas

    #4197

    surfineurope
    Participant

    I’ve been thinking some more and it would actually be very nice to have a machine component that is separated from the gcode generation.

    The machine component could even be supplied by the machine provider and possibly be plugged in at run time. What we would need to define is a number of interfaces such as a mandatory interface that defines axis configuration, support type, tool(?), etc, an optional interface for getting a graphical model of the machine in order to simulate the cutting, maybe an interface for loading and executing the gcode in the machine, and also allow for completely custom interfaces. Of course we should supply a simple generic and configurable machine component with BoardCAD, but I would probably like to supply a more specialized component for my Shapebot machine.

    I did some experiments last year with interfacing BoardCAD and LinuxCNC and was able to load and execute the gcode from BoardCAD. It was pretty cool and something that I might choose implement in the Shapebot component…

    /Jonas

    #4198

    surfineurope
    Participant

    @surfineurope wrote:

    I did some refactoring today and removed the gcode generation from the Board class and put it in a separate BoardMachine class. I will try to do the same with the drawing methods tomorrow…

    I’ve placed the drawing methods in a BoardDraw class, but it was done on a computer with no internet connection, so I’ll only be able to checkin the new version in the beginning of next week…

    /Jonas

    #4199

    surfineurope
    Participant

    I’ve checked in the latest changes. Apart from cleaning up the Board class I also started to separate some of the classes into different packages in order to reorganize the architecture.

    This will be a time consuming task since there are lots of dependencies between classes that I think should be independent, so I’ll not spend more time before we are sure on how we want the new architecture…

    /Jonas

    #4200

    surfineurope
    Participant

    Here is an updated component diagram:

    #4201

    surfineurope
    Participant

    I haven’t used UML for years so I’m not sure if a deployment diagram is the most suitable for what I want to describe.

    What I mean with a component in the diagram above, is a larger piece of software that provides one or more interfaces, and that can be easily reused and/or replaced.

    Previous versions of BoardCAD, at least the initial version, were more object oriented where each class represented a physical object and functionality was delegated to the individual objects. For example, in order to save a board, the board class wrote some meta data and then told each surface to write their own data. The same strategy was used for reading files and for drawing the objects. The problem with this approach was that a lot of the dependencies from the higher levels, such as graphics and file handling, was passed down to the lower levels.

    By taking a more component based approach (without getting into component based technologies such as EJB), I want to make the software units more independent.

    In some cases I would like to specifically specify the interface (didn’t components used to have interfaces in UML?). As stated before I would like to have one or more machine interfaces in order to make it easy to plugin a different machine. I would also like to specify a minimal CAM-interface that can be implemented by both the cadcore and the board instead of making the CAM-module (boardcam) directly dependent on the Board component. Also, as I stated in another thread, I would like to use interfaces for the cutters, and possibly also for the boards, instead of using abstract classes…

    /Jonas

    #4202

    surfineurope
    Participant

    @surfineurope wrote:

    In some cases I would like to specifically specify the interface (didn’t components used to have interfaces in UML?).

    I had to google it, and it seems like component diagrams with interfaces were introduced in UML 2.0 in 2005, but ArgoUML that I used for the diagram above still only supports UML 1.4. The funny thing is I used component diagrams with interfaces a lot during 2001-2003 so I thought they had been removed. Maybe I just need a different tool. Does anyone use UML and have any suggestion?

    As a side note: standards are really slow, but I guess it’s a good thing. STEP started in 1984 and is only recently taking over after IGES so I’m sure it will be along for at least another 50 years…

    /Jonas

    #4203

    sm02463
    Member

    @surfineurope wrote:

    The problem with this approach was that a lot of the dependencies from the higher levels, such as graphics and file handling, was passed down to the lower levels.

    I don’t really see the problem with being dependent on OS level (ok, java level) features.

    @surfineurope wrote:

    By taking a more component based approach (without getting into component based technologies such as EJB), I want to make the software units more independent.

    Yes, the interdependencies within the project should be minimized.

    @surfineurope wrote:

    As stated before I would like to have one or more machine interfaces in order to make it easy to plugin a different machine.

    More interfaces require more complexity and essentially more code. I would try to target a single common interface for each component.

    @surfineurope wrote:

    I would also like to specify a minimal CAM-interface that can be implemented by both the cadcore and the board instead of making the CAM-module (boardcam) directly dependent on the Board component.

    This is the most important decision on this page so it’s important to think this one through. Can you please elaborate a little more on how the CAM-interface will be implemented by both the cadcore and the board.

    @surfineurope wrote:

    Also, as I stated in another thread, I would like to use interfaces for the cutters, and possibly also for the boards, instead of using abstract classes…

    Using interfaces is probably a better idea, however an interface is just an abstract class with no members. My point is they are very similar are aren’t even worth differentiating between for this discussion.

    steve

    #4204

    surfineurope
    Participant

    For the CAM-interface I see two alternatives that can both be implemented.

    A parameterized approach where the board is parameterized using s,t and we leave it to the board model to decide what those parameters should mean. It could be the parameters of the nurbs surface, or the respective parameters of the outline and a cross section bezier curves, or s could simply be a normalized length measure and t the normalized width at the actual position. For this the board would need to implement the following methods already present in the Surface class:

    getMaxS()
    getMaxT()
    getMinS()
    getMinT()
    getPoint(double t, double s)
    getNormal(double t, double s)

    The second alternative would be a metric approach, similar to what is currently present in the Abstract board:

    getTopAt(double x, double z)
    getTopNormalAt(double x, double z)
    getBottomAt(double x, double z)
    getBottomNormalAt(double x, double z)
    getLength()
    getWidthAt(double x)

    /Jonas

    #4205

    sm02463
    Member

    I’m not as much concerned with the interface but making sure it is used properly.

    I think what you are saying is you define:

    interface CAMInterface
    {
    getMaxS()
    getMaxT()
    getMinS()
    getMinT()
    getPoint(double t, double s)
    getNormal(double t, double s)
    }

    Then

    class Surface implements CAMInterface { … }
    and
    class Board implements CAMInterface { … }

    The BoardCAM class would then be dependent on CAMInterface and GCode functions would use a CAMInterface and not knows any specifics about Board or Surface.

    Does this sound correct?

    By the way, in the s,t version, how do you get information for the top vs the bottom?

    Steve

    #4206

    surfineurope
    Participant

    @sm02463 wrote:

    The BoardCAM class would then be dependent on CAMInterface and GCode functions would use a CAMInterface and not knows any specifics about Board or Surface.

    Does this sound correct?

    Yes, I think so. The GCode functions could of course know a lot about boards and surfaces, but I don’t think they need more information from the Board or CADcore components than what is provided through the CAMinterface…

    @sm02463 wrote:

    By the way, in the s,t version, how do you get information for the top vs the bottom?

    I’m not sure. Maybe the board would need to implement separate CAMinterfaces for the top and bottom.

    However, I would like to add that I still prefer not to implement the CAMinterface at all in the board component. I just consider it less bad than to create a direct dependency between BoardCAM and the board component.

    The complete geometric model should already be available in the cadcore so I don’t see what we would actually gain by implementing the CAMinterface in the board.

    Knowledge such as added outline and stringer cuts can be provided directly in the Gcode functions that generate the cutting paths.

    /Jonas

Viewing 15 posts - 16 through 30 (of 63 total)
  • You must be logged in to reply to this topic.