Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - drew

Pages: [1] 2 3 ... 11
Help and Support / Re: Oil Pump - S-series.
« on: February 21, 2024, 08:28:17 AM »
I am not sure that I bleed the oil through the lines correctly or at all.  Is there a way to check that all parts that are suppose to get oiled when pumped are getting oil?  I honestly not sure what parts the pump are oiling.  Im almost at that 1 year mark and want to make sure I am doing all the needed maintenance unless someone know if there are companies that I can just pay to come out and do scheduled maintenance (NE FL)

mine is set up to pump for 5 seconds every 650 minutes... but... that's just because that's what i set it to after researching it when i took delivery of the machine, and i've never changed it. 

truth is, it isn't needed.  the same fill i did three years ago is still in the reservoir...

after every run of HDU foam or PVC, which have dust/particulates that are notoriously grippy due to static, i'll wipe everything down with spray silicone lubricant... other than that, once a week i'll wipe the glide rails with the same silicone lubricant and then hit the helical rails with same... the little straw on the spray can makes it easy to bend and direct the spray upward toward and into the rails... then, drive the machine around the bed... wipe everything down... blow/vacuum out the control box, and you're good.

the only real bi-annual/500hour maintenance is cinching down the Y azis motors to the rail (re-seating them) and scrubbing the gunk out of the helical rails.  checking your tram and adjusting if needed (Stupid Simple Tools has a decently functional TRAM tool for a benji that's worth getting)...

pro-tip:  spray the silicone spray liberally on both glide and helical rails, make sure it's distributed by moving the axis's around, and then walk away... come back in the morning or next day and wipe it off... that silicone spray 'sets up' and leaves a dry film, and debris don't stick to dry film as easily.  White Lithium is superior to the silicone spray, but, it makes a mess and attracts debris.  the silicone spray doesn't.  use a non linting rag to gently wipe the rails, then use the same rag to wipe down the machine to keep it puuuurty. 

another pro-tip:  if you use the auto lubrication pump, you're going to want to make sure the machine is in motion when/as you pump it... otherwise, the oil pressure has the ability to push the bearings out of the glide rail slides.... you'll find tiny ball bearings here and there around your shop.  that doesn't mean the machine is down if you lose some- it just means you've introduced play by opening some tolerance between the glide and rail and that the gantry can literally rise whatever thous those missing bearing created when they vacated... it'll be apparent, sometimes, when you run a 2.5D cut on a fairly large model (that requires decent linear move of the Y axis).  when the machine is in motion and the oil distributes, it provides escape for the oil that otherwise can push the bearing off their seat.

General Discussion / Edging the spoilboard
« on: December 19, 2023, 10:43:36 PM »

Help and Support / Re: HD-100 - Random Resets and Origin Loss
« on: December 19, 2023, 06:37:31 PM »
what i'd look for is making sure the little hall effect homing sensor is good and clean... they can pick up a film of debris and wreak havoc. 

the homing works off of an interrupt- as soon as it is encountered, it stops... it should be very precise. it's the same principle as when you complete the circuit with a Z touch off- instead using the circuit completion rather than the sensor.... it's like a g104 or something like that, but, it's not g-code but instead the programming language of the machine... with DSP it 'bounces back' some distance, but that is also repeatable.  your home should be dead on... if your machine was reading funky, it literally lost it's position in space and needed to be sent all the way back to mechanical home to move accurately from there on- the same as when you powered it up...

Help and Support / Re: HD-100 - Random Resets and Origin Loss
« on: December 19, 2023, 09:20:15 AM »
How would a G offset behave any differently? Are the G offsets not relative coordinates themselves?

two seemingly conflicting statements:

so when you move your machine over to where you want the origin to be by aiming for the corner, center, ect, and assign that as 'home' (origin) the machine is absolute from that point... you actually changed your absolute base coordinate, but you placed it in a relative (arbitrary to the machine) place.  once your g-code starts being parsed, it'll 'consider' the moves absolute from that (relative) point...

the machine and the cut path being given to it via thumbdrive+gcode file aren't connected- the machine just does as it's told.. but, you can 'tell' the machine to do things PRIOR to it digesting the code- and can even do so WITH the code. 

the machine is absolute until it's told to think relative.  it's even then absolute, but from a relative position.  it just does exactly what it's told with the only concerns being "you can't go this far or that far, else crash, and i won't let you do that"....

yes, in direct response to your question, an offset is relative to something/somewhere.   you can either plop that relative (user defined) origin at a known location (to either you or the machine) or from just some place in space the machine doesn't care about with the exception of making certain it's within the work space envelope.  by leveraging one of the pre-defined offsets and having THAT ALSO as your 'user origin', you've just mapped out precisely, in code and repeatable programmatically, where that location is... so long as your workpiece is placed in precisely the same place (using registration points?) you can use that position as long as you want without changing a thing, and by either directing the machine to 'origin' OR by programmatically calling the corresponding offset (g57 as example) in the gcode. 

the machine is absolute- and the offsets are absolute positions- the relative comes in after the offset is called, as all moves are now relative to the offset not machine home or user defined origin.

Is it practical to setup G offsets for one-offs? Sincere question - I haven't played with them much.

maybe not... but what IS useful is homing the machine (mechanical zero) and then jogging to where you want user defined origin to be, and before assigning it as such- jotting down those coordinates.... I don't do this that often... i do it when i'm working on a piece that either i'm going to have to remove and then cut again (painting, perhaps?) or a piece that is hard to replace.  IF you choose this manner, you can toss out the jive above in the first question. 

I did consider writing down the mechanical coords once my origin was set. Is there a "Go To" type function in the HD-100? E.G. Go To 250,350,30

not that i know of there is no "go to this place" button... but it can be done by populating an offset BEFORE the gcode is introduced and moving relative from that point, OR, it can be brought up programmatically by either going to the predefined offset location, OR, by entering a line in the code by hand right after the GO X0 Y0 Zsafe that says GO X250 Y250 Z30.... i've done it both ways...

to be forthright, I don't have a single offset programmed in my DSP controller.... i just make mark of the origin's coordinates from mechanical zero and i use registration blocks to press the material up against... which works out the same without all the confusion or different approaches.   and to further present, i got one of those 300 win mag rifle casings with a laser pointer in it... if I lose position in space on an irreplaceable material, i'll slap that thing in the collet (300 winmag fits nicely in a half inch collet) and run code well above the workpiece and with the spindle off, and to make sure the cuts are where they should be.  i'll often 'cut air' above an expensive work piece with the same gadget before running the cut, just to make sure.   

Help and Support / Re: HD-100 - Random Resets and Origin Loss
« on: December 19, 2023, 08:17:20 AM »
man, I hate that for you.  There is really no way of anticipating a blink in the system- and which is most often caused by a power fluctuation either external to the machine or on the machine side of the internal transformer... it happens to all machines from time to time no matter the brand or build.  external, there is hardly anything that can be done without investing in something like a universal power supply which cleans output and stores enough energy to carry the machine to a point it can be recorded and closed... internally, when a failure happens there is usually little warning when it's electrical.   

there are two options for you moving forward, and they're in preparation for responding to a systems failure more than any kind of fix. 

the first is effective 95% of the time- which is setting an offset in your controller to correlate with the origin of the workpiece- not to be confused with setting the origin- it's a fixed position that leverages one of the g55-g59 offsets (there are actually a lot more slots than that available) and these offsets are set from the machine mechanical zero- meaning the movement to them is in absolute coordinates before it swaps over to relative and is done before any kind of gcode from a toolpath is loaded.   this will protect your workpiece if you encounter a systems reset mid stride.

the second is basically the same as the first, but instead of storing the coordinates of user origin in one of the slots for offset, you write these coordinates down somewhere- coordinates, again, are absolute from mechanical home.  If you lose your origin due to system reset, you just home and then bump the axis's over to the coordinates you wrote down and set as origin.  this will work all the time, even if the machine loses the programmed offsets during a system reset.  as an example of this, i used to write my origin coordinates directly on the spoilboard especially when i was cutting on something of value, and in a spot not used or covered by the material being cut.

.... i gotta say this carefully as not to come off as an ass- understand i learned this the hard way myself- but using a 'user origin' is a hack... it's a mighty useful and constantly used hack to the point of entering operations as a 'part of procedure hack' and one i use every day.. but from a machinists point of view who, say, works at a place cutting high valued material and which an eff up would cost him/her their job- the only way to safely proceed is using a programmed offset as opposed to a user defined relative origin. 

doing so does two things- it offers the person operating that machine protection by removing the 'could be arbitrary' but certainly 'relative user origin' from the mix.  if someone jacked up a workpiece of high value and i wanted to see the code to see what happened, as soon as i see code vectoring off of 'relative' position it's that operators fault.  if, however, i see the implementation of a g57 offset, let's say, my only question would be "what is the location of this offset and what is it's relation to the material fixtured to the bed?".....

^that's just an hypothetical example of how that can play out in a true production environment... how and what it means to us who answer pretty much to ourselves when we encounter these things is:  removing the user origin and using a pre-positioned offset OR using an origin in which we recorded the position from absolute/mechanical zero mitigates a good bit of concern out of encountering a system reset- and we can just pick up and move on if one happens.   

the only thing i know of that can help you avoid these types of happenings is to make certain your machine is well grounded so it is less likely to pop something off in the system while operating.

General Discussion / Re: SCA44 Offset in -X and -Y directions
« on: December 10, 2023, 10:10:49 AM »
There is a little block in fusion that's way too easy to look past... it refers to g51,54,55- the offsets.. I haven't seen a post processor for the hd100 in quite a while, but I can tell you when autodesk introduced that option a couple years back it wreaked havoc with folks not knowing where the problem was..... turns out autodesk populated the offsets with a value and if you didn't deselect that option, you'd have an offset...

Scour the beginning of the gcode for any of those g5x codes... it'll appear but once after the headers and before the first cut.

Fusion/autodesk annoys the hell out of me when they update, as even reading the release notes doesn't always describe all the changes... they force the update (cloud) and then don't mention a tiny alteration, and that alteration then cascades into other things... that dang offset back when was a doozy to figure out. 

Edited to add: the offset isn't present in your design- it's added to the output code before be processed to gcode... that tiny little check block asking about "use g5x?" Is where it's controlled/toggled. 

Help and Support / Re: Z Cut Depth Issue - Moziak
« on: December 05, 2023, 07:31:33 AM »
When you installed the file you may have noticed it asked you 'from internal drive or external drive' as to where the replacement file was located...

While you were thumbing down to "restore data" directly before it was a "backup data"...

With a clean bak file, use the "backup data" and save to internal... you'll now have a clean bak file saved to restore from when using "restore data from internal memory" so you don't have to keep up with the thumb drive. 

Help and Support / Re: How Accurate Is Home?
« on: November 28, 2023, 06:18:37 PM »
I don’t talk with anyone from there, anymore.  I've no clue what they've published or not published.  I may, maybe, post up what I provided them for owners manual which had a section in there about maintenance... though that was for S series DSP...

Re:repeatability.... if your game is production and running the same files over and over, there are tricks... one I like the best is to set "home" to actual mechanical home, and then set your origin/datum to an offset of something shoved up against your registration pins/block. 

The machine has to be indexed upon power up- it finds those by coming back to trigger the limit switches on the low x, low y, and high z... then, it bumps off of them a specific distance.  You see this every time you turn your machine on and home it... make that your machines "origin" too...

Then, bump over to your registration pin/block closest to the mechanical and machine "home/origin"... write that down, and assuming you're using the lower left aka low x and low y...

In vetrics (or autodesk) set your machine bed size to the limits of your movement, and make a template to reflect that.  Then, when assigning your origin, use an offset which is the coordinates you wrote down. 

^that is pretty much foolproof.  If you lose degrees using that method, you've got big problems as it's using the machines thoughts of what's mechanical home as it's origin, and that shouldn't ever change. 

You can get fancier... I had a routine programmed once that used the same mechanism as the z-zero macro... m105 or something like that (I refuse to memorize m or g code... its too easy to screw up, so I reference a list every time I dig into hard scripting code)... basically, the machine moves until its interrupted... its interrupted by a closing of a circuit attached to the z axis...

what the script did was akin to a xyz touch... an xyz touch, for those who dont know, lowers the z axis and finds the closing of the circuit (surface of material) and retracts a short distance sorta like the z touch... what it does then, which is commonly used in machining, is it moves over a specified distance beyond the corner of a square metal plate on the x axis, drops below the surface, and slowly moves toward the plate... when it touches it, it rebounds a short distance and z retracts again... then it moves over job speed to the same coordinate except y axis this time- drops the z and slowly moves to the plate.. when it touches it, it stops and rebounds. 

That^ xyz touch ensures your material is square to the axis(s) and finds the top of the material. 

My script was different but using the same idea... instead of the two or three inches on the x or y, it would move out to the corner of the material and where I also had a registration block planted. 

I chunked that entire prospect after using it a few times because it took so long to use it that I may as well have manually found home..... that... and DSP has no means to reconcile an error other than just stopping... and...  while messing with the actual code inside the as211 is dangerous of you don't know what you're doing. 

The xyz touch (or zxy as it was) is handy but only for visual confirmation your material is squared.. dsp has no way to interrupt the rest of the code if it isn't.  So, you're standing there watching the operation with your thumb on the cancel button, which takes away any advantage of automating it.... if your registration blocks are right and your origin is good, all you should be interested in is z'ing...thats the rapidedist and mostest accuratedest way... good blocks/pins and knowing exactly where they are in terms of coordinates.

Insofar as maintenance, keep the machine clean.  Rails, motors, electronics.  I use the oiler- never more than five seconds of squirter which is just enough time to load pressure enough to move oil... I also spray all moving parts with silicone spray once a week at least, run the machine to every limit immediately afterward, and then walk away until morning when I'll wipe off the excess.  The silicone dries and leaves a film on the rails and cogs- one that is dry and doesn't collect dust/debris as oil or grease does. 

That's pretty much it, though this post turned into a book I typed with my thumbs.. please forgive the typos.

Help and Support / Re: How Accurate Is Home?
« on: November 28, 2023, 02:34:11 PM »
i've done it the way you describe if i understand correctly.... and the only issues i encountered is variations in the material... it was ply, in my case, and the variation was all three directions- width, length, and thickness... the thickness variation drove me to language that scares children and animals... and that is the one dimension that couldn't be addressed in any other way but programming. 

the biggest concern you're going to have is likely down the road from where you are now- it's when the machine settles in and can loosen it's grip on the helical rails- allowing the Y axis a little play and ultimately binding.  i've dealt with it many times with others and even encountered it on my own machine.  it's easy to forget these things need some love every once in a while- and which is why it's now a matter of scheduled preventive maintenance to re-seat the steppers/servos every 300 hours of op or every six months. 

an item that can hasten this is improper use of the automatic oiler- it doesn't need much oil to be happy, but it does need some from time to time... if yours is automatic based on timer, it's my opinion to squirt no more than 5 seconds every 650 minutes of operation.  more than 5 seconds of squirt can actually make those little ball bearing become a ram in a hydraulic type operation and fling them out on the glide rail for you to discover.... or worse, step on and go gliding across the floor... 

if those bearings come unseated and go play jimmy hoffa, there is now tiny amounts of play in your machine and any debris in the helical rail itself can bind the Y travel taking you out of square, and wrecking your/the machines precision moves...  phantom was clever with the downward facing helical rails and especially the covers making it hard for debris to find their way in there, but they still can- especially if they're oily and hold on to the airborne dust/debris (from too much oil)...
bottom line is as always- take care of the machine and it'll take care of you.  keep her clean and lightly lubed, and re-seat the steppers/servos twice year or so... keep the cabinet blown/vacuumed out, and don't let sticky stuff settle on it too long... blow it off with dry compressed air after use/at the end of the day, knocking anything clinging to the glides and helical rails away...  pretty easy, but also easy to forget because these things pretend to be main battle tanks.

AutoDesk FUSION / Re: Atomic Not Ramping
« on: November 21, 2023, 09:44:29 PM »
That's the difference between a clean design and a not so clean..... I love aspire, as it's quick and easy to create something 2D... but... make a circle which is four arcs, right? Now, use the function to place a ring around it a certain distance away while not deselecting the corner/angle option... if you enter node mode, you'll see the circle (still four arcs) but the other one? It'll have a gazillion nodes which are tiny straight lines....

As for the design manifested? If it's wood you likely won"t notice... acrylic, though? You'll see the jagged little edges instead of a smooth cut.  You'll also see in the code one that uses four lines of code for that circle when using arcs... when using a ton of little short lines between a bunch of nodes, that is a literal ton of code...

One of the things i love about this job is i dont manage people with personalities- instead, i tell a computer what I'd like to have... if it doesnt respond predictable, then the fault is mine as it just does exactly as its told.... reminds me of the joke the c+ programmer was sent to the store by his wife with instructions"get a jug of milk and if they have fresh bananas, get six"... he comes home with six gallons of milk.... and he was in the right because her logic failed.

Help and Support / Re: Z Cut Depth Issue - Moziak
« on: November 21, 2023, 08:15:16 AM »
my next comment was going to be to reach out to Brandon to get the Bak file.  There was a time Phantom used me as a tech, when they didn't have a staff and those folks they did have were buried- and anything up to that point i wouldn't hesitate sharing.  now?  too much has changed with the machines... specifically, the pulse width/rate for deciphering the movement, which is the first line(s) of the bak file.  the gear reduction boxes when I bought my machine and up until last year about this time were the same- then there was a period where 'some' were the old ratio and others were the new ration- this was because the vendor for that part swapped the ratio's unannounced- Steve&Co 'knew' the ratio was going to change, but the vendor did it a few deliveries early- and the gear boxes look the exact same from the outside(casings)... talk about confusion!  ... and for customers that got the wrong programming in relation to whichever gear box they got only had to change the pulse width/rates to be back in business....

what problem that created, though, was there are now not only two (gantry height differences) bak files, there are at least four if not 12.  ... which makes getting the right one tricky... and something i'd rather have the factory do- as they can pull the file on that specific machine and know everything needed to know about it.

once the specific file is obtained, i can help load it up- that sort of thing should be taught and made as common knowledge for owners.... you ARE going to encounter a corrupted bak file at some point if you own a DSP S-Series at some point- there is no way around it... flash drive with failing sectors can do it, a bump of the flash drive while the machine is in motion can do it, inserting/removing the drive while machine in motion can do it- a power surge can do it... it's just the way these things are and why it's a good idea to save the fresh and clean bak file to your internal memory (backup-internal) and then restore the file (restore-internal) every so often....

Help and Support / Re: Z Cut Depth Issue - Moziak
« on: November 19, 2023, 08:18:54 PM »
If it stopped mid cut then it lost comms with the drive, and if that wasn't caused by a corrupted file, then it corrupted the file when it did that. 

I can share the bak file I have,  but I'll need to know the gantry height from the bed to confirm which one you need (z travel), the period you bought it (pulse width for gear box changed from 4:1 to 5:1) and dimensions of the machine. 

I've come to trust saving the file "backup" to internal drive AFTER "restore from udrive/thumbdrive" and just making a habit of restoring from internal afterward every week or so of use just to be careful.  These are found under menu, then machine settings.

Help and Support / Re: Z Cut Depth Issue - Moziak
« on: November 17, 2023, 09:52:49 AM »
the only thing i don't really like about that post processor is the index(datum;origin) is pre-determined by the material and lower left corner.  that is something that should be left to the machine and not the script.  it's a flip between g91 and g92, or g51/54, which is relative vs absolute coordinates... the machine takes your origin- where ever it is you've set it- and realizes it is relative to the actual bed.. so long as it knows the origin (relative) in relation to the working size of the table (absolute) it does the math to 'look ahead' and see if you're going to crash...

the post processor relays "no" to z zero off the bed... that's okay, i guess, but not really necessary for it to process... all it 'should' care about is whether the movement is positive or negative when it drops into the material.  this isn't a big deal- it's just strange that they've included it. 

question: have you ever driven the z axis into the bed on accident? aka 'crashed' the z axis?  this would be the only thing that would cause the axis to drop without a command to do so... the reason is the ball screw could be broken, which is surprisingly hard to spot.  if you're using a upcut, the bit will 'drift' upwards if it's broke, and if you're using a downcut, the bit will drift downward.   if you've crashed that z axis this is something you're going to want to check... the torque these machines generate can break it (torsional sheer) and it be a hairline break all the way through and really difficult to see...

also- have you ever removed or added a thumbdrive while the machine was in motion?  has the machine ever just stopped in the middle of a job as if it was finished but not return home?  if so... and even if 'not' so, as a power surge can also do it... your bak file may be corrupt.  they corrupt when using a bad thumbdrive, even... and... they don't announce it- it just keeps doing what it figures is expected of it but pushing the g-code through a corrupted/missing formula... if so, replacing the bak file is simple and easy, and SO easy i recommend folks do it whether they think it needs it or not every 100 hours of use.  A corrupted bak file (some refer to it as a machine profile) can easily do what you're describing.

Help and Support / Re: Z Cut Depth Issue - Moziak
« on: November 16, 2023, 12:18:26 PM »
Thanks for the response! I had to contact Mozaik to create a Post processor.  The original one that they created didnt work (I can't recall the extension).  I ended up sending them a Vetric file that I had created which ran fine so that is probably where they came up with that extension. I am not the most technical guy when it comes to troubleshooting software files.  There are a million different settings in Mozaik and it has been running fine up until the last 2 cuts which is puzzling.

So would you lean towards something it the post processor/software vs a stepper/hardware related?

I looked through the code, and it tells the machine to do exactly as you described... its not the machine- it's sinking to that 18.3mm or whatever it was exactly just as it's told. 

Do me a favor- make a toolpath and share it.  Say, 24in x 24in one inch thick material and a single straight line cut at 1/2" deep, and then a circle 12" in diameter cut (not pocket) dead center at a half inch deep as well.  Do both with ramps leading in over an inch distance.  Hang the file up here and I'll look at it.

If I'm not mistaken, mosaic holds the post processors hostage- it's in the cloud.  They may have changed that, bit that's the way I understood it to work.. meaning: we may not be able to actually see the pp code.  All we can do is see how the output code is formed.  In the end, that's all that matters- it's just some are cleaner than others.  If theirs is tossing a g-code command that our machines don't recognize, that there may be the issue... ours are set up to use the fundamental g and m codes- nothing fancy...

Help and Support / Re: Z Cut Depth Issue - Moziak
« on: November 16, 2023, 07:36:49 AM »
snippet from file- the first moves to cut:
Code: [Select]
G01 Z-6.350 F1905
G01 Z6.350 F10160
G01 Z-12.700 F1905
G01 Z6.350 F10160
G01 Z-18.313 F1905
G00 Z25.400
G00 X949.800 Y384.950 Z25.400
G01 Z-6.350
G01 Z6.350 F10160
G01 Z-12.700 F1905
G01 Z6.350 F10160
G01 Z-18.313 F1905
G00 Z25.400

man, it looks like that Z axis is bobbing for apples or something as much as active as it is.... also, the file extension is .phs-v for that file... it's a naming convention i came up with indicating ph(phantom)s(s-series)-v(vetrics).... meaning, that post processor is for vetrics (aspire.v-carve) NOT mosaic.... if i'm not mistaken, mosaic is cloudware and provides a post processor under some sort of lease and the software won't process to machine code if the subscription expires.... that would be my very first stop which is to validate the post processing is happening as it should be. 

that said, i can't image why any post processor would have such a strange array of z-axis movement "up and down" as much as this indicates.  It also changes the feed rates (not the speed, the feed) every time it bobs up and down.  that would be okay as some find it useful on some materials to slow down going into corners or coming out of them- it's a strategy, anyway- but the weird thing with your code is it changes the feed as it tells the z-axis to go up and down but doesn't move the x or y axis at all...

the ultimate depth, indicated on the next to last line i quoted, is at a depth of 18.313mm which is roughly 3/4"--- so the machine is going to that depth following the codes instructions.

there is something wiggy with either mosaic or the post processing function- and though post processing seems something like witchcraft and/or mysterious, it's actually pretty straight forward and simple...we are the ones that overthink it... meaning: i can't see how any post processor would translate CAD to CAM with such arbitrary commands as making that z-axis bob for apples... which is why i think this one is solely on mosaic...

and that file extension ".phs-v" is strictly for phantom s-series running DSP and CAD'ing with a Vetrics product... but that STILL isn't an excuse for all that z-axis movement.... that is something mosaic is doing...

do you have vetrics (v-carve, aspire) and can you rebuild the design in it, and process using the phs-v post processor?  you'll see the differences in the g-code for yourself. 

does mosaic interject some sort of macro function at the start of their toolpaths?  that is all that makes sense to me with that code- which means it 'could' be a depth probing routine akin to machinists "four touch" automatically finding both origin and z-zero- touching a plate that rests on the corner of a material block with a known/precise distance from one corner to the next, and a z-axis probe to each corner.... IF there is a function within mosaic that adds that, and there may be, find it and turn it off and this may go away.

Pages: [1] 2 3 ... 11