Hi, My old Arduino Nano died a few days ago so I went with a Mega 2560 board as a replacement. The trouble is the openbuilds control software won’t recognise it. I’ve flashed with the official Grbl branch for the Mega (v1.1g) and tried the Mega-x5 version (1.1n). Both of which work perfectly fine using other controllers but just are not recognised by the openbuilds controller which is by far the best out there and therefore the one I want to use. the only difference I can find is that when Grbl Panel (my alternative controller) accesses the board, there is far less verbose status presented than I’m used to seeing. But it does show the version info. what does the openbuilds software use to confirm there’s a v1.1 board present? can anybody please help?
Sounds odd. If it's the official Mega port, it should output the same serial comms. Based on what I've seen in grbl's and CONTROL's sources, their modularity shouldn't care about what specific hardware it is, only that it's using the correct serial data formats. @Peter Van Der Walt?
It waits for the string "Grbl digit[dot]digit[letter]" after reset or after it sends Ctrl+X For example [18:15:12] [ ] Grbl 1.1g ['$' for help] [18:15:12] [ ] [MSG:'$H'|'$X' to unlock] See OpenBuilds/OpenBuilds-CONTROL Connect to your Grbl using a serial terminal (putty, etc: 115200 baud to the correct port) and see what it outputs on connection, if nothing (autoreset disabled?) then try Ctrl+X and see what it says Then we'll take it from there Example coming off a BlackBox First messages came automatically on connection (after autoreset) Second set is me pressing Ctrl+x
So what ever happened with this? I am in the same boat, board responds and broadcasts the correct connection message, but openbuilds control, seems to ignore it. When I connect with putty it responds with exactly the right message. Additionally, when I send a ctrl-x, it also responds. What is openbuilds control expecting? ITs like its totally ignoring what the response is. I tried connecting to another PC and it worked for a second, then I tried changing something on my grbl code and it failed again. Trying to run a mks gen 1.4 which is just like an arduino mega 2560 with ramps pinouts.
Never got feedback from the original poster as requested in the post above yours. Answered above: You can confirm that's what our code check for here: Want to help? refer to my post above. Do the test and screenshot it as requested
I have to shut down the openbuild server app on my machine when I want to try to reconnect, its pretty fustrating, but after I do that, it connects just fine. Any thoughts? I have to close the app in my system tray.
What exactly does or does not happen. Clues in the serial log. Do you have USB Selective Suspend setup correctly in Windows Power Settings?
I press the connect button and openbuilds control tries to connect using its three methods as seen on the terminal, and does not find the controller. If I stop and start the openbuilds control service it finds it the first try every time. I have tried resetting my controller, unplugging and plugging back in, nothing seems to work other than stopping that service by quitting in the task tray.
Ok I found the setting, it was in the documentation 4.2 not 4.3 as you mentioned. The setting was enabled, and I disabled it. Hopefully it will work better now. Thank you for the help, and the software is great. I like it much better than 1980s mach3 interface.
It should. Of course hoping its a Genuine arduino. Not a chinese knockoff with a CH340 on it. Those chips are terribly unstable. Consider a BlackBox 4x though, support the company that makes the software you love
Peter, thanks for the info, I will probably go with a black box, but that will be for an upgrade once I am up and running. The board is a [spam link removed] which probably has the chip you are talking about. The parts I got from openbuilds are very nice, and once I go to a larger router, i will for sure get more stuff from you guys. Also, thanks for the software support. Jason
I'm having the exactly the same issue, however disabling USB selective Suspend doesn't fix it. I have tested with multiple boards including the BlackBox 4X, Ramp 1.4, Uno, MKS Sbase, MKS Gen_L. I found the issue only happens with boards with ATMEGA2560, and whatever which the USB serial chip. - The BlackBox 4X is ATMEGA328P with FDTI, no problem. - Th Uno (compatible with CH340) is ATMEGA328P, no problem. - Ramp 1.4 with FDTI, ATMEGA2560, has the issue. - MKS Gen_L with CH340, has the issue. - MKS Sbase is a LPC1789 build-in USB serial, no problem. Reproducing: 1. Launch OpenBuilds CONTROL, connect the board, select the right serial port and click connect. The board successfully connected. 2. Click "restart gbrl" under the disconnect button. (Ctrl+X 0x18 sent), the board soft reset, the connection is still on. 3. Disconnect and try to connect again, the board will be connected. The port.on("open") entered, but never entered parser.on("data"). 4. Quick OpenBuilds CONTROL from the system try and restart, recovered. 5. Before quite OpenBuilds CONTROL, connect another ATMEGA2560 board, can't connect, the same issue, but a non-ATMEGA2560 board, connect properly. 6. Before quite OpenBuilds CONTROL, successfully connected a non-ATMEGA2560 board, then switch back to a ATMEGA2560 board, still can't connect. 7. Before quite OpenBuilds CONTROL, use Universal Gcode Sender， Easel or Arduino IDE to connect, no problem, try to connect from OpenBuilds CONTROL again, still can't connect. I suspect it's node serialport's issue.
So please help by checking for us, what it sends I asked the original person above, but never got the feedback sadly (actually also asked the second person to do it too without feedback) If you guys want support for it, the least you can do is the quick test to see what String it prints on reset so we can see if we can add it for you. We don't have 2560 based hardware lying around, so we'd love to do you the favour but no point getting upset its not supported if none of the 2560 users helps with the info we need
Hi peter. It sends nothing. the code reaches port.on("open"), then nothing happens after it. No port.on("data") or parser.on("data" ) hit. I enabled "set DEBUG=serialport/*". and confirmed.
Hmm, that's weird, that's all we check for; 1) We open the port OpenBuilds/OpenBuilds-CONTROL 2) We rely on the autoreset to make Grbl send "Grbl x.x[az-]..." (we check for it here OpenBuilds/OpenBuilds-CONTROL) 3) if after a second autoreset didn't work (boards without DTR/Autoreset) we send Ctrl+X to make any listening Grbl instance reset itself (OpenBuilds/OpenBuilds-CONTROL) and wait again for the string "Grbl..." from 2) above 4) If after 2 seconds we still did not see a ""Grbl x.x[az-]..." string, we send the word "version" to see if any instance of Smoothieware is on the other end (not supported anymore, but first couple version of control could talk to Smoothie), we wait for the Smoothie version response: OpenBuilds/OpenBuilds-CONTROL 5) If Smoothie also does not answer, we close the port OpenBuilds/OpenBuilds-CONTROL As you have both on hand, stopwatch the responses in Putty, see if the GrblMega stuff is a lot slower to respond maybe? The timing works with official Gnea Grbl-Mega, and Gnea Grbl (328p) but community forks kinda does become a "well why are they doing xyz differently from upstream"
Sidenote, this is different (does connect first time) from the problem the thread starter had above. He could not connect at all So might not be related to startup string then (rather lower down in SerialPort where it seems then the events get paused or die when you reconnect, which does work with original Grbl, so wondering whats different in the serial buffer here. Sadly the 5x folks did zero effort to update wikis, readmes even source comments )
Wow, I didn’t realise the thread had carried on after my original post as I didn’t see any email notifications. Today’s the first email I’ve had! I can’t really help though. I lost patience and dumped the 5x version of the code and went back to standard grbl pre-branch. Never had any problems again. I did go back to 5x some time later but still didn’t work. The problem was intermittent but more towards failing than not. I might get one in every 5 or 6 tries to connect and then nothing.
I found the issue and resolved, pull request created. clear statusloop interval before set it by linanw · Pull Request #153 · OpenBuilds/OpenBuilds-CONTROL Every time grbl restarts, welcome message (with "Grbl" it) will trigger setting the statusloop, without clear the loop previously set. stopPort() only clear the last one, but leftover rest of them. It seems blocking the port from open again. I can't tell if the root cause is from node serialport or the grbl-Mega firmware. This issue happens on Mega boards only. I tried also on an Uno board, I can see its serial led blinks crazier after I "restart grbl" multiple times, but the Uno board just can be reconnected again. I made a video with the Uno board for its led blinking difference after clicking "restart grbl" multiple times. The fix ensures there is signal statusloop, I tested on few different mega boards, no more problems. Cheers! .
Thanks will test and merge in next release cycle. Weird still that it only affects the Megas but oh well. Good catch nonetheless, should be cleared before reinstating.
v1.0.250 Release v1.0.250 · OpenBuilds/OpenBuilds-CONTROL released, give it a test and let me know if there's any issues
Hi Peter, I have run the new release with multiple projects for few hours. I didn't find any problem.
I also have had this issue i thought it was the china board so i tried a few different ones but same issue so i got an official mega board in today to try and still same issue it fails when i try to update the firmware.
openbuildsCONTROL cannot flash a Mega board, it has firmware for Arduino Uno (Atmega328p based like the Blackbox 4x) and the Blackbox X32 which is ESP32 based. looks to me like you are trying to flash an mega256 based board, which is not supported. if you can flash GRBL 1.1 to the mega board using other tools then OpenbuildsCONTROL might well talk to it ok if they have not changed from the standard GRBL protocol.
