Yeah, man. You have any direction here? I don't want to waste my time on dead branches. Would algorithms that enable a kind of "place and cut" for circles and rectangles as discussed in the video be useful to you?
I think it might be good in terms of development portability to use standard G-code as toolpath instructions. Therefore we could divise the control in two main part; a G-code interpreter (where G instructions get translated into x-y coordinates over time), and a machine control (Where the x-y coordinates would translated to actual physical axis movement). Then a front end visual software could effectively be developped to help with the g-code generation. What do you think?
I think at this stage it's somewhat of a needless layer of abstraction. If the intent is to be able to "place and play" g-code control doesn't really buy you anything because there's no human to generate g-code! If the software computes the path and then translates to g-code and then executes g-code, why did you even bother with the g-code when you could have just been directing steppers? Future application by more specialized people would definitely call for it, but from my understanding of "commanders intent" right now, I'd just drive towards simple stepper control at the moment. Also this is just to mock out behavior of a single device, not really intended to actually control the thing.
![Open Source Laser Interferometer - Part 1 [4K]](http://i.ytimg.com/vi/v8gaEqHa1r0/mqdefault.jpg)
![“อ.เบียร์ คนตื่นธรรม” มาตามคำเรียกร้อง แหกศาสตร์ฮวงจุ้ย เตือนสติอย่างมงาย | แฉ 7 พ.ย. 67 [1/3]](http://i.ytimg.com/vi/5fc4S3xBNfc/mqdefault.jpg)
Python 3.4.4 is required, not Python 3.4.0. My bad!
Nice! I was about to try the same thing when I saw you already went and did it
Cool man.
Thank you!
Yeah, man. You have any direction here? I don't want to waste my time on dead branches. Would algorithms that enable a kind of "place and cut" for circles and rectangles as discussed in the video be useful to you?
I'm not sure yet.
Roger, well I'll probably goof around with those next week some time just to amuse myself. If you come up with a direction, lemme know.
I think it might be good in terms of development portability to use standard G-code as toolpath instructions. Therefore we could divise the control in two main part; a G-code interpreter (where G instructions get translated into x-y coordinates over time), and a machine control (Where the x-y coordinates would translated to actual physical axis movement). Then a front end visual software could effectively be developped to help with the g-code generation. What do you think?
I think at this stage it's somewhat of a needless layer of abstraction. If the intent is to be able to "place and play" g-code control doesn't really buy you anything because there's no human to generate g-code! If the software computes the path and then translates to g-code and then executes g-code, why did you even bother with the g-code when you could have just been directing steppers?
Future application by more specialized people would definitely call for it, but from my understanding of "commanders intent" right now, I'd just drive towards simple stepper control at the moment.
Also this is just to mock out behavior of a single device, not really intended to actually control the thing.
I see your point. Notheless I'm sure there is a shitload of open source code for toolpath generation and interpretation.