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
what i 'can' do is move it over to a shared IP.  it's on a dedicated one, currently.  I asked as it's easier to just wipe it than t pack it up and move- but- either is doable.  I paid $6 for IP's years ago, and.... the six series are all but depleted- the newer ones are hex and in theory won't ever deplete... the IPv6's are worth a LOT more than $6, now...  a domain name is linked to an IP address and that's how it knows where to send you when you type the name in the address bar- if i swap the IP for a shared one, it'll ultimately get you back to the forum- but it'll take time to propagate through all the DNS servers.  the TTL for the IP is set to three months, currently- which means the DNS servers check back in every 3 months to see if anything has changed.  the first thing is to change that to 5 minutes- and in theory the longest it'll take for a DNS server to re-adjust with the shared IP is 3 months and 5 minutes.  there may be issues with caches, as some ISPs like to cache lots of stuff so it appears your pages load faster through that provider- and it can sometimes be 'grippy'--- which means i'll have to introduce some 'cache busters' which is tricky business.  but again, doable. 

if the forum is being used then it can stay and that'll be fine... i can just move to a shared IP... but that takes work and time to do, which i'm a bit short on... at least currently... but doesn't mean i'll always be short on... and nothing has to happen RIGHT NOW... i just have a site i'd like to build on a dedicated IP so when that site3 is ready to launch will dictate when this one now moves.

Vetrics / Re: Increasingly rougher cuts
« on: June 12, 2024, 08:17:22 AM »
depending on the time of the year, mine will look similar.  more humid?  hotter? you'll get that... if it's an issue, use sanding sealer before cutting- do whole sheet of ply right there on the table... it dries in like ten minutes even in heat and humidity... it'll eliminate or at least reduce the shredding of the veneer.

in other words, it's more of a material issue than one with the machine... unless it's an engineered composite, you'll get that.

I don't see much need for this page, anymore... does anyone disagree?  Two posts, or so, this year.  I'd like to recycle the IPv6 address- which are in short supply. 

Help and Support / Re: Z-Axis will not go the instructed depth
« on: May 14, 2024, 11:18:38 AM »
I have a SVC 4x4 and I just cut out a few patterns in a 1/2 inch piece of plywood.  After putting the second piece of plywood on the machine for the next cuts, it wont go through the plywood as instructed.  I powered the machine off then back on.  reset the X, Y, and Z axis and it still will not go through the plywood like it did earlier.  I re-installed the post processor and that did not fix it.  I regenerated the file from another computer in the house and still acting the same.  Can anyone point me in the right direction for a solution.  I even manually set the Z axis without the puck and that did not work.  I am out of options.


how much does it 'miss' from going through?  plywood is rarely consistent in thickness, sometimes (and often) from one side to the other. 

are you using v-carve?   

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....

Pages: [1] 2 3 ... 11