On Thursday, February 16, 2012 11:53:23 AM Sebastian Kuzminsky did opine: > I have only a little experience as a user of cut simulation, but the > times I've used it, it's been integrated with the CAM rather than with > the machine control. It's when you're designing the cuts that cutsim > is most useful, IMO. I wonder if Dan Falck's FreeCAD+OpenCamLib work > would be a useful place to add it? > While I would have no objections to that, it would only become 'useful' for me if freecad could import the gcode that already exists, in a LinuxCNC compatible format. I'm on the buildbot ppa, so freecad gets updated quite frequently, but it had not grown that ability when I last ran it yesterday.
Because LinuxCNC is the 'consumer' of gcode, often just the output of someones editor of choice, it makes more common sense to me to have either a standalone viewer, such as openscam, or a linked in ability that might even use the axis backplot display window if it was enabled. That isn't an important function though, just the ability to get at least a 2D preview that would give us a preview. openscam, as of the build I did yesterday, is not working, no clue why other than the messages I posted from the cli yesterday. I suspect it needs a tool table file, which of course isn't going to be available when it is "run in place", the build having zero docs, and zero installation in its Makefile. In this openscam, I see , in the .cpp file, a copyright joseph AT cauldrondevelopment DOT com, whom I have not emailed but will next as it looks as if the propaganda I can google says it should do what is needed. That name does not ring any bells for me, but perhaps if he knows there is some interest, he might join in the discussion here. > On Feb 16, 2012, at 08:27 , Anders Wallin wrote: > >> I don't think that belongs in linuxcnc. It sounds like you would > >> like the "cut simulation" work that Anders Wallin et al are working > >> on. Check this out: > >> http://www.anderswallin.net/2010/08/octree-animation/ > >> > >> It'd be cool to have a tool like that in another Axis tab... > > > > Last time I tried to work on cutting-simulation I tried to do it all > > in one: OpenGL, threading, double-buffering, QT-gui, rs274-interface > > etc. > > > > Maybe the way forward is to start minimal instead. I trimmed down > > libcutsim to a bare minimum over here: > > https://github.com/aewallin/libcutsim > > > > This should be mostly standard c++ and only require cmake + > > boost-libraries to compile. > > > > I'd be very interested in working with someone who knows enough about > > AXIS to get this started. What I think we need: > > - A tool definition (this can be hard-coded for now, but set by g-code > > comments eventually) > > - A stock definition (hard-coded for now, set by g-code comment > > eventually) - For each line of g-code (or canon-move) a call into > > cutsim asking to execute that move. This is userspace stuff so no > > real-time demands please. The trivial approach to subtracting a move > > from the stock is: (a) subtract a stationary cutter at (x,y,z,a,b,c) > > from the stock. (b) move cutter along programmed move by a small > > amount (dx,dy,dz,da,db,dc) (c) while move not done go to (a) > > - we can do one or many iterations of this loop between OpenGL > > updates. Or we can do one or many canon-lines between OpenGL updates. > > - When we call Cutsim::updateGL() it will respond by updating two > > arrays: a vertexArray and an indexArray. The vertex array holds > > vertices which are essentially 6-tuples of coordinate and color > > (x,y,z,r,g,b). The indexArray holds indexes into the vertexArray. > > Depending on the algorithm these are interpreted as lines, triangles > > or quads for drawing. For example the first triangle would have > > vertices: > > vertexArray[ indexArray[0] ], vertexArray[ indexArray[1] ], > > vertexArray[ indexArray[2] ] > > and so on. > > I got quite lost with immediate-mode, vertex-array, > > vertex-buffer-object, etc. drawing last time I tried, so it would be > > much better if someone who has experience with OpenGL would do the > > rendering part. The vertexArray/indexArray can be accessed from C++ or > > python. At first I don't care if the view "freezes" while we run the > > program, but in the future it would be great to allow rotate/pan/zoom > > while running (I am not sure what combination of drawing-mode, > > threading, or double-buffering is needed for this). > > > > I'd really like to see this happen, and I know there's a much greater > > chance of success if we work together and this becomes a permanent > > part of LinuxCNC - rather than I or someone else going at it alone. > > Please respond with ideas/comments/patches! > > > > Anders I am personally in favor of it Anders, but the best claim I can make about C is that I knew, 20 years ago (and have forgotten much of it) just enough C to be dangerous. And absolutely zip about C++ :( Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> Friction is a drag. ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
