Messages

741

LazyTurn / Re: LazyTurn

« on: February 08, 2010, 11:36:00 AM »

Hi Guys:

  This version fixes some roughing issues, and displays the fine path not as a red line, but as a red/blck checkered line. The checkers show the actual line divisions, the red line I used to show you
was made up of thousands of small lines, ( tolerance in length), this version is now culling that line to create straight line segments in preperation for moving the path outwards by ( PerPass) amount to create the actual toolpath from that original multi point red line.

   Im working on the next steps. They include making an offset contour of the checkered line by the perpass distance, checking to see if that lien cuts any material, and repeating if it does. The path will stop contouring outwards when it senses no cut woudl occur, then the entire sequence of lines will be reversed in order and compromise a finihs toolpath. At that piont Ill post it out. I may give you the
option of just posting the checkered profile shortly as a first step in the development sequence.


Just to keep you filled in.
Art

742

LazyTurn / Re: LazyTurn

« on: February 08, 2010, 09:38:41 AM »

Hi Guys:


   Sorry, but I was waylaid for a couple weeks on important engine code experiments. Sadly, they failed in most part, but did end in some tighter
control in the driver. Anyway, back to LTurn. I did find a couepl of roughing errors this week and fixed them, and now Im back on the finish pass.

  The finish security profile, ( the red line) does appear to work well except in the case of undercuts wich cause a cutthrough. But since this may take
awhile to figure out as an algorithmic solution, I will now begin to finalize the way the fiinish pass will be output. This means not just a red line, but
actually several of them working outword until no more materuial is cut. This is to make sure the tool is not stressed beyond the PerPass specification ( unused at present ).

  Ill release when I have a test version, though it probably still wont post until Im satisfied the final passes look good and woudl make sense in a cutting context.

At that point Ill release a version that posts the finish pass code, shouldnt be too long after the consolidation, which may happen this week.
As to undercuts, we'll head bang together after that to solve the last thing needing solving before we can possibly call this a released program.


Just so you know..

Art

743

Tempest Trajectory Planner / Re: Tempest Planning - Preliminary information and testing

« on: February 06, 2010, 08:21:22 AM »

piv:

   Theres a few docs around on plugins.. check the plugins download sdk for the example, but you migth ask rufi if he'd give you a copy of
his current one..

Art

744

Tempest Trajectory Planner / Re: Tempest Planning - Preliminary information and testing

« on: February 05, 2010, 08:05:11 PM »

>>There'd be no need to, the plugin author coudl just a load a file of points..

Art

745

Tempest Trajectory Planner / Re: Tempest Planning - Preliminary information and testing

« on: February 05, 2010, 01:19:42 PM »

Hi:

  Yes,planners can be facinating to work on, but incredibly complex when you take everything into account. The truth I suspect is there is no perfect planner for every situation. You need multiple ways of planning. By the way, Tempest sets an allowable devation, and as well allows the user to set Jerk, this matches it to any machine. The problem comes in with small block segmentation, just like in EMC and MAch3. Tempests trouble is math, its incredibly complex to use S-Curves in a planner, so its limited by how much it can compute on the fly as segments are added. Tempest is just a first test though.. to teach myslef the weaknesses of the process. That having been said it DOES cut very well in standard type code so Im heartened that a general solution exists. I keep it on a warm burner so I can play in that area as I get time.
   I just today got a Windows timing subsystem working so I can actually run C++ routines in User mode at up to kernal speed. In theory this means I can now have a Real-Time version of Windows just like EMC runs real-time in Linux. Im considering rewriting the printer port driver as a normal mode C++ program routine. That means I could finally use floating point in the driver if time allows for it, which woudl mean greatly ehanced capability.   Its taken a long time to figure out just hopw to do that without Windows complaining. But today I had a C++ routine being called in Mach3 every 20us reliably and very stable. The possabilities are huge for what "could " be done now. I dont know of any inexpensive realtime extender for Windows that could be used similarly. Im psyched as this also means I could easily breakpoint into the actual workign section of the code which puts out steps and such.. It doesnt get better than that. (if it all works as I go.. :-)

Art

746

Tempest Trajectory Planner / Re: Tempest Planning - Preliminary information and testing

« on: February 05, 2010, 09:18:14 AM »

piv:

>>CV ditches the idea of the path going through G code points anyway.

   Not really. The idea isnt that the planner has to touch waypoints, it has to touch a either the point or a spot between them. Thats usually the rule, it was reported
to me recently that thats the view of the EMC planner as well. Mach3 doesnt realy have that rule, it can skip over blocks to some extent but the effect is almost the same.

 Ive actually tried a planner once as you suggest. Its effect is not what youd expect. Your right that it smooths.. way too much in fact. Consider a square 3" on a side.
Fairly common operation.. If I specify 1ms waypoints that dont have to "much touch line " rule,
what happens is that at low feedrate you get what looks like a square. The corners do tend to be rounded..as you increase the feerate, the square begins to look
like a circle, surprisingly it doesnt take much speed to get there. From the circle, it degenerates to a squiggly line that goes forward and then back..

   Its argueable then ,that one could just set a feedrate and the feedrate itself would then determine accuracy. But accuracy would come at the expense of running
slower. Entirely true. What you find though when you try it is that the feedrate must be constrained pretty much to the point Mach3 contrains it in its current
planning methodology before signifigant detail is lost.

   Yes, in some situations, like a flowing curve, it works out OK as the data is compliant with the way a servo corrects position anyway, and the output is fine, but in CNC thats a rare situation.I once made MAch3 run the Roadrunner example in such a way for example, normally it runs at something like 500mm/sec .. and I had it so I coudl make it run any speed. At the normal speed it looked like a roadrunner, from the time I got abotu 25% faster it started to look like a rooster and running full out it looked like a triangle. ( but took only 4 seconds to run.)

  Its not easy to add such a thing as youve suggested, though it could be done.I havent the time to do it at this point, but Ill consider it in future so you can play with the numbers. Of course you could do that now. Write a program that takes a small block program and rewrites it as the distance along the path at 1ms intervals. Since each line is now longer Mach3 will run it much faster. What youll notice though
is it doesnt take much speed before the cut looks nothing like the input. If you do this, you can see the cut file immediatly upon loading it in mach3, I mean youd see exactly on the screen what such a file would cut like. It typically isnt pretty..

Art
 

747

Tempest Trajectory Planner / Re: Tempest Planning - Preliminary information and testing

« on: February 04, 2010, 10:02:47 PM »

Sorry, missed the second question..

>>If I understand the planner correctly it plans the motion based on two segments, and it buffers about 2 seconds worth of motion to the plugin as 1ms points.  How does the 20 line look ahead affect things

 No, not really . Each and every move is added to the motion queue. everythign is calcuated on a 1ms pass in time. The planner is basically asked, given Im here..wher will I be in 1ms..

Then the planner looks to motion #1, if it woudl be completed in less than 1ms, it is run to completion and the next block in run as well for a 1ms increment. If it too runs out in 1ms, the next block is processed.. ect.. up to an arbitrary number .. 50 or so.. by then we should be 1ms further ahead..

  Contraints are considered of coarse, over acceleration being the most important. Consider two motions from x = 0, g1x0.5 , g1x0 .. , this being worst case .. at speed this woudl produce acceleration that is infinite as it has to reverse. whiel g1x0.5,g1x1 woudl be fine to run simultaneously as they would add to a normal acceleration of  between the segment. But in the end, the planning is done by runnign simultaneously several blocks at once and adding them all up basically. LookAhead is just how many items are in the queue at once and so it limits the overplanning..

  I suggest you look at EMC's planner, Mach3 is based on it, though heavily modified. Tempest is totally different so has different problems that the old planner.

Art

748

Tempest Trajectory Planner / Re: Tempest Planning - Preliminary information and testing

« on: February 04, 2010, 09:54:21 PM »

No You have it right. Its not the theory that wrong, its the practice. Hard to make an algorithm to do as I think you want.. you still need to
use every line.. so your problem comes in when current acceleration and velocity over the next 1ms takes you 10 lines ahead.. question is..what do you do with those
10 lines..ignore them? :-) , some do.. I take the position that no matter what, 1 waypoint must fall on every block.. that maintains as much accuracy as you can ask for,
but if you violate that rule, you can go very fast.. just not very accurately..

Art

749

Tempest Trajectory Planner / Re: Tempest Planning - Preliminary information and testing

« on: February 04, 2010, 09:22:33 PM »

>>When I say 1ms points I mean points on the motion path, spaced 1ms apart, with the path acceleration (vector acceleration, sum of tangent and normal accel) limited to the motor tuning value (in my case 1g, 10 000mm/s/s) (or a programmed value).

  Hmm, but thats exactly what MAch3 does now.. gives 1ms waypoints limited ot the motor tuning acceleration.. Thats the Mach3 planner in a nutshell really.
I think Im not grasping something maybe.. But that describes exactly what Mach3 puts out.. possible shortcoming that each segment is limited by mototr tuning to its max speed, but that cant be changed without simply using a different planning theory algorithm altogether..

Art

750

Tempest Trajectory Planner / Re: Tempest Planning - Preliminary information and testing

« on: February 04, 2010, 08:15:24 PM »

piv:

>>Im just putting in my $2 worth (bit more than 2c now), and offering to help

  No problem there, I never take offense and it allows me to rethink many things when I have these discussions,
its sometimes a long time betwen code sessions so even I forget how things work.

   When you say 1ms points..using what acceleration? 1ms presupposses that there is an acceleration as well
as a feedrate. If you mean can it send you points not separated by such things as slowdowns for junctions and such..not easily.
Its basically trying to defeat the way it works. It wasnt designed to look ahead that way. Closest you could get woudl be to have
as close as infinte acceleration as possibel and accelerate the data yourself.

   Im heavily bogged in code at th moment, so its not a project I could take on, but perhaps in the near future I coudl allow such high accels
in a test version.

 Your rigth about tempest. Its drawback is that it cannot add one line to another, its designed to always put an arc to join lines, that arc stop sacceleration
during its run and its 20% of the line length, so the accel is jerkier to apply so the speed is kept down. Tempest is far from finihsed though, its just sleepinmg till
summer sometime..

Art