Hey guys. Small problem. I recently put a Workbee 1010 with a black box together and have been doing some initial setup and testing, or lack there of recently. Just to give some background, my day job is at one of the big aerospace firms in industrial robotics. Different software, different languages. Haven't done much with GRBL until recently. I dry ran the ubiquitous Hello World .dxf once and had no issues after I figured out "setzero XYZ" is intended to identify the WCS after homing with the limit switches setup. I tried to do it again but scaled up and with a marker to plot it this time. After powering on the next day and going through the cycle again then trying to run, the machine will continue to the front left corner (if facing the tool) and trigger the hard stops as I have them enabled since I dont want to eat a coupler or worse. I've got the toolpath in the center of the work envelope from OB CAM. To its credit though, the GCode generated is showing the toolpath starting in that position. I'm not really sure what happened but I've combed through the grbl parameters again to no avail (some of which are incorrect). This really seems like something small and stupid. Any shove in the right direction would be awesome.
Are you sure you didnt reset your WCS to your homing position? It certainly sounds like you did. Or, if you're like me, after homing you jogged where you wanted your new X0 Y0 but forgot to click SetX 0 and Set Y 0. I do that more than I care to admit. If you jog to where you think your center is, what does your DROs say? Do they say you are are X0 Y0?
Ok I definitely did that a couple times during troubleshooting but corrected it after. I've been going back and forth with the step pulse and direction inverts so many times in attempts to rectify. So my home position shows positive values in the first shot and yes the intended corner of the workpiece position shows XYZ all at 0. The second one is after trying to run the routine and it runs into the limit switches and now gives me the negative value error. Am i correct to assume the machine coordinate system when jogging and facing the tool should be X+ left, Y+ forward and Z+ up?
Assuming your are standing in front of the machine. X+ move to the right. Y+ moves away from you. Z+ moves up. Assuming homing position is in the lower left, your DROs will show negative numbers if your WCS is set somewhere besides machine home position.
LOL, I have a sign on my monitor that says "Reset Axis' to Zero" and I STILL forget to do it sometimes.
Ha! Last week I switched cutters in the middle of the job and forgot to re-zero the Z. I plunged down into the wood almost to the collet before I hit the pause button. Thankfully it was a test run in scrap plywood and not the nice hardwood I was going to use for the finished product.
I've got my machine coordinates setup correctly according to the video but that also conflicts with the value for grbl settings from the workbee page (pic). When I run the routine this time the machine drives all axes to positive directions (back right corner) without stopping before end of travel. (I stop it of course) It seems there may be some conflict with my setttings. Can someone screen shot settings from their serial console?
Dont worry about matching settings. You need the set the machine based on how the motors are wired. In a perfect world, the motor wire colors in the videos will match your motor wire colors. However, this is not always the case. So, set your Step direction invert mask to whatever will give you X+ to the right, Y+ away from you and Z+ up when you jog. If your limit switches are in the lower left corner, your homing direction should be set to invert X and Y only.
It's setup exactly as described and yes the limits are setup for the front left homing and X an Y are inverted. The OB gear logo still moves to end of travel +. If that's all right then there's an issue with the coordinates the OB CAM is sending. Ok on to something....fast forward a bit to another idea and my theory seems to be proved correct. I just placed a simple 100mm circle about 250mm center from WCS origin and it ran without issue. Is is possible from the grbl console to call up current positions and offsets? And is it possible to see posted coordinate data from OB CAM before running? Something about the previous posted coordinate data was not correct based on these results.
In your first post you said " but scaled up and with a marker to plot it this time". Do you mean that you made the gear logo bigger? As in too big for your machine? "And is it possible to see posted coordinate data from OB CAM before running?" Yes, the 3d viewer show you that. In any case, save the gcode file to a txt file and attach to your response. Please do not paste the gcode directly into your response.
Yes I increased the size on the original test run and it was well within the work envelope of 824x780mm from WCS. I did a restart of PC, controller, PS somewhere in there so maybe that cleared some cached data. Not sure. Ah..yes the live data box from the Sim. I was speaking more of seeing all the routine coordinates listed but just realized after saving the Gcode and viewing in a text editor that will work too. Numbers all look good and she runs without incident... for now Thanks for the quick responses guys!
Ok it looks like this is not solved. It's clearly a software or controller issue. I checked all this with a previous .OBC workspace that was working correctly and now it isnt. I post gcode from a simple vector and when i try to run it, the simulation in Control completely ignores the toolpath as does the actual machine. I double checked the coordinate data from the gcode and it looks normal, well within the envelope. Again the machine wants to travel + direction way past limits. Nothing has changed except for sitting idle for several hours and it's doing the same thing as before. This doesn't matter at this point but there are a bunch of UI bugs in Cam that I'm also noticing in addition to this main problem. i.e. it doesnt generate gcode when it says it does certain times, click reset view and the grid locks up and generate frees it up. Pretty frustrating to say the least.
Update... I picked up VCarve not long ago and was kind of working through things in stages so held off diving too deep with it. I decided to remove OB Cam from the mix as it was just being very buggy in general. Again I created some simple vector based toolpaths but in VCarve this time and what do you know, it worked flawlessly. It seems OBCam is not functioning properly for my particular setup and the machine is working just fine.
If you have Vcarve its best to use it for CAM. Vectric products are paid software for a reason, and also why we do resell it, it is good.
Do post any broken files with detailed bug reports on OpenBuilds/OpenBuilds-CONTROL for the devs to check too
