some cutsim progress

[andyw]

Hi all,
I've posted a picture and some text on my blog:
http://www.anderswallin.net/2011/10/cutsim-driven-by-g-code/

The rs274 binary from an emc2-build is required. A non-realtime "simulator" build is OK, and a real-time kernel is not required. That build is described here:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2

This is very very experimental, but for those of you who are brave (this isn't exactly an easy install..):
clone cutsim: https://github.com/aewallin/cutsim

go into the src-directory, build and install:
cd src
mkdir bld
cd bld
cmake ..
make
sudo make install

then we need g2m. build and install.
cd src/g2m
mkdir bld
cd bld
cmake ..
make
sudo make install

then the prototype app is cutsim5. cutsim_window.hpp has hard-coded paths to the rs274-binary and the tooltable. These are lines 96-97 of cutsim_window.hpp which will require changes.
cd examples/cutsim5
mkdir bld
cmake ..
make
DONE!
now we can run ./cutsim5
my screenshot is the result of opening ngc/simple_sphere.ngc and pressing "play"

I'll be really surprised if someone else gets this to build and work and posts a screenshot! :)

Anders

[mark]

here ya go :)

https://github.com/aewallin/cutsim/pull/1

[mark]

That sounded waaaay too much like a challenge, so I had to do something about it! http://imagebin.org/177041

For anyone on ubuntu who doesn't have emc2, there are simulator .deb packages at http://wiki.linuxcnc.org/emcinfo.pl?EMC2_Pure_Simulator

[Anders Wallin]

Great! I've merged your pull-request which mostly re-organizes things,
and makes the build easier.
There is now a short README.txt with the build "instructions"

I think the next step is to put the cutting-simulation, and (parts
of?) the OpenGL-window in a separate thread, so that the UI stays
responsive during play() and we actually see the cutting in progress.
Also I think the OpenGL-code is somehow not right, since it sometimes
takes 0.05s to run updateGL(), but sometimes up to 0.35s. I think we
want something where the cutting-simulation updates the stock-model in
one thread, and the openGL graphics sits in another thread which runs
often enough to keep the openGL view updated and "smooth".
Suggestions/examples/patterns are welcome!

Anders

[andyw]

I think the next step is to put the cutting-simulation, and (parts
of?) the OpenGL-window in a separate thread, so that the UI stays
responsive during play() and we actually see the cutting in progress.

I have experimented with a worker-thread that updates vertex and index-data drawn by OpenGL. See this blog post:
http://www.anderswallin.net/2011/10/threading-and-opengl-test-2/

Does anyone have ideas/patterns/examples for a double-buffered approach where the Viewer draws based on existing valid data, the worker thread modifies a copy of the data, and we only have to lock the mutex for a short time while swapping buffers?
Any ideas on how the buffer-swap/sync should be done? is the assignment operator for std::vector good, i.e.  just array1 = array2 ? Or is a C-style memcpy() call faster?

Anders
 

[Mark]

If the data is in a std::vector<>, this would probably be most efficient: http://www.cplusplus.com/reference/stl/vector/swap/

Anders
 

Regards,

Mark