Hi i need help flashing firmware to Arduino but after updating openbuilds control flashing other controller is disabled please help me to solve this problem?
Retiring some old and very rarely used features. You can get older versions from Releases · OpenBuilds/OpenBuilds-CONTROL
Hello just updated to the latest version of the openbuilds software, with the black box, now when I go to run a job it is as if the BB is not connected? I can turn on the spindle, and turn it off but NONE of the controls for movement are working?? I just finished a job 20 minutes prior and everything was working fine, I go do the update 1.0.328 and the above happens?? I have completely restarted my machine and still no movement available there are no red leds on my BB alerting me that there is an issue with the stepper motors. LITERALLY was working fine prior to update. The RUN JOB Function seems to be disable but I am not getting any warnings about soft limits or anything?
I havent had any issues, but you can downgrade to the previous version here: Releases · OpenBuilds/OpenBuilds-CONTROL
Check that there is power (24v) to the BlackBox. If the DROs reflect movement, but the motors aren't moving - its more likely power/power switch/incorrect $4=1 setting
Having the exact same issue today. Ran first job fine, did the update, next job the RUN button is effectively disabled. Serial output when RUN button is pressed is: [ websocket ] Disconnected. OpenBuilds CONTROL probably quit or crashed Hope this issue get sorted out fast! edit: some more information. All machine movement works fine except for starting gcode. Previously had been running Blackbox for hours without an issue, and the next job post-update is giving this serial output. I use the official Blackbox Fusion 360 post. Also there is now a strange "skybox" in the 3d renderer that doesn't match the table dimensions anymore that used to match the machine origin. The box looks like its 100mm off in the x and y.
Just downgraded to v1.0.321 and both issues went away and my next job is running perfectly. Definitely something is up with v1.0.328. (We run our BlackBox/CONTROL machine very hard about 6hrs per day and other than this issue the software has worked perfectly since we started using it!)
Good afternoon, The openbuilds software automatically updated to the latest rev yesterday and i've run into issues with larger gcode files not wanting to start. The file will load but when i click "Start" nothing ever happens. If its a smaller simple gcode file it will run like normal. I'm using the same gcode generator in aspire that i always use with no issues. Please help. thank you!
Please post sample files so we can test if we can replicate the issue. Just tested with a carve of 1.2million lines and works no issue. What OS/version are you running (i still test on win10, not a lot of win11 users yet) Pulled 1.0.328 for now. Just a box that represents machine coordinates. Drawn based on Home + Max Travel values in Grbl Settings and positioned onscreen relative to Work Zero based on the standard Grbl MPos/WPos offset reported by "?". So if its off you possibly forgot to Home, or Max Travel values are set incorrectly Thank you! A much better and more directly attributable report . Facts not assumptions.
I was running on windows 10 but I believe windows 11 is ready to be installed (if that makes a difference). The computer keeps telling me to "restart now to install windows 11". I've attached the files that I tried running on 1.0.328 that would not work but would work on 1.0.321. The 30D Path2 file wouldn't work until I broke all of the features up into separate paths and ran them separately. That was the basis behind thinking the issue was connected to a larger code file. the 125EM Path1 file did work on 1.0.328 if you want to compare that to the 30D Path2 file. 3D 25BN Path2 was not changed. Would not run on 1.0.328 and would run on 1.0.321
Both those runs fine for me - screenrecorded 30DPath2 below Please update to 1.0.328 again, try it again, and lets see if your Serial Log offer any more clues? Sure you weren't accidentally on 1.0.322-327 (should all have been internal test versions, but maybe the updater grabbed the wrong release?)
Yea I'm sure I had 1.0.328.. I'll get it updated and try to run the files again. Where do I find the serial log?
On the Serial Console tab - it shows gcodes, responses, errors, alarms, lot of extra details and troubleshooting info
Thinking back on my motions when having these issues.. It's almost like the "run" button just wouldn't respond. I had all my parameters set and would click on "run" and nothing would happen, no error messages or anything. I could still jog the machine around or load new files... Just when I would click on "run" it was like the button was disabled.. Unless I need glasses or something.. I'll try to re-create the issue tonight.. Thank you
Thanks for the help on this Peter! DM me for my test gcode I couldn't get to start on v1.0.328 if you'd still like to test that. It was a larger file, probably about 30000 lines.
I've had a customer who had time to help test via store support. Looks like the core electron/node backend has put some arbitrary limit on websocket message size. We do try to keep up to date with security patches and do review changelogs but this one with a quick glance seems to have been undocumented. Weirdly it seems to differ between his PC and mine - so thats less than ideal (rolleyes) I am pushing out v1.0.329 Release v1.0.329 · OpenBuilds/OpenBuilds-CONTROL: Switched job starts from Websocket message to HTTP_POST - lets see if that helps you guys with the issue (can't test it here because I can't replicate - so lets let you guys with the issue have the honors) Let me know whether it works - or whether it broke something else (or did nothing)
Just tested v1.0.329 on the same gcode file giving websocket serial error on the previous version, it now works perfectly! Thanks!
I'm having an issue with version 1.0.329, although I'm not sure if this is version related. When I switch on the controller, an xPro V5, and then launch OB CONTROL and connect through the corresponding USB port, the software does not open the port. It does read the GRBL config from the controller but it does not control the hardware, that is, I cannot jog or do anything. If I disconnect OB CONTROL from the port, launch and connect other control software as UGS or CNCJs, they open the port properly and control the machine fine. If I then disconnect UGS and connect OB CONTROL again, it does open the port and behave as expected. What can possibly be the issue? Should I downgrade to a previous version perhaps? Thanks in advance
CONTROL supports Grbl from github.com/gnea/grbl Some 3rd party controllers does not run the official Grbl firmware and thus aren't 100% compatible with CONTROL. We don't provide support for 3rd party controllers
Ignore this post, or read it in context of the resolution below. -------- First completely acknowledging that I'm deep into "unsupported" territory here, but hoping someone might be kind: OB Control seems to be working perfectly, except that the DRO does not update (shows "0.00mm" for X, Y & Z). OB Control v1.0.329 running on a Raspberry Pi 4b (I know, unsupported), sending to an XPRO V5 (I know, unsupported). Code in the GCODE Editor runs, and the machine responds. The Serial Console updates as expected. The 3D view renders (but does not show machine position). The XPRO console shows MPOS updates like: Code: <Idle|MPos:10.000,20.000,-10.000|FS:0,0> <Idle|MPos:10.000,20.000,-10.000|FS:0,0> <Idle|MPos:10.000,20.000,-10.000|FS:0,0|WCO:99.395,27.050,-112.730> <Idle|MPos:10.000,20.000,-10.000|FS:0,0|Ov:100,100,100> <Idle|MPos:10.000,20.000,-10.000|FS:0,0> <Idle|MPos:10.000,20.000,-10.000|FS:0,0> <Idle|MPos:10.000,20.000,-10.000|FS:0,0> <Idle|MPos:10.000,20.000,-10.000|FS:0,0> <Idle|MPos:10.000,20.000,-10.000|FS:0,0> <Idle|MPos:10.000,20.000,-10.000|FS:0,0> <Idle|MPos:10.000,20.000,-10.000|FS:0,0> <Idle|MPos:10.000,20.000,-10.000|FS:0,0> <Idle|MPos:10.000,20.000,-10.000|FS:0,0|WCO:99.395,27.050,-112.730> <Idle|MPos:10.000,20.000,-10.000|FS:0,0|Ov:100,100,100> <Idle|MPos:10.000,20.000,-10.000|FS:0,0> <Idle|MPos:10.000,20.000,-10.000|FS:0,0> ... and these show movement when the machine is following OB Control's instructions: Code: <Idle|MPos:110.000,120.000,-10.000|FS:0,0> <Idle|MPos:110.000,120.000,-10.000|FS:0,0> <Run|MPos:176.450,186.450,-10.000|FS:4243,0> <Run|MPos:217.600,227.600,-10.000|FS:300,0> <Run|MPos:228.110,238.110,-10.000|FS:300,0|WCO:99.395,27.050,-112.730> <Run|MPos:240.770,250.770,-10.000|FS:300,0|Ov:100,100,100> <Run|MPos:249.500,259.500,-10.000|FS:300,0> <Run|MPos:259.925,269.925,-10.000|FS:300,0> <Run|MPos:270.775,280.775,-10.000|FS:300,0> <Run|MPos:281.285,291.285,-10.000|FS:300,0> <Run|MPos:292.260,302.260,-10.000|FS:300,0> <Run|MPos:302.630,312.630,-10.000|FS:300,0> <Idle|MPos:310.000,320.000,-10.000|FS:0,0> <Idle|MPos:310.000,320.000,-10.000|FS:0,0> <Idle|MPos:310.000,320.000,-10.000|FS:0,0|WCO:99.395,27.050,-112.730> <Idle|MPos:310.000,320.000,-10.000|FS:0,0|Ov:100,100,100> <Idle|MPos:310.000,320.000,-10.000|FS:0,0> <Idle|MPos:310.000,320.000,-10.000|FS:0,0> A few days ago (nearly) everything was working. Then I... I honestly can't even remember what, at least 10 hours ago, started me along this doom path (perhaps needing to upgrade nodejs for something else?)... foreboding of doom, then OB Control running super slowly with rendering glitches, then not starting, then refusing to start 'cos s'thing was already bound to port 3000, then nodejs being back at v10 (?), then... that kind of doom path. Anyway, I noticed that while your `pi_install.sh` script still installs nodejs v12, your GitHub Actions yml installs v14, so I managed to update to that, and clouds parted and the sun shone through. Now OB Control is running smoother & better than it ever has... other than that the DRO shows nothing but "0.00mm". Anyone have any ideas? Code: [21:49:29] [ ] ets Jun 8 2016 00:22:57 [21:49:29] [ ] rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) [21:49:29] [ ] configsip: 0, SPIWP:0xee [21:49:29] [ ] clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 [21:49:29] [ ] mode:DIO, clock div:1 [21:49:29] [ ] load:0x3fff0018,len:4 [21:49:29] [ ] load:0x3fff001c,len:1216 [21:49:29] [ ] ho 0 tail 12 room 4 [21:49:29] [ ] load:0x40078000,len:9720 [21:49:29] [ ] ho 0 tail 12 room 4 [21:49:29] [ ] load:0x40080400,len:6352 [21:49:29] [ ] entry 0x400806b8 [21:49:30] [ ] [MSG:Grbl_ESP32 Ver 1.3a Date 20201212] [21:49:30] [ ] [MSG:Compiled with ESP32 SDK:v3.2.3-14-gd3e562907] [21:49:30] [ ] [MSG:Using machine:CNC_xPRO_V5_XYYZ_PWM_NC] [21:49:30] [ ] [MSG:Axis count 3] [21:49:30] [ ] [MSG:RMT Steps] [21:49:30] [ ] [MSG:Init Motors] [21:49:30] [ ] [MSG:TMCStepper Library Ver. 0x000701] [21:49:30] [ ] [MSG:X Axis Trinamic TMC5160 Step:GPIO(12) Dir:GPIO(14) CS:GPIO(17) Disable:None Index:1 R:0.050 Limits(0.000,735.000)] [21:49:30] [ ] [MSG:X Axis Trinamic driver test passed] [21:49:30] [ ] [MSG:Y Axis Trinamic TMC5160 Step:GPIO(27) Dir:GPIO(26) CS:GPIO(17) Disable:None Index:2 R:0.050 Limits(0.000,810.000)] [21:49:30] [ ] [MSG:Y Axis Trinamic driver test passed] [21:49:30] [ ] [MSG:Y2 Axis Trinamic TMC5160 Step:GPIO(33) Dir:GPIO(32) CS:GPIO(17) Disable:None Index:3 R:0.050 Limits(0.000,810.000)] [21:49:30] [ ] [MSG:Y2 Axis Trinamic driver test passed] [21:49:30] [ ] [MSG:Z Axis Trinamic TMC5160 Step:GPIO(15) Dir:GPIO(2) CS:GPIO(17) Disable:None Index:4 R:0.050 Limits(-210.000,0.000)] [21:49:30] [ ] [MSG:Z Axis Trinamic driver test passed] [21:49:30] [ ] [MSG:pWM spindle Output:GPIO(25), Enbl:GPIO(4), Dir:None, Freq:5000Hz, Res:13bits] [21:49:30] [ ] [MSG:Client Started] [21:49:30] [ ] [MSG:Connecting blacknode] [21:49:30] [ ] [MSG:Connecting.] [21:49:30] [ ] [MSG:Connecting..] [21:49:31] [ ] [MSG:Connected with 192.168.1.242] [21:49:31] [ ] [MSG:Start mDNS with hostname:http://CNC_xPRO_V5.local/] [21:49:31] [ ] [MSG:SSDP Started] [21:49:31] [ ] [MSG:HTTP Started] [21:49:31] [ ] [MSG:TELNET Started 23] [21:49:31] [ ] [MSG:Mist coolant on pin GPIO(21)] [21:49:31] [ ] [MSG:X Axis limit switch on pin GPIO(35)] [21:49:31] [ ] [MSG:Y Axis limit switch on pin GPIO(34)] [21:49:31] [ ] [MSG:Z Axis limit switch on pin GPIO(39)] [21:49:31] [ ] [MSG:probe on pin GPIO(22)] [21:49:31] [ ] Grbl 1.3a ['$' for help] [21:49:31] [ ] [MSG:'$H'|'$X' to unlock] Code: [22:46:12] [ $$ ] $0=10 ;Step pulse time, microseconds [22:46:12] [ $$ ] $1=255 ;Step idle delay, milliseconds [22:46:12] [ $$ ] $2=0 ;Step pulse invert, mask [22:46:12] [ $$ ] $3=2 ;Step direction invert, mask [22:46:12] [ $$ ] $4=1 ;Invert step enable pin, boolean [22:46:12] [ $$ ] $5=0 ;Invert limit pins, boolean/mask [22:46:12] [ $$ ] $6=1 ;Invert probe pin, boolean [22:46:12] [ $$ ] $10=1 ;Status report options, mask [22:46:12] [ $$ ] $11=0.010 ;Junction deviation, millimeters [22:46:12] [ $$ ] $12=0.002 ;Arc tolerance, millimeters [22:46:12] [ $$ ] $13=0 ;Report in inches, boolean [22:46:12] [ $$ ] $20=0 ;Soft limits enable, boolean [22:46:12] [ $$ ] $21=1 ;Hard limits enable, boolean [22:46:12] [ $$ ] $22=1 ;Homing cycle enable, boolean [22:46:12] [ $$ ] $23=3 ;Homing direction invert, mask [22:46:12] [ $$ ] $24=100.000 ;Homing locate feed rate, mm/min [22:46:12] [ $$ ] $25=1000.000 ;Homing search seek rate, mm/min [22:46:12] [ $$ ] $26=250.000 ;Homing switch debounce delay, milliseconds [22:46:12] [ $$ ] $27=10.000 ;Homing switch pull-off distance, millimeters [22:46:12] [ $$ ] $30=24000.000 ;Maximum spindle speed, RPM [22:46:12] [ $$ ] $31=60.000 ;Minimum spindle speed, RPM [22:46:12] [ $$ ] $32=0 ;Laser-mode enable, boolean [22:46:12] [ $$ ] $N1= ;unknown [22:46:12] [ $$ ] $N0=G21G54G17G94G90 ;unknown [22:46:12] [ $$ ] $100=200.000 ;X-axis steps per millimeter [22:46:12] [ $$ ] $101=200.000 ;Y-axis steps per millimeter [22:46:12] [ $$ ] $102=200.000 ;Z-axis steps per millimeter [22:46:12] [ $$ ] $103=200.000 ;unknown [22:46:12] [ $$ ] $104=100.000 ;unknown [22:46:12] [ $$ ] $105=100.000 ;unknown [22:46:12] [ $$ ] $110=5000.000 ;X-axis maximum rate, mm/min [22:46:12] [ $$ ] $111=3000.000 ;Y-axis maximum rate, mm/min [22:46:12] [ $$ ] $112=3500.000 ;Z-axis maximum rate, mm/min [22:46:12] [ $$ ] $113=3000.000 ;unknown [22:46:12] [ $$ ] $114=1000.000 ;unknown [22:46:12] [ $$ ] $115=1000.000 ;unknown [22:46:12] [ $$ ] $120=150.000 ;X-axis acceleration, mm/sec^2 [22:46:12] [ $$ ] $121=150.000 ;Y-axis acceleration, mm/sec^2 [22:46:12] [ $$ ] $122=150.000 ;Z-axis acceleration, mm/sec^2 [22:46:12] [ $$ ] $123=150.000 ;unknown [22:46:12] [ $$ ] $124=200.000 ;unknown [22:46:12] [ $$ ] $125=200.000 ;unknown [22:46:12] [ $$ ] $130=735.000 ;X-axis maximum travel, millimeters [22:46:12] [ $$ ] $131=810.000 ;Y-axis maximum travel, millimeters [22:46:12] [ $$ ] $132=210.000 ;Z-axis maximum travel, millimeters [22:46:12] [ $$ ] $133=825.000 ;unknown [22:46:12] [ $$ ] $134=300.000 ;unknown [22:46:12] [ $$ ] $135=300.000 ;unknown [22:46:12] [ $$ ] ok
The Xpro v5 runs on a 32 bit fork from grbl - it won't be entirely compatible with OB Control. Basic g-code commands will work of course. Spark Concepts recommend cncjs, and their are other control software that work well with the Xpro v5. Alex.
I understand that the xPro uses a fork from grbl, but it seems to me that the issue is related to how OBC controls the usb driver rather. Once the connection is made, I've found no issues controlling the xPro, so I don't think that the problem has anything to do with grbl. But I do understand that OBC is focused on the black box
All fixed: I'd hit the reset button on the xPro (assuming that was a complete reset), but I'd not tried actually completely power cycling it. After power cycling the xPro, all's working. I think that this line of pi_install.sh can be updated to: Code: curl -sL https://deb.nodesource.com/setup_14.x | sudo -E bash - (I'm now running node v14.20.0 and it's running better than 12.x was (and GitHub Actions is running v14, and I assume that's working)... but as above I arrived here after a deep spelunking into a versions doom hole, and my system may now be a unique snowflake, so someone else running on a Raspberry Pi should probably check that.)
Good day/Evening or maybe night! I have mounted a welding machine instead of a spindle to the CNC. In order to pause the CNC movement while the weld is performing the weld I have connected a relay on the welding machine to the door input on the Black Box. Relay closes when the weld starts and therefore activates the door input. As of now I have to manually resume the job from the Control software but I would like this to happen automagically. What would be a good solution to make this happen?
