QTPYVCP+VISMACH+LINUXCNC ROLLED INTO ONE?

Lcvette wrote:

this has already been implemented in qtpyvcp and does not require vismach. the model can be setup to be shown and run in main vtk ui backplotter natively and respond to gcode and subroutines etc. and is quite easy to setup.

 

 

if i would have know this last week when i was about ready to smash the pc because it fought me so much i would have been all over this in a heart beat i probably should have posted something before i started this to see what other have done  

to build what you see above once you have the machine files would take under an hour to be up an running natively. my suggestion would be to give it a try. it can be configured pretty flexibly for any functionality you might want to add. and instead of using hal you could simply trigger things like toolchange or part passing etc directly from the gcode with some simple commands. configuring vismach and hal for something like this while powerful, seems cumbersome and unnecessary in my opinion (that said, i'm not the hugest fan of working in hal, so im very biased on that front..lol). I would be trying to make this as gcode dependent as possible if your intentions are to use as a simulator for proving out programs.

if you are trying to make a configuration tester that would run off core signals and hal, that would be a different story. even so this could definitely be configured for that.

alternatively, for machines such as your talking about, if this is meant to be program proving sim and if you are programming with any decent commercial cam system they typically have excellent simulation built in with many more sanity checks that what you would likely have patience to build yourself in a stand alone sim. not trying to discourage you, its fun to have projects, just wanted to make sure you were aware of other existing options.

i have options for sim at work with different cam packages but one of the things i noticed right out of the gate once i started looking at the lathe controllers is lack of memory on the controllers since these lathes are maybe 15 years old with the exception one he new one that was just bought. the problem with cam if your trying to do something with live tooling without the Y axis the program size just gets way to big pretty fast. so macro programs seem like a good solution to keep the program sizes in check. Gibs cam might have something for macro's but i don't use it very much. i'm mostly interested in something to test lean programs with and maybe add some quick code for small run jobs for protype work we seem to get a good bit of that with the production work.

ok, s im not certain what your implying regarding memory? are you wanting to retrofit the machines?

no retro fits on these i was just saying the memory for program storage is what ever the base model came with at the time. sadly the people i work for don't spend the extra money to upgrade that part of the machine when they buy them.

they guys were old school who have retired or moved on and they hand coded everything in the past so bloated cam programs were never an issue before because of this. the one mori is nothing fancy at all but when i first came out of trade school back in 1991 they had that machine at it's still there so it's 35 years old plus

 

i'm not even close to being done but got the viewer hooked into a custom .ui file. i think i am on the downhill side of things now but this seems to be the hard way to do it but since i have so much time in teaching myself this i will finish what i started. but basically, it's done in OpenGL.