Might need to "calibrate the screen" with a variable power supply and some masking tape... That said, this sort of imagery is hard to miss (courtesy of the Q-Line driver before I replaced it): Noise is noise, any significant ripple you find anywhere is suspect.
Correct! But you do need some idea of the scale its on, depending on the scale a a 10mV ripple and a 10v pp ripple can 'look' similar
True. I think anything in triple digit mV is somewhere that's at least worth looking into (only ~250mV PP in the pic, based on those cursor settings, but caused no end of problems for no discernible reason; I can only assume it got amplified under load or something). It's more just that it's indicative of something not-quite-right somewhere than necessarily being *the problem* in and of itself. Hence the masking tape! 5V or even ~3V from a couple AA batteries across the whole screen would show plenty. Time period is another issue, of course. A kHz wave and a 10MHz wave are both gonna do some damage, but one may not even be visible depending on the general settings.
Sorry guys, I'm still here. I've had a few deaths in the family do to this darn Covid-19. Well my blackbox came in last Thursday and I was able to install everything yesterday. As of today all is well, however I did find out that most of my problem was coming from my post processor. The Grbl post processor from Bobcad is not compatible with this Blackbox. So Bobcad is going to edit it so that it will work with the Openbuilds control software. There seems to be NO problems with any axis thus far.
Ugh, sorry to hear that. This thing's awful... All we can do is hope against hope that there's a functional vaccine or biological available by the end of the year or early next year, and meanwhile they have half the country trying to open back up. This sounds... Slightly odd. If it's not compatible with BlackBox, it shouldn't really be compatible with stock grbl/Arduino either. OB CONTROL just sends the code, it doesn't interpret it.
Exactly, then their Grbl Post is not Grbl compatible. Wouldn't be the first time though, even Autodesk's default Grbl post is not correct. Big companies fail to think all the time... When they send you a working Grbl post (no need to refer to it as a BlackBox post etc, we truly run stock standard grbl) - do post it as a resource for the next guy though (bobcad users are few and far between though, but still, share it for the next guy) -> Resources | OpenBuilds
I've seen this a few times, but Fusion's grbl post has worked perfectly for me. Is there a discussion on this somewhere to skim through?
I havn't noticed any changes to the post, but, if you have turned off tool changes in the options and have G28 set correctly or turned off, then it does work just fine.
I will Peter. They have been modifying the post for me and as of now it is working but it will need a couple of more modifications so that I will be able to do a tool change. I figure today I should be completely ready to go. Then it will just be up to me to learn and hone good cnc strategies. Once I know for sure their post is completely safe to run I will post it if that's ok.
We recommend splitting each tool into its own gcode file, most of the Grbl hosts (and grbl itself) does not support toolchanging like the big machines (refer Toolchanges · Issue #26 · OpenBuilds/OpenBuilds-CONTROL for an example thread of trying to implement toolchanges to CONTROL, but its still far from production ready)
I will do that Peter. I do have a question you be able to answer about changing tools. When a M06 tool change code is issued would a GO G28 code follow? So that the spindle can travel to a safe place to change the bit. I'm not sure and I'm thinking that is the modification I need Bobcad to make to their post, or something like that. What are your thoughts?
Ah, yeah, I set up what seemed to be the more important machine parameters in the machine setup window. Seemed like an easy shorthand to me, but I guess it makes a difference. Looks like Autodesk have specifically addressed it in the post options- Grbl Laser doesn't even mention it, which probably isn't surprising, though interestingly LinuxCNC defaults to G53 and grbl defaults to G28. Honestly I'm still not even 100% sure what difference it makes, since the grbl wiki says it supports G28 (LinuxCNC behaviour) and when F360 used to throw an "M6 T1" at the beginning of a program just because, grbl never complained, it just ignored it and continued on its merry way (and I just confirmed now by throwing a random M6 T2 into a program before running it... No issues). I suppose if Fusion's expecting a different tool diameter and/or TLO and programs accordingly after the M6, which grbl has obviously ignored, I could see that being a potential problem. Which I wouldn't run into on a laser, of course.
G28 works just fine if the machine is setup correctly. Beginners tend to set machine home = work home by jogging to the work home then resetting GRBL. this makes the default G28 settings of 0,0,0 an unsafe move and users ask why the bit drags across the work at program start. Use the correct 'fake home' and G28 works just fine. I use G28 as a tool change position, I have a macro in bCNC to move to G28 which is a nice spot for me to change tools in the Makita router. But this does require a consistant home position since G28 is an absolute position, if I were to have home 100mm left in X then G28 would crash your GUI, probably UGS? is filtering the toolchange codes, GRBL itself will choke if it receives an M6 or Tx. Send T1 M6 with the MDI and see (-:
Oh, makes sense. I'm perfectly comfortable using proper G53 and G54 origins (depending on how cooperative the limit switches are being on any given day, anyway), G28 always seems like more hassle than it's worth- G54 G0 to defined location, followed by G53 G0 to G28.1 coordinates, but only for axes specified- so if you don't want to move an axis for the first move (say a vertical move only in Z), but you do for the second, you're apparently just screwed? Nah, I think I'm good. bCNC, I've always liked it. Feels like I could make it do anything I want it to. And yeah, Error 20s with MDI M6 input.
Ok I know I'm in the right place. I got everything working fine as long as I don't have to do a tool change. I'm not sure if I'm understanding this right. Are you all saying in order to do a tool change in grbl you have to treat each toolpath as (say) a new part?
Not necessarily. You could produce the complete program as normal, and then (manually, or using a g-code sender macro like bCNC allows) convert "M6 T*" into a whole sequence of moves in its own right. Typically for any given machine, the moves will be very similar (Z0 @ front of machine for convenient collet loosening, pretty much) so it's easy to tell your sender, "hey, when you see this G-code, convert it into this pre-programmed sequence". Alternatively, you can manually find and replace your M6s in like Notepad++ or something with that same sequence. All you need to do is tell your machine to do something along the lines of the following: move to safe Z move to toolchange location M0 optional stop for change upon resume, move to touchplate location probe, update TLO back to safe Z back into program flow Which, when you think about it, is what an "integrated" controller is doing in a proper machine- it's just that the stop-for-change is more likely part of an internal automation ladder program or similar, where the machine says "ok, I'm here" and then waits for the toolchanger to say "ok, I'm done" before moving on. grbl doesn't have any of that extra programming in it, the ATMega 328P IC just doesn't have enough performance or memory overhead in order to be able to run it. It's a pure motion controller, nothing else. Hence, we talk about bCNC and macros; it's the job of the sender to take on that higher-level programming task. Now a lot of people find it easier to not do all of that, especially if they're working with a simpler sender that may not have as extensive options for runtime replacement macros. So what Peter's saying is that by having each tool in a whole new file, you set up the beginning and end of the programs in the most convenient fashion for tool setup and as long as you have a consistent home location, you don't even need to run them on the same day, if you don't want. You can hard-code all the G53 stuff for toolchange and probing, and just copy and paste it at the beginning and end of every program. It's a slightly simpler option that keeps things a little more beginner friendly and requires less machine oversight (because M6 is basically now M30). There isn't really a right or wrong answer here, just whatever's more convenient for your workflow. In any case, you're only telling grbl how to move, not why it's moving. It can't understand that and was written explicitly not to require it. Sounds like it's time for another link to gnea/grbl - everything we're talking about is there. It might take weeks to get through it all and months to wrap your head around, but it's more than worth the effort! All the whys and wherefores are explained within.
I'm coming in a little belatedly here (the forum stopped emailing me updates, so I was sitting all alone in the dark crying to myself because I thought no one was replying to me. All those tears, all for nothing... The O'Silly O'Scope stuff is going to have to wait until I've gotten some sleep, but on the tool change issue, the behavior I was used to in Mach 3 was rather simpler than Rob's description (and didn't require a fixed touchplate location). It would essentially feed hold, let me swap out the tool and manually (or with a separate script) set my new Z0, and then wait until I told it to continue. That probably wouldn't work without some new functionality in CONTROL and/or grbl (since I think one or the other balks at running G-code while in feed hold - does it handle M0/M1 any differently?), but I (obviously) haven't really looked into it in much depth. The fact is, I eventually came to the conclusion that I was usually better off with a lot of smaller toolpaths anyhow - at least for one-off projects. When you've got everything combined in one big program, if something goes south 3/4 of the way through (whether because the machine goofs up, or because I goofed up), then even if it didn't do any damage, you're stuck starting over from the beginning. If I've got it broken up into separate tools (or, more often, each tool broken down into separate operations), it makes recovery a whole lot easier. Of course, a lot of that comes down to what sort of work you do. While it makes perfect sense for one-offs and prototyping, it's obviously a lot less convenient if you're doing production work, at which point you want everything as close to automated as possible, which looks a lot closer to what Rob described. -Bats (the other other alternative is to make OpenBuilds give us a nice little drum ATC kit. Make it happen, Peter!)
Here I get the emails but often can't do anything about them because the OpenBuilds domain is so frequently 502 over the last week. Nah, M0 puts grbl into feed hold and everything gets greyed out, can't do nuthin'. I used to be like this, until I discovered that bCNC will let you select miles and miles of code, and then just click the () button and poof, it all gets commented out simultaneously. And the visualizer updates, so you can see if you took out something important earlier on.
if you are using Fusion360 the preferred post is this one swarfer/GRBL-Post-Processor which will automatically convert tool changes into separate files, one for each tool. The big reason for this is that each tool needs its Z height set, GRBL does not support a table of tool offsets. Though I am confidant I can create (safe) gcode for this in the middle of a program, and figure out some way of integrating it all with a tool height sensor and so on, I believe that it is really much easier and faster and safer to use a file per tool. so the process is set up tool 1 run file 1 set up tool 2 run file 2 and so on. where 'setup tool' is physically inserting it and then setting the Z height for this tool. 'during program' tool changes only make sense if you have an automatic tool changer, but then there is a bunch of complexity regarding tool length offsets etc.
About what I figured... That's no fun. I really need to get around to playing with bCNC. I think I've even got it installed - just haven't taken the time to get it sorted out & set up. CONTROL is decent enough about source editing (actually much better than Mach 3 in that regard, which had an awful internal-ish editor, and awkwardly implemented external editor support), but not so great at telling you where you were in the file... All you can do is copy the text of the last reported line (if a grbl reset hasn't already pushed it out of scrollback) & search for it, delete everything above it, then hope to hell you didn't miss a G90/G91 in there somewhere. What I miss is the "run from line x" option in Mach 3, which could intelligently handle all the preparatory moves first. The lack of spindle visualization in jog mode also contributes to making recovery harder - especially when your X0Y0 reference point has been machined away... But I think I'm drifting off topic into wishes & whining now, and I already do too much of that in the CONTROL thread. - Bats (wait... topic? did we even have one of those?)
... which would be of limited usefulmess (thank you, Samsung handwriting recognition) anyhow, unless you've got all your foods (err... tools?) equipped with depth stops to ensure repeatable lengths. "Safe" gcode sounds like " boring" gcode to me. Where's the excitement? Where's the fun of not knowing which axis may be wrenched, which workpiece may be destroyed, or which limb may be severed by the next tool change? Live a little, people! Not to mention a bunch of complexity regarding having an automatic tool changer. Of course, now I'm watching sitting here watching the old ER-collet foolchanger (umm... is Samsung trying to tell me something here?) video from hackaday for the hundredth time. I would've thought length offset would be a lesser issue, though... once the ATC loads the tool, shouldn't it be fairly straightforward to then drag it over to a touch plate? -Bats (fool in search of a foolchanger)
Problem there is that ER collets don't seat consistently... You really need something like a backstop screw to hit reasonable tolerances, but spindles don't come with thru-bores to do those kinds of things. Though I suppose there's nothing technically stopping you from dropping the turning spindle directly on a drill bit... I've turned parts on my mill with lathe tooling held in the vice before. I've thought about that a lot too. It still seems elegant in the simplicity of its approach... My concern is how feasible the 77ftlb of ER25 is to achieve. ER16 or so would be significantly easier for normal size spindles. G53 to the plate, G38.x probe, G43.1 relative TLO update. Should be fairly simple.
Back to VFD noise, checkout this thread from @Paul Stoller For those with noise issues. - the link he shared is teaching me a thing or two
Probably for the best, since, among other tangents, I don't think the scope thing is happening any time soon. I warmed it up a few days ago and it seemed to work (which is to say, a dot/line appeared stably on the CRT and would do vaguely different things when certain knobs were shifted), but today - after the probes belatedly showed up - it was far less cooperative. First the dot/line (or, when clipped to the LED ring, squiggle) insisted on sitting way off the top edge of the tube. Then - after briefly opening it to stare in wonder at the totally tubular innards & gasp in horror at the condition of some things that might be caps (or might have been caps) - it was off the top edge and blinking on & off about once a second. Unfortunately I have neither the patience nor, as it turns out, the budget for a recapping adventure, and little clue how else to approach it (I can sometimes fumble my way through simple modern electronics, but I don't even know where to start fumbling with tube-and-dead-bug architecture), so, with no small regret, I think I'm going to have to re-shelve it - and with it the idea of doing any scoping on this project. Still, I think the innards are worth a few pics in their own right... Count the tubes! Hand-painted resistor color codes(!) and another shy tube hiding in its metal...tube tube? Also check the red/brownish & yellow things-that-are-possibly-caps, which seem to be coated & have the ends sealed (or possibly "sealed") with some sort of wax. Connected to the BNC jack, we have another wax-"sealed" cap. Past tense. Sealeded. (although I actually can't even tell whether it erupted, or was just dipped in the wax a little too enthusiastically). Also, there appears to be one of those halloween bite-size Hershey bars in the middle. Or maybe a Kitkat - it's hard to tell from this angle and I always preferred Krackle or Mr. Goodbar. I think I may have stumbled on that one before - I seem to recognize the feeling of slowly glazing eyes interspersed with bright flashes of revelation - but obviously I didn't read it closely enough. Guess I should give it another shot, now that the oscilloscope won't be taking up any more time. -Bats (now if I could just remember where I left that spare attention span...)
oh boy, tubes! I had a tube 'scope back in the 80's. it was old, and non linear, but it helped with some things. but then something went wrong inside... there was an aux input on the front panel for a banana plug that had exposed metal, and whatever went wrong put 400v DC onto that socket. that bit me so I scrapped the scope. have lived without one ever since. temped by a Pokit though....Pokit Meter | World's Smallest Multimeter, DSO and Logger
