Its a POSITION not a move. Z-5 in Machine Coordinates would be right at the top, 5mm away from the homing switch. You can't move to the switch or it will trigger, so it stops just short of it. By default, in Grbl, the entire machine lies in the Negative Quadrant. Read Why is Grbl in all negative coordinates after homing? Or it so annoying and not what I'm used to!
Well, we are back to the homing issue. I'll see how I can work around it in the settings. I don't 'home' and I don't want to.
Stop resisting the much needed standards, you will just keep bumping your head against things that doesn't work right until you do. Homing is a must for anything except the basic "set zero and run job only in G54" work. Everything else, needs homing. Because every other coordinate system is referenced from Home.
I'll just say that my life got a lot better once the homing switches went in. Watching the machine saw through work pieces, the work bed, and supports because it had no idea where home was was nuts.
I'm running the AppImage. Where do logs for the AppImage end up. What happens is this runs for a while. I think the screen saver kicks in. When the BB finishes what it is doing it stops. Not the job but the last spoon fed line of the job. Control GUI is firmly wedged. I have to kill control and restart it to get it back. I don't think it drops the usb but it is hard to tell. I've switched to the .deb if that makes any kind of difference. I need to run some tests. I switched to ubuntu from mint. They're both debian. Surprised there is any difference.
kill the screensaver! A pc that is running a machine tool must not power save or screen save in any way whatever.
I enabled it and it still does the same, it doesn't rise, or lowers, the Z axis. I even tried to enable this line: // #define ENABLE_SAFETY_DOOR_INPUT_PIN // Default disabled. Uncomment to enable. but it acts even way weirder so I re-disabled it. I searched the term 'door' in the config.h and only these instances came up and one about inverting the pin but I didn't bother with it since that is not a problem in my case, I think.
It definately works. If it doesnt raise, did you remember to HOME first? Remember, Parking happens in Machine Coordinates... and yes. You need to enable Door, and enable Parking if you want a Parking motion when the door opens.
Hi Everyone, This is my first time posting so hopefully I am doing this in the correct place. Sorry in advance if I am wrong. I have been running OB Controller on my iMac but have recently installed on a Rpi to run it in my shed instead of the iMac. I have all of the Macros I use set up on the iMac OB Controller, and am wanting to know if there is a way of migrating them over to the Rpi or do I have to input them all manually again into the Rpi? Cheers
Manually at this time: See Backup/Restore buttons for Macros · Issue #93 · OpenBuilds/OpenBuilds-CONTROL for todo list item, but not yet Tip: Copy the details to a text file on the iMac, take that along with you to save some typing when you recreate them
Ok Thanks Peter, And thank you for all the work you have done and do on the Controller software, I love using it.
I know the following problem was mentioned before but I couldn't find it. I run a g-code after zeroing the axes on the material (without homing) and it run perfect. I even run it a few times with no problems. I tried homing first and then zeroing the axes on the material and running the same g-code and the Z axis goes up and hits the limit switch. Where shall I look for to fix it?
How are you generating the gcode? Post a sample file. What we do on the fusion side of things is make a G53 Z move to -5mm (5mm from your limit switch) so it never triggers the switch.
In the SketchUcam options there is a setting that last one, "End position Z for G53", set it to -5mm and it will raise to Zhome - 5mm to avoid that limit switch
Hi. Openbuilds software updated to v1.0.301. I noticed the update due to a change in the UI. When I went to jog my machine (LEAD 1010 + blackbox controller) I notice the feed rate is off - much slower. I had to reset my GRBL settings to a saved profile and everything went back to normal. Is it possible that my Blackbox firmware was updated by the Openbuilds software update? As a consequence of the update when go to 'Check Size' the X-axis moves in the opposite direction to how it's supposed to. I'm stumped as to how this could have happened as I reset GRBL to a saved profile which I am confident works correctly. I haven't made any hardware changes. I turned the controller off in between jobs - 15 minutes later the software updates itself and this unexpected behaviour. I'm unwilling to run a job until the Check Size runs correctly. I'm running windows 10 and export my GCode using Aspire. No other changes have been made. Any suggestions to debug and resolve? Thanks.
Negative, impossible we would never do that. Only YOU can flash firmware from wizards and tools, or save Grbl settings from the Grbl settings tab along with I suspect you had a better tweaked profile, without a backup. At some point restored the default profiles forgetting that since initial setup you applied some changes. Or you had some event that caused a brownout and corrupted the EEPROM. Fix the profile, direction inversion is under $3 Dir Invert in Grbl Settings. Be sure to take a backup using the Backup Settings button on the top toolbar in Grbl Settings once its happy
The open builds control software is great software - steps in the right direction. 1) One way we can greatly improve the software is to re examine the software performance under Windows with regards to CPU usage. The control Software currently pushes my Laptop to 100% CPU usage which interferes with other Windows 10 background tasks. This normally happens when the foreground program (Open builds Control) sits in a tight loop such as a "for" or "while loop". If the programmer ad a small delay or call the windows message queues in his tight loops the 100% usage will drop significantly, Windows and his program will actually run much more efficient. The benefit to users with smaller machines will be huge. 2) Having the option update firmware is great, but is there a way to lock critical settings as the machines are used by NON technical operators as well.
Better to train the operators. A locking mechanism would add frustration to new users setting up their machines for the first time You could use the Javascript Macros with auto start, to disable any functionality you want to though. To prevent changing Grbl settings you'd have to prevent the Grbl settings tab from coming up after connection, and also, have to disable the serial console so they can't send $$ commands. Though they can still sneak $$ commands into the gcode editor so maybe disable that too. Though one can add those commands to a gcode file too, but you can't disable that basic functionality We do not observe that behaviour on our end, but feel free to debug (as it happens for you, easier to diagnose in an environment where the issue is present) and submit a PR: OpenBuilds/OpenBuilds-CONTROL
Thank you very much Peter for your response and knowledge. It sounds like it must have been a brown out - which is very odd. I'll take a look into the settings as you suggested.
Checkout @sharmstr 's awesome CONTROL mods on her blog at Blog - Thayne Co She has a Fullscreen startup macro: OpenBuilds Control Automatically Launch at Startup - Thayne Co
You know, this is perfectly legit question, and I am super curious with all the documentation available for the hardware etc, that there simply is not a page on the download section that states the minimum system (hardware and software) requirements. Every other computer application has this so you know what setup is required.
Hi guys, My system has developed a glitch - I'm running a standard C-Beam, hasn't had a lot of use. For some reason, 11 minutes into a 36 minute project the machine does a spurious horizontal line and then bores the bit into the platform (at the set plunge and feed speeds). I've checked the gcode in Camotics, can't see any stray lines. Any thoughts on why I might be getting this ? Is there any way to change the view in CONTROL to see horizontally what's going on ? <edit> Have run and rerun the simulator and it looks like it must be a machine issue, can't see any stray lines. cheers Rich
Thanks for the quick response, Peter Come to think of it, I turned off the lights around about then, bright neons so maybe that was it.
Hi, Is there a way to restart a job in the middle of a cut? Case in point: While cutting the side of a full size airplane out of 15mm ply, my bit snapped, and I stopped the job. I was three quarters of the way through the job, but there seemed no way to pick up the job after a bit replacement, and had to restart the job from the start. Regards, Duncan
Gcode is a "conversation" so you cannot easily just "start at this point" because earlier on some modals were set, some relative positions were first moved to etc. You can hand-edit of course to ensure modals are kept intact, and also write some manual positioning moves to enter the cut safelty (cannot just move in from zero as it will crash) Or re-CAM excluding areas already completed
