No worries. I was able to setup everything again quite quickly. Having the fine tune steps function really helped.
i dont know where else to turn. I've been looking for a manual/guide for open builds control & this is the closest i've come. i've built a 2 axis router table frame, wired it to a ramps/mega 2560. I had marlin on it, but configured for a delta. and got the steppers to move. then i checked & found grbl 1.1g for mega. and loaded that up. and hooked up openbuilds control v1.0.138 and when i send jogs to it, it doesn't move. I know i probably will need to get a better control board some day, but i'd like to proof of concept before i invest too much more. i cant find anywhere, to tell me what steps to set on the board (1/4,1/8,1/16) and the pre-loaded steps per mm, 250, might be high.
Is it just me, or does this light up anyone else's AntiVirus products? First it blocked it due to ransomware, then it didn't like the file modifications it was doing and it kicked the main executable. The install isn't signed either, so that threw a red flag on Windows Defender. Clearly you folks have it installed - did the last compile from Github have something come along for the ride? Or is everyone just shutting down their AV to get this installed?
You are correct that we are not signing yet. But the rest shouldnt be happening. Any more logs out of Trend? I'll scan them this morning too but I use ESET. We compile on AppVeyor so its unlikely its infected already. Might be something like Trend's heuristic scanner picking up the https webserver (that runs https://mymachine.openbuilds.com:3001) If you could pull some more logs that would be great . (the screenshot says 'a malicious program' encrypted our executable, sounds almost like something already on the machine, encrypted openbuildscontrol.exe when it was written to disk. Cryptolockers sit and wait for file writes to do their thing)
ESET didnt find anything odd, so I'm downloading a trial of Trend Maximum Security like you have, so check it out closer: (300+mb for an AV? 2 hours ETA....)
Start with a known-working config: I'd recommend an Uno/Nano running Grbl 1.1f ( from official release gnea/grbl) or if you only have the Mega, at least make sure its also the official Gnea version (gnea/grbl-Mega - download hex from gnea/grbl-Mega and make sure to wire according to gnea/grbl-Mega - it's not the same pinout at the UNO)
Yesterday's update was the first time my AV popped up with a warning about it not be signed. I'm running Norton.
Peter, Thank you so much. The response is much appreciated. after i posted that i rememebered that i had an unused MKS sbase 1.3 in a box. I was able to load that with the latest smoothie firmware, wire up my steppers and get my machine moving last night. Then i used the openbuilds CAM and generated some rough tool paths and had it stepping through some paces. Its very intuitive, except, i know this is more a 3d printer thing, but homing? I have endstops wired (mechanical) but cant tell if im supposed to use them in this fashion. I've got to actually assemble the z axis before i worry about it too much. Thanks again, and i really appreciate the help.
Oof, just upgraded to 1.138...and I get a bunch of (I mean a bunch...that keep scrolling by) error messages: [18:35:27] [ [external from hardware] ] Openbuilds CONTROL received a RESET/ABORT notification from Grbl: This could be due to someone pressing the RESET/ABORT button (if connected), or DriverMinder on the xPROv4 detected a driver fault So, I do have the external Abort button - nice when I need to park the machine to change out tools... ...the problem is I get several (I stopped counting at 30+) messages a second then... Several messages: [18:35:27] [ ] Grbl 1.1f['$' for help] [18:35:27] [ ] [MSG: '$H' | '$X' to unlock] Several more of the first message about RESET/ABORT... Then Openbuilds CONTROL eventually doesn't get the whole Grbl version number and disconnects... [18:35:27] [ ] Grbl 1.' [18:35:27] [ undefined ] Detected an unsupported version: Grbl. This is sadly outdated. Please upgrade to 1.1 or newer to use this software. Go to gnea/grbl [18:35:27] [ disconnect ] PORT INFO: Port closed ...I do have Grbl 1.1f ... xPROv3 Going back a version or two for now...
As @sharmstr said above - thats Z0 probing; If you want to do your own things like XY probing etc, you can use the MACROs tab to add some G38.x Macros to suit your specific needs too
Hi Toby Would you mind helping me debug this one? 1. Download Putty, close all other applications (including CONTROL) that could interfere with the serial ports 2. Connect to your XPRO: 115200 baud, type your correct COM port, click OPEN 3. In the Putty Terminal, type "?" (Question Mark) A couple times wouldnt hurt: Grab me a screenshot please As you can see above, for the first couple times I sent "?" the button was being held down, for the next couple it wasnt (That was the HOLD button, expecting to see Pn:R in your log) This will tell us if its your hardware (IE does grbl still report Pn:?? in the status reports when you are in Putty) or a bug I cant reproduce here (Works for me everytime, three seperate test boards and hours of trying to get it to do what yours does)
Does hard limits have to be turned on for homing to work? I only have min end stops. Also I do alot of my cam work in fusion and I get a T1 M6 error. Any Ideas?
Love the newest MacOS "no need to force quit" version. However, the latest release broke the webgl support on older Macs. I am hoping you guys enable it again.
Hard Limits tells Grbl it has switches installed, see github.com/gnea/grbl/wiki for more info T1 M6: manually remove the unsupported commands, or use a Grbl compatible Post Processor. As Grbl does not support Toolchanges.
Thanks for the report. Will check, as the legacy webgl switches were in turn causing issues elsewhere so will need to find a middle ground
I don't think you need hard limits set. you will need to set the homing directions correctly, normal homing is at max travel ends (industry standard). no, having negative machine coordinates is not a problem, just jog to your PART ZERO and click the zero buttons in the GUI. you never need to know the absolute coordinates. and if you want to the gantry at the front for tool change, just jog there and issue G28.1 after that giving a G28 command will move to that exact spot every time (if you home in the same place everytime of course) The stock GRBL post in Fusion is not very good as they have not read any of the docs for GRBL (-: GRBL does not support tool changes , for example, so there should never be a T1 M6 code. Please try this one instead swarfer/GRBL-Post-Processor and there are some others around the web if you look. My one tries hard to avoid errors from Fusions habit of creating very small arc segments on leadin and leadout moves.
From: Grbl hard limits and homing David is correct, you don't need it enabled (but since you have switches, doesnt hurt either)
Se See Post #170 OpenBuilds CONTROL Software - I need someone with the problem to grab me those... my test boards/PCs doesnt present the issue to debug it
@Spark Concepts - any idea why the boards are holding down HOLD? (as we can see we do get Pn:H from grbl, so it's a hardware issue...
Alright. So with CNCjs I can home without having hard limits enabled. With OBC I have to have hard limits enabled. But if I have it disabled. The home all button is just gray as seen.
i will research 'hard limits enabled' to see if i can enable it on my smoothie.. then i will have homing? yes/no?
Making the move from Shapeoko 3 to a custom machine using Open Build's c-beam, and v-slot extrusion and was hoping for something on par with carbide3D's XYZ probing, or corner probing. In eluded a couple of photos of my build. Please ignore the messy shop and ball screw config on the Z
Hey i just did the update to 1.0.140 and now i cant jog it will home & can turn on the laser and that's it, am i missing something?
