Messages

1271

General Mach Discussion / Re: Lazy cam problems

« on: September 10, 2008, 09:37:58 PM »

Hi Kristin:

  No claws.. I promise.

 In all seriousness you have to understand quite a bit about the file formats to understand the issues in LCam.
When I say user experiences vary I really meant it. I have letters praising LCam for what it does in the Pro Features,
but its highly dependent on the DXF program used, as well as the user and his setup in Cad. For example when one says that
a profile is all spearate lines, it means the DXF lines dont connect to each other. ( I have hundreds of example file that do this..)

  Now youd think it'd be easy to fix.. youd be wrong. The math is incredibly difficult because various drawings cannot be fixed. For example,
if a user tells the program that any line thats withing .1" of the next can be connected ( Tolerance of .1) , many drawing will then have 2 lines that are within .1" of the endpoint
of the originating line.. makes it near impossibel to figure out for the user. LCAm was meant to be easy. For those that it works for it isnt far from it, but when
drawings vary in things liek connection and such, pocketing, or even offsetting can fail in many strange ways.. Almost all CAM programs suffer from this in various forms,
and the users who find another that is to their liking often find that simply because that cad program was designed around similar dxf's to the ones they use. (Or its a dedicated program that
is constantly developed to overcome such limitations. ( like sheetcam..). )

   Its why I dont think Id ever like to do CAM seriously, Im more of a chiphead into the drivers , pulsing times, and electronics. Cam is typically expensive for
a good reason. I use some very expensive programs and curse them all allot. Even the $10,000.00 programs can be cursed daily for not doing what I want,
or putting out destructive code. Ive run almost every program in existance , and if you really really hate LCam, I can tell you you can pay much more to
get pissed off. Make sure you test any program your looking at a great deal before jumping, CAM is like a religion, you wont want to switch to a different program
after you spend the time getting used to whatever you pick.

   I guess what Im saying is that your experience with LCAm was a bad one, it really menas more that its not a good match for you, but then its meant for
very simple things, and with DXF's that match its input philosophy. It could use a good manual, rather than just the videos' , but Ill leave that for the future deveopers..

  If your looking for good full featured CAD, Sheetcam is great, VCarve is the master. A bit expensive for low end users perhaps, but VCarve is the true winner in the evolution sweepstakes over the past few years, I cant recommend any product more highly that VCarvePro. Tony and the Guys are great as well and very trustworthy.

  I kinda figured Scott woudl fix you up, when I passed on MAch3 I did so only after a long releationship with Briian and Scott, and they both have my respect as honerable people.
No hard feelings over any of it, my skin is leathery like a crocodile after all this time. ( Besides.. I have no real responsibility anymore. LOL )


Small note to Rich:

   Havent forgotten you, Im still coding in LTurn as I can. I hope to get a "roughing " output soon. I discovered last month some of my assumptions were wrong, I wasnt detecting collisions
of the tool in the previous pass of the tool in the material .. I had to recode many sections, but its working better now. Im real slow on LTurn because I cant settle for anything other than a "lazy" program with few settings. Since it will be free I cant have support on it because Im donating it from my retired chair, last thing I need is support trouble.. Cant dump that on Brian either.. So true to form LTurn takes about 3 clicks to generate a roughing path. And your right, for us hobbiests, there is no real Lathe programs out there.. what there is makes LCAM look like solidworks..

  Finish pathing may takle more time after that, I have to figure out an algorithm to only remove material where its left from previosu passes. Tough slogging.

Art
 

1272

General Mach Discussion / Re: Lazy cam problems

« on: September 10, 2008, 07:08:46 PM »

Hi Guys:

  First, Im retired so none of this is official , but Im sure Scoitt and Brian will be reasonable.

OK, first of all , LazyCam was written to replace a very bad DXF importer. LazyCam as it stands is a
free program. It was added because allot of OEMs needed a "mini" cad package to inport DXF's and
manipulate them. Its been great for that. It isnt heavily supported, nor was it ever meant to be, at its price
point ( free) it is simply to help those it canhelp. ( and I have hundreds of letters showing it does..)

  Second, the "Pro" version was offered because of the many who didnt want to learn cam, but still need to pocket or offset,
and at its price of 75.00 ( almost all of whihc went to purchase the code that does the offsetting and pocketing (none of that was written by me)
it also does the job for many people. I always recommende people try it and see if it is OK for them, before licensing the pocketing
or the offsetting features. This is beacuse its real hard to refund a web license. ( believe me, if you offer a refund on a web license, people will
ask for it, then continue uising the program...) . That having been said, if its driving you nuts, just ask Scott at the license address for a resolution,
he's pretty fair and Im sure you can negotiate a deal thatll make you happy. No need to start spouting about class actiona and such, thats plain silly,
if you can find a cheaper product that can do what it does, you would've.  Your obviously used to dealing with companies that dont particularly care
what you think or if you have trouble.. thats not Brian and Scott, and it definitely wasnt me when I ran things either.

  Remember a couple things, before we created allot of downward price pressure with things ike Mach3 and LCam, you definitely would have
paid that 750.00 you talked about. LCam is kept pretty low priced because it doesnt pretend to be all things, it is a simple import facility, free in its basic version,
and it isnt well supported, but it Does do the job for a great many people, its why its there. If youve been around awhile you may remember what it
used to be like to import a DXF into a controller, its still not easy but its a far cry from what it used to be like. Mach3 is a controller, it isnt supposed to import
drawings, manipulate graphics and do text convcersions, but many people cant afford the full package of Cad/CAM as well as a controller and a machine, so LCam
has allowed allot fo people to find a way to do what they need.

  What comes out of LCam depends allot on what goes in, and DXF's are not like any other file, they differ remarkably depending on what created them..so user experiences with LCAm vary allot.

 Personally, I always recommend SheetCam over LCam when asked, Les provides excellent support as well as an excellent program, its a bit more expensive, but
its obvious why when you have to deal with any issues.

 As I said, talk to scott, tell him your feelings and see if he'll fix you up, or at least meet you halfway.. I suspect youll find he's pretty easy to deal with..I wasnt, and they arent..a faceless
corporation screwing you over..

 

Thanks
Art
 

1273

Mach SDK plugin questions and answers. / Re: Trying to get gcode movement and motor tuning in BlankMovement

« on: August 26, 2008, 09:22:12 AM »

Hi Kent:

  The g100 has proprietary code in it written by the developer of it, so I cant include a compilable plugin for the g100. The TCP
connection is their own , the ncPod plugin is compilable for usb side, but the g100 cannot be made complete to compilation stage..

Art

1274

Video P*r*o*b*i*n*g / Re: MachCloud point viewer program

« on: August 25, 2008, 10:12:37 PM »

Sorry, cant do it. Totally experimental program, there is no support for it.. its just a hobby thing I tinker with, you can eother get it to work on a
file or you cant.. Its just one of those types of programs..

Art

1275

Video P*r*o*b*i*n*g / Re: MachCloud point viewer program

« on: August 25, 2008, 03:22:12 PM »

Its the max angle a ball can fall into , stops undercleaving..

Art

1276

Video P*r*o*b*i*n*g / Re: MachCloud point viewer program

« on: August 25, 2008, 08:35:05 AM »

Hi:

 The ball algorithm is like rolling a ball over the points, when the ball rests on 3 points, a triangle is formed and
the ball is rolled over again. SO the Ball diamter shoudl be set slightly higher than the average disance betwen points.
Can be hard to figure, but using Decimate is a way to reduce the amount of poiints and make the ball rolling easier..
  Experimental program though, so its allot fo trial and error..

Art

1277

Mach SDK plugin questions and answers. / Re: Trying to get gcode movement and motor tuning in BlankMovement

« on: August 24, 2008, 06:52:26 PM »

Hi Kent:

Take note you have to set MachView->m_PrinterOn = false in the myInitControl function to indicate an external device plugin
as well as have set MainPlanner->ExternalType = EX_VMS; for variable ms timing, and set the MainPlanner->ExTime == .001 for 1ms timed waypoints..



 Then, you have to set the axis maximums , then motor tuning can work..

This woudl set the max to 75K steps/second for example.. The user can then tune the motors with the motor tuning..

for( int x = 0; x < 7; x++ )
  MainPlanner->ExternalPulseRates

• = 75000;

Now if you command a move, the positions will be in the RingBuffer at
MainPlanner->Movements[Engine->TrajIndex].sx;   sy,sz..ect..

 I believe the ncPod plugin shows incremental motion from the .ex, .ey, .ez var's, and the sx, sy, sz vars show absolute position..

Art

1278

Mach SDK plugin questions and answers. / Re: Plugin development in VS2005, VS2008

« on: August 05, 2008, 10:50:14 AM »

Status Update -

I've spent over 80 hours in the last two weeks working on the .h files that will be needed to accomplish this.

  >> Ugh, I know the trouble involved in this one..

I'm down to testing and working on a minimalist approach to a plugin. I am targeting using VS2008 C++ Express Edition with mixed mode CLR code.

I've got a plugin working in VS2008 C++ Professional. And have one ALMOST working in C++ Express. It loads, can be config'd (with managed dialogs), but blows up Mach with an infinite error message "ART9991" when I enable it.

A question for Brian/Art that would help me in finishing this:

>>Anything.


About the 4 routines concerning COM automation (DLLGetClassObject, etc) - Does Mach USE COM to talk to the plugin or was this just if the plugin needed COM to talk to other software?

>> Not used at all in the context of the plugin. Mach3 basically asks the plugin for the pointer to the functions like Update() etc.. stores them , then calls them at the appropriate time as declared function pointers.
>> No com is used. The plugin also asks Mach3 for the pointers to its main classes and uses those as the data pointers into the h files. ( thus the trouble as youve discovered ).

To me it looks like Mach does ALL simple DLL calls to the plugin. I have setup 'simple' functions like: extern "C" __declspec(dllexport) void Config()

 >> Exactly, only I used the archaic function decalration such as OneShort defined in the .h files to setup the function as opposed to the __declspec

These all appear to generate the proper DLL exports under examination with PEBrowserPRO.

>> Excellent, I hadnt played at all with iut that way, Once I discovered I could define the return type and have it work, I stopped and used that. ( hence the trouble. )

My C++ Pro code is very similar to the example plugins. My C++ Express code can not access AfxDllGetClassObject, etc. since it does not include MFC headers. I'm trying to get around it by returning S_OK. Any ideas on what I can try? Would some other return tell Mach that I don't need automation and have it skip the other calls? Ultimately, with my mixed mode I should be able to use Managed COM for people that need COM.

>> I think just returning S_OK woudl work, just a case of getting it to compile as I think the interface is totally unuded in the context of a plugin. Though to be honest you
probably know more than I as your fresh into delving into that so much lately.

Thanx,

-Ed

p.s. i will be asking for contributions to my new glasses fund after poring over 17,000 lines of assembly code to check out the structs that I replaced ALL classes with  ;^)

>> I suspect Brian will be happy to pay for the glasses en toto..

1279

Video P*r*o*b*i*n*g / Re: More hands..

« on: August 03, 2008, 12:14:48 PM »

Hi:

  The angles are the same,just more scanning distance , but my math fails in the joining as yet.. still rough and work to do..

Art

1280

Video P*r*o*b*i*n*g / Re: More hands..

« on: August 02, 2008, 11:01:23 PM »

Hi:

  No, that scan was about 30 seconds or so.. not hard to hold still that long..

Art