Until today, I never had issues with my workbee 1010. I use a Blackbox controller and Openbuilds Control 1.0.279, the G-Code is generated from Fusion 360 with Workbee - Duet post processor. Today, when milling, the machine suddenly stopped within the job (file Job1). No alrams, no nothing. So I tried to pause the job. After continuing it worked for some time and then stopped again. I split the job into two to continue from where it stopped (with file Job2) but then things got worse. Althogh I can jog the machine as usual, when I try to start the job, nothing happens. I then realized, that after uploading the code I get a "websocket disconnected" message from the controller and it says "open builds control probably quit or crashed". I diasabled the 3D viewer as suggested in some discussions, tried different computers, nothing helps. All connections on the workbee look fine. I also tried a job from an older project, the job was started as expected. Is there something wrong with the G-Code? I have no idea what's going on. I attached the two G-Code files I used. Any suggestions?
You may prefer to use a Grbl post: see docs:software:vectric [OpenBuilds Documentation] (shouldn't the cause of the current issue, but may later cause some other problems - Duet and Grbl are different firmwares) We will check for bugs and let you know [edit: Update to v1.0.280 - bug found and fixed]
As @Peter Van Der Walt said - use a grbl post processor with Fusion 360;- docs:software:fusion360 [OpenBuilds Documentation]
Also found a bug in v1.0.279. Fixed, v1.0.280 is available: Release v1.0.280 · OpenBuilds/OpenBuilds-CONTROL Thanks for reporting the bug
First of all: Thanks for the incredibly fast replies and even more for the bug-fix. I followed both suggestions and the machine control works flawlessly again. There is only one thing which luckily did not destroy my workpiece. The suggested post processor adds the following line of g-code almost at the beginning (and also at the end of the file): G53 G0 Z-10 This causes the z-axis to step down 10mm when moving to the starting point which is a path within the stock. Maybe this is related to the WCS settings? The post processor requires a setting of 1 to 6 but honestly, I do not know what this exactly does. To sort things out on my side, may I ask which bug caused the problem in Openbuilds Control? Are both steps (changed post processor and new version of Openbuilds Control) necessary to solve the issue or would the update of Openbuilds Control allone have solved it? Maybe I find the time to also test it with the new software version and the initial G-Code version.
The Grbl post relies on standard Cartesian Homing. G53 = machine coordinates G53 Z-10 is at the very top of Z travel, just below the Z limit switch, which is at the top of travel. That is a standard safety feature to get Z up and out of the way of clamps etc before moving XY. So this points to potentially incorrectly setup homing on your machine Bug was seperate from Post, but still better to use a Grbl post for a Grbl machine
Solved by either having homing switches and using them consistantly, or using this resource to fake the home and doing that consistantly.
