Always: Old versions all the way back are here Releases · OpenBuilds/OpenBuilds-CONTROL Give it a go, but checkout OpenBuilds/OpenBuilds-CONTROL - not sure what version you were on, ie how much of an update it was, but I can't think of any changes that would cause your issues. If you were say on 1.0.238, and jumped to 1.0.243, it was all cosmetic stuff (menu for VFD spindles, Fixed a G1 vs G0 bug in surfacing wizard, updated certificates and dependencies for security, updated the cloud based build process to node12, and fixed some cosmetics with a scrollbar popping up in the probe wizard) . 1.0.244 is in the changelog, but not released yet at the time of this post so not related either Hang in there though, Fusion and the G53 moves are tough on beginners. If you could work only in G54 it would be less confusion (Vectric etc)
The "go" button haha. And thank you so much, I'll give this a shot and get back to you. It may be something I mess with over the weekend. Ill keep you posted. Thanks again
does your machine have home switches? if not, did you properly 'fake the home'? Gibbs rule no1 for CNC : home first, then everything else (-: Which Fusion post are you using? It should be this one OpenBuilds/OpenBuilds-Fusion360-Postprocessor
absolutely correct (-: update before the test cutting or after the successful job is done, but not in the middle of a process. Never update under pressure (-:
I turned off the limit switches. Turn everything off, Move the machine manually to table zero, turn on the machine and power supply, fire up the software, plug which in the USB, which should zero the machine coordinates, then move it with the software to the work piece and set zero, load the g code, hit the button that makes it go around the perimeter of the job to make sure the stock is where it needs to be, return it to work piece zero with the machine, hit the "go" button, it plunges into the work piece and drags to the start point then plunges fully, then pulls up and starts cutting where it should after leaving a grand canyon sized slot across my work piece. There is a thorough explanation above about how to fix this, which i did, and it worked! And I used it several times flawlessly, turned it on, worked flawlessly, updated, then it got screwed up. Followed the previous instructions again to the T, down to the last letter, doesn't fix the issue. I am unaware of what my previous version was but it was whatever was out last october. With that said, I was asked above to try finding and installing an older versions, which I will do this weekend most likely and get back to you guys. Regarding the post processor, I have the correct one. Please check out the earlier comments and see if you may be able to lend insight to this. Its the same issue as my original post, and you'll see the things that have been discussed regarding issues and solutions. Thank you for your reply. I'll get back to you guys shortly
please post the gcode file here. (so I can run it in my machine, or in simulation at least) and a screenshot of fusion showing where the workpiece zero point is. where did you set zero on the machine? and what size is the workpiece in reality and what did you tell Fusion? which WCS is selected in fusion (setup => post tab)? (should be 1) which WCS is selected on the machine when you do the zero setup? (should be G54) in fusion, check the heights for each operation.
also, in the Serial Console type $$ and press enter and copy/paste the result then type $# and press enter, copy/paste the result thanks
Thank you. I will definitely do those things, though it may take me a bit. I'll see if I can make it happen Sunday. Much appreciated! Answer to your question, for ease of explanation, if I'm standing at the skinnier part of the machine, with the router facing me, it goes all the way back and to the right (Per previous instructions). It goes from there to the work piece just fine... then plunges at the work piece zero and drag it to whatever the starting point of the first cut is, which is usually to the opposite side of the work piece somewhere. What I'm going to have to do is... coear off the machine, set it up, follow these instructions again and run a fresh g code for a fresh project then send you guys the results. I currently work 16 hours a day as a luthier 7 days a week. I have to schedule time tomorrow to do this. I really appreciate everyone's patience and assistance. I'll get back to you asap with the info requested. Thank you!
I know this is kind of necroposting, but I'm curious if you're still on here and if you ever solved your issue. I'm also a full-time luthier, working often 16 hours a day, and I've lost a week of work trying to resolve a very similar issue while cutting inlays. To anybody else who may be reading this, I went through everything that was mentioned in this thread, and did so to a tee, like OP did. It seemed to fix the issue at first, but when I try to run my second operation after a tool change, my position is always off in the x axis by 2 mm. This issue is what lead me to this post initially. And everything here solved the first operation issues. But it's still present in the second operation I'll go through the homing process outlined in this thread, then I zero my work coordinates on my part origin, then send code. The first operation, a profiling cut, will work fine after I'm all homed and zeroed at origin. Then I switch to my engraving tool, load up the code for the second op, confirm my work coordinates are zeroed at origin, and send code. Every single time, the tool jogs to its starting position, but is off around 2mm in the +X axis in the work coordinates. When the first pass reaches it closest position towards the front of the machine, it should be 2mm to the left (-X) of origin point, but it is directly above the origin, even though it's reading -2 on the X axis in the work coordinates box. The first attempt today, I noticed this immediately and stopped the operation. I hit Restore Origin, and it jogged back to the zero, but was very slightly off. A couple tenths of a mm. So, after zeroing again, I let it run its entire first pass above the stock so I could gauge how far it's off. When it got to that closest point I just described, where it should be 2mm to the left of origin but is directly above, I stopped it. Hit Restore Origin, and now it stops 2mm to the right of origin, even though the work coordinates are at zero. I checked if the grub screws are slipping in the motor. They aren't. This would make my first op fail, anyway, and it isn't. I've quadruple checked my origin points in fusion. Nothing seems off. I'm losing my mind with this. So I'm really hoping somebody here can give me some answers. I'm at my limit of trying to figure this out alone. And I'm hoping OP might see this and have some insight, as this is the closest issue to mine that I have been able to find. Machine is a Genmitsu PROver 3018, if it matters. Thanks in advance!
Small update: It seems the longer the second op runs, the further out of alignment it becomes. And this explains why the first failed attempt at this left my part with excessively wide engraving lines, that were also out of alignment with the part. I think it's going out in both the X and Y axes, but it seems the X is worse, even though there's far more movement in the Y axis.
It sounds like it is slowly loosing steps over time so the longer it runs the more inaccurate it is getting. Are there and loose screws on pullies or shaft lock collars? Shorts in any wires?
Thanks for the reply! I did check all of that over thoroughly and everything is in order. This issue is bizarre. I've been working on it since my last post. I created new setups in Fusion just to make sure something whacky wasn't going on there. Ran the new operations and everything seemed solved. I planned on coming back here to add that, but right now as I type this, I have yet another operation running that did the same thing. It will be done any minute and I'm going to restore origin and see how far it's off. I'll up[date in a minute.
That machine has a very low cost driver chip in it, and though the spec sheet is not clear I strongly suspect it is one of the chips that needs a delay between direction change and the next clock pulse. If it does not get that delay it will miss a step, this accumulates during the course of a program and results in what you are seeing. A possible fix is to invert the step pulses, ie set $2=7
Ok, so it's off by 5mm in the Y axis now... Which is the original issue that lead me to this post. The profile I'm cutting is coming out fine (besides the fact that 10% of the machining is being done in empty air past the stock). So it's not that anything is slipping or slowly adding up during the operation. Otherwise, the profile would be completely ruined. It does seem that this second pass has wider tooling tracks, but only by a tiny amount, and nowhere near enough for this origin issue to be explained by slippage. The work origin is just getting completely wrecked as soon as I send an op. If I post a .nc file, could anybody run this op in air and see if the work origin is getting thrown off? I have no idea what else to do. This is bizarre, and like OP, I'm at my wits end.
Wouldn't this result in cumulative inaccuracy in the profile though? The profile itself is perfectly accurate, and it has some extremely small and delicate sections that would be completely gone if the path was slowly losing accuracy. The origin jumping is what seems to be the issue. Or am I misunderstanding the effect that would have? Edited to add that the origin is off by 5mm. If that was cumulative, the entire profile would be completely gone, no?
are you still using Candle? I liked Candle but it does not handle work offsets correctly all the time, have you tried OpenBuilds CONTROL? When you have CONTROL running, you can easily reduce the max rate and accelerations for X and Y. As a test, halve all 4 settings and run a job. Also make sure to run the calibration wizard so we know we are getting the correct size cuts in the first place. yes, please post the .nc files, and tell me about the bits you are using for op1 and op2
when you click 'reply', at the bottom of the edit box where you type your reply, is a button labelled 'upload a file'....
Thank you so much for the help! I genuinely appreciate it a ton. I just tried another run, and somehow it's now my Z axis that is being thrown off... What is happening?! I'm so confused... Ughh I'm not married to candle and would have no reservations about switching. I'll download CONTROL after this. Candle does have an option to override spindle, feed, and rapid. I've been running feed and rapid at 30% just to see if it helped. Didn't so far, but I will try it in CONTROL. To be clear, I have successfully cut some of these inlays, and they fit perfectly into the pocket which was also designed in Fusion. These new attempts seem perfectly accurate as well, just offset somehow. I'll attach the NC files. Two separate versions of each op from trying different things The bits are just the cheap SainSmart spiral mill bits for the profile, and their engraving bits for the engraving. Nothing special, but I've had good luck with them for this exact stuff. The mill for op 1 is .035" and the engraving bit for op 2 is a 5 degree taper bit. Sorry about the photos. I tried to upload them on my phone and it wouldn't let me select them. Just transferred them to my computer and will add them now. The one that's already engraved went well enough (obviously needs tweaked a bit), although I did have to move the origin point to the model instead of the stock box to set it accurately on the machine after the profile op. This worked out fine the first time. Middle inlay profile op went well also. Last profile op had its origin go crazy in the Y axis. Tried to engrave the middle inlay and it also went crazy, this time crashing down in the Z axis and wrecking the inlay. I'll also add a photo of a previous successful attempt profiling and engraving the other component of the inlay. All parts were done with the same CAD/CAM workflow, ops, machine, bits, etc.
Looking at another previously cut tentacles component, it does seem the earlier attempts have a cleaner profile with more fine detail, and the later attempts have gotten increasingly sloppy. You can even see it between each profile in my previous photo. This photo is of my earliest attempt, and the profile is much cleaner than those in my previous photo. But that difference doesn't correlate with the 2-5 millimeter discrepancy in the origin before and after an op starts. So it might be related, but not directly? Idk anymore.
This is pointing toward EMI causing lost steps, or more lilkely, dirt in the wheels/bearings or leadscrews. If it si EMI whicjh was not happenign before, the question is "which wire got moved" (-: great. Candle has not been updated ina long time, CONTROL was updated last week (-: I will give them a try tonight (about 8 hours from now) The increasing loss of accuracy points to 'something loose'. Stepper motors vibrate at high freqency, like an ultrasonic cleaner in some ways, so now is the time to check every bolt and screw and nut, not just visual, but apply screwdriver and see if it turns a bit, a little tighter won't hurt any of them. Also put a sturdy bit in the collet and pull/push on it and see how much it moves, anything more than normal flex (which you know the feel of from changing bits) is a symptom looking for a cure. Dirt on the guide rods will cause spikes in the resistance to movement. You mention elsewhere slowing down the feedrates using overrides, with dirt this won't make any difference becasue stepper mootors are at their weakest when moving fast, and the rapids will still be normal speeds. That is why I recommended setting the maxrates and accelerations lower, slower speed rapidly increases the power available. Another possibilty is heat in the drivers. Over time dust builds up on the fan and heatsinks which prevents efficient heat dissapation, so give that a brush off (turn it off, earth yourself, hold the metal ferule of the paint brush while brushing to prevent static buildup). If it does not have a fan, add a fan, cool drivers are happy drivers.
Interesting. I'm trying to envision this and how it would play out. If it were EMI over the course of the entire operation, or mechanical interference causing lost steps, the toolpath would gradually be more and more off, until the profile was being cut 2-5mm out of alignment, causing a massively misaligned cut. But this isn't happening. The toolpath is relatively accurate, it just jumps to a random position This leads me to wonder if the interference is at startup. This might make sense, as the spindle motor is an upgraded 20,000rpm motor, which is supposed to be paired with an upgraded power supply. I never got the power supply, and have simply been manually ramping the spindle speed on startup. But even starting at 10,000rpm, the motor stutters. I've had issues before with second operations losing origin, but never this issue of losing origin on every op. How would I alter the .nc to ramp up the motor before making any movements? This would at least let me eliminate this as a variable. Or, could I start the spindle in CONTROL before sending the op? CONTROL is awesome, by the way! I won't be switching back. I really appreciate all of the features y'all added. It's a killer piece of software! I ran the calibration wizard and was only out on the X and Y by .4mm. Got that sorted now, but the issue remains. I'll clean everything thoroughly today. I did clean it and lube it with Teflon the other day, but I'll go over it, and the motors, today. Again, I really do appreciate the help! I know this isn't exactly a forum for random machine users, so I don't take the assistance for granted. I plan on building a machine (current machine is a loaner I've had for years), and I'll be buying my parts here when I do. Going from the [insert software] forums where devs and experts are often condescending and unhelpful, this is a stark difference, and is greatly appreciated.
Add a G4 Dwell after the M3 Sxxx spindle on command: G Codes to give it time to spin up You can turn on the spindle from CONTROLs Tool On menu, but in the Gcode makes more sense. Are you reprobing/rezeroing between tool changes? Do you have $1=255 in Grbl Settings? If not - set it! Keeping drivers enabled avoids loss of position between runs
Ok, I'll give that a shot! Yes, I am re-zeroing between each op. I've even re-homed the machine between ops, as outlined in page one of this thread, to see if that helped, and it hasn't. Like OP, the first time or two, rehoming with the hard limits off seemed to help. But since then, it hasn't.
[QUOTE="Do you have $1=255 in Grbl Settings? If not - set it! Keeping drivers enabled avoids loss of position between runs[/QUOTE] Just noticed the last part of your response. I'll do that also. I just added the dwell command, so I'm going to do a test run with just that variable altered to see what it does. Then I'll check if $1=255, and set if not.
more detailed: you want to set a low speed, wait a bit, set a higher speed, wait a bit, repeat... like this: M3 S5000 ; if it can go that low G4 P2 ; is 2 seconds long enough? S10000 ; otherwise start here G4 P2 S15000 G4 P2 S20000 G4 P2
Thank you for the added info! I did an in-air run after adding a 5 second dwell after spindle start-up, and it did restore origin perfectly after finishing! This very well may be solving the issue. I haven't had a chance to run it again, but I do now. I'm a bit reluctant, but I think I'm going to try a real run and see what happens. I'll respond about that in a bit No problem on the delay! I'm just grateful for the assistance! These things can be daunting on your own, so it's very nice to actually get helpful feedback. Seems like I'm on the right track now, but we'll have to wait and see.
Well, Gentlemen, it seems the issue is the spindle startup! Whether it's EMI, or a current drop causing an error in the driver, I can't say. But it seems that adding dwell on startup is allowing me to retain my origin. I desperately have to get back to normal work, but I'll try some more runs tonight and see if I can reproduce these results over a span of several operations. I don't think you'll have to run my code, David. If you have nothing better to do and want to give it a shot, have at it! But currently, this is looking like an issue unique to my machine specs. Thanks again, guys! I'll make sure to leave an update here for you both, and future readers.
