BoardCAD 2.x and 3.0 roadmap

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

Viewing 15 posts - 31 through 45 (of 63 total)
  • Author
    Posts
  • #4207

    sm02463
    Member

    Maybe it’s best to skip the CAM interface for now since you’re for it and against it at the same time.

    I do like the idea of having a cutter interface and using it generically at the BoardCAM level. Maybe that’s a good place to start if you’re planning on keeping multiple cutter classes.

    #4208

    sm02463
    Member

    I just noticed the AbstractToolpathGenerator class tree with WidthSplitsToolpathGenerator, HotwireToolpathGenerator (and Hotwire2ToolpathGenerator) and SurfaceSplitsToolpathGenerator.

    Are these actively used and did these classes work well? They seem simliar to what a cam interface my be so it’d be nice to come up with something that ties them all together nicely.

    #4209

    Anonymous

    hi,
    those are all Haavards codes, all due respect to beziers only… (correct me if i’m wrong Jonas)

    They do work, and pretty well. Bun not quite well debugged as yet. Toolpaths come out beautiful.

    Haavard, we need you to explain these things here!!
    😆
    m.

    #4210

    Anonymous

    @sm02463 wrote:

    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 { … }
    Steve

    I don’t think this design is correct. Is a board or a surface a CAM interface? (What is a CAM interface anyway? To me it looks like all the functions
    are part of a surface model. If it’s a surface model, call it a surface model…)

    I think it’s ok to be able to getDeckAt(x,y) and hide the surface model with an implementation like this:
    int getDeckAt(x,y)
    {
    return getCamInterface().getPointAt(q,w);
    }

    On the other hand, the ideal would be to do this:
    CamInterface *interface = new BezierCamInterface(bezierBoard);
    or better
    CamInterface *interface = CamInterfaceFactory.getCamInterface(bezierOrNurbsBoard);

    I think the later would be a much better approach for our drawing functions as well, ie.
    DrawingInterface interface = DrawingInterfaceFactory.getDrawingInterface(bezierOrNurbsBoard);
    interface.drawOutline();

    Of course this is overly simplified, but you get the idea.

    #4211

    surfineurope
    Participant

    @soulvoid wrote:

    I don’t think this design is correct. Is a board or a surface a CAM interface? (What is a CAM interface anyway? To me it looks like all the functions
    are part of a surface model. If it’s a surface model, call it a surface model…)

    The CAM interface is a number of methods required by BoardCAM in order to cut an object. By implementing the CAM interface, a component tells that it provides those methods. It doesn’t mean that the component itself is a CAM interface (it is not an inheritance).

    The main question at this point is whether any board specific methods are needed by the BoardCAM component, or if we can avoid the dependency between BoardCAM and the board component and only depend on the geometry model (which would make me happy)…

    /Jonas

    #4212

    Anonymous

    @surfineurope wrote:

    The CAM interface is a number of methods required by BoardCAM in order to cut an object. By implementing the CAM interface, a component tells that it provides those methods. It doesn’t mean that the component itself is a CAM interface (it is not an inheritance).
    /Jonas

    Ok, so by interpolating s and t you get the whole surface? I’m a bit uncertain how this would cover a few cases such as cutting of the nose and tail (which should be done when cutting the stringer), if you want cuts parallel to the stringer at 2mm intervals, spiraling cuts at n mm intervals on each side of the stringer, or my use case where we want n cuts at equal distance apart up to a point defined by an angle on the cross section. As far as I can see you would have to re-implement the CAMInterface in these cases? So what’s the difference between the CAMInterface and the toolpath generator?

    I also have a problem with AbstractBoard implements CAMInterface.
    If the CAMInterface is in BoardCAM package, doesn’t that make the board package depend on BoardCAM?

    I’m sorry to come across as such a naysayer/party pooper, but as this is a project we do on our free time I feel we need to be very pragmatic with the design. It needs to be minimal and to the point for what we are trying to achieve. Abstractions have a tendency to add complexity, which takes time…

    #4213

    Anonymous

    Two quick questions:
    Wouldn’t it be better to have boardcad as the top package name and then put core, cam, etc. under the boardcad package? Maybe even add org so we get org.boardcad.core, org.boardcad.cam, org.boardcad.etc. which is sort of the ‘standard’ naming convention http://www.oracle.com/technetwork/java/codeconventions-135099.html

    Secondly, did you use svn move or copy when making the new packages? It seems like the revision history is lost on each file, I thought move or copy would preserve that? I might be wrong though.

    Oh man, I’m so in trouble the next time I’m going to check in code…

    #4214

    surfineurope
    Participant

    The idea with the CAMinterface was just to specify the methods we need from the board and/or cadcore in order to generate g-code. I regret I called it an interface since it put focus on how to implement this instead on what information we need from the board/cadcore. We can instead call it a-list-of-methods-we-need-to-generate-g-code.

    The methods I thought could be useful where the following:

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

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

    Please add any methods that you feel may be missing to the list…

    /Jonas

    #4215

    surfineurope
    Participant

    @soulvoid wrote:

    I’m a bit uncertain how this would cover a few cases such as cutting of the nose and tail (which should be done when cutting the stringer), if you want cuts parallel to the stringer at 2mm intervals, spiraling cuts at n mm intervals on each side of the stringer, or my use case where we want n cuts at equal distance apart up to a point defined by an angle on the cross section. As far as I can see you would have to re-implement the CAMInterface in these cases?

    Here is how I find the s values for generate cutting paths at equal distances up to a point, using the methods above:


    #Find uniform distances for s and their angles

    wval=[]
    sval=[]
    aval=[]

    s=s_rail
    n=deck.getNormal((deck.getMaxT()-deck.getMinT())/2, s)
    p=cutter.calcOffset(p,n)
    max_width = math.fabs(p.z)+.1
    i=p.z
    step=p.z/deck_cuts

    while i>0.001:
    wval.append(p.z-i)
    i=i-step

    print wval
    print 'nmax width = %0.3fn' % max_width

    for w in wval:
    while (max_width - math.fabs(p.z) < = math.fabs(w)):
    s=s+0.01
    p=deck.getPoint((deck.getMaxT()-deck.getMinT())/2, s)
    n=deck.getNormal((deck.getMaxT()-deck.getMinT())/2, s)
    angle=math.fabs(180.0/math.pi*math.atan2(n.z, n.y))
    aval.append(angle)
    sval.append(s)

    print sval, aval
    #4216

    surfineurope
    Participant

    @soulvoid wrote:

    Two quick questions:
    Wouldn’t it be better to have boardcad as the top package name and then put core, cam, etc. under the boardcad package? Maybe even add org so we get org.boardcad.core, org.boardcad.cam, org.boardcad.etc. which is sort of the ‘standard’ naming convention http://www.oracle.com/technetwork/java/codeconventions-135099.html

    Secondly, did you use svn move or copy when making the new packages? It seems like the revision history is lost on each file, I thought move or copy would preserve that? I might be wrong though.

    Oh man, I’m so in trouble the next time I’m going to check in code…

    1. I think that the cadcore and possibly the cam package can be useful also outside boardcad so that’s why I didn’t define them as subpackages…

    2. I thought I did, but I may have messed up. I simply copied the files in the windows explorer and thought it automatically did an svn copy since I have TortoiseSVN. It shouldn’t be too hard to get it back though by creating a local copy of the latest version, revert to the old version, make an svn copy, and substitute the file with the local copy…

    Actually I haven’t changed any functionality in your code (I only had to make some private or protected methods and variables public in order to access them from another package) so you may revert to the old version, check-in your changes, and then put the code in whatever package you find most suitable…

    /Jonas

    #4217

    Anonymous

    I think it should still be org.boardcad.xxx, it’s like the inverse the web address where boardcad is the organization, not the product which is xxx. An example from the oracle link: com.apple.quicktime.v2

    Tell you what, I’ll shut up about the interfaces and let you guys sort it out and adapt accordingly. After I get the bezier toolpaths sorted I will focus on adapting the print code to output to dxf, g-code and pdf. There are also some editing related task that need to be done.

    #4218

    surfineurope
    Participant

    @soulvoid wrote:

    I think it should still be org.boardcad.xxx, it’s like the inverse the web address where boardcad is the organization, not the product which is xxx. An example from the oracle link: com.apple.quicktime.v2

    Ok, if that’s the standard way I agree we should organize the packages like that…

    @soulvoid wrote:

    Tell you what, I’ll shut up about the interfaces and let you guys sort it out and adapt accordingly.

    Please don’t. I would really like to have a common way to configure the machines and to generate g-code from boardcad, and without your input I’m afraid it will take a long time to get there. If you leave it to me I’ll simply skip the CAMinterface and all information needed for the g-code will have to be provided by the cadcore…

    /Jonas

    #4219

    sm02463
    Member

    These interfaces already exist but are just disguised and not used consistently throughout the code.

    AbstractBoard = BoardCamIterface (although I prefer IBoardCam)
    Provides functions to points on the deck/bottom surface. In previous discussion it has been called CAMInterface, but I’m suggesting to add ‘Board’ to the name because it is actually relates to a board.

    AbstractToolPathGenerator = CamInterface (ICam)
    Ties all the pieces of a CAM system together to generate GCode: the machine, the board, the holding system, the cutter.
    Currently this contains code so it can’t just be renamed as an interface but there’s no requirement to be strictly an interface.

    AbstractCutter = CutterInterface (ICutter)
    Provides functions get the offset based on cutter geometry.

    The current class hierachy above form an object oriented design which is very powerful, provided virtualization is utilized (calling specific derived class functions from a generic reference). I think what is lacking is conformance and enforcement of this. Basically, choose a set of interfaces and make all related classes implement them or change the interface until their needs are met. The second part of that is to not use any of those [concrete] classes directly. Always call them through the interfaces. This breaks dependencies and simplifies the overall code.

    #4220

    Anonymous

    Hi,

    Of course we could simply parameterise any surface with (s,t) and get normals, pointAt(x,y), etc. from this numerically. One risk with this is that we could end up re-implementing that code over and over again. One solution to that problem would be to write util functions like getPoint/NormalAt(x,y,CAMInterface). The problem with this approach is
    that it may not give optimal performance as there might be implementation details internally which could be used to get a quick solutions but cannot be used from an external, generic function.

    Just thinking out loud here, but how about having a common base class for the geometry models? This way we could implement the generic functions such as getNormal/PointAt(x,y) which use s,t that can be overridden where it makes sense. The functions you outlined makes sense to me and cover most of my use cases, the only thing I use besides them is a kind of normalised circumference so I can get toolpaths which are equal distance apart. Again, something could be made from s,t which would cover it, but I’d prefer to have it in the interface. I have no idea what to call such a function. There may be some similar function that may make sense f.ex. for calculating the surface area of the board.

    If we have a separate geometry model from the board (which I would prefer), how do we connect the two?

    #4221

    surfineurope
    Participant

    @sm02463 wrote:

    These interfaces already exist but are just disguised and not used consistently throughout the code.

    AbstractBoard = BoardCamIterface (although I prefer IBoardCam)
    Provides functions to points on the deck/bottom surface. In previous discussion it has been called CAMInterface, but I’m suggesting to add ‘Board’ to the name because it is actually relates to a board.

    I know. My main question is if those methods need to be implemented in the board component or if we should move them to the geometry model.

    The current versions cannot be moved directly to the cadcore since they use some custom defined surface models and the cadcore should only contain standard geometry.

    The solution would be to transform the custom surfaces to either nurbs or a mesh (preferable nurbs) and then use those for g-code generation.

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