Hello, I'm trying to connect to the Openbuilds Control app with an ESP32 board. It's a new way to support GRBL, but unable to connect while with GRBL_32 no problems. The application correctly recognizes the Grbl 1.1g type message ['$' for help]. Do you have any solution that could solve the situation. FYI GRBL_32 in version 1.3a connects with method 2. Thank you in advance.
yes it works with bCNC. But strange that Openbuilds only works for GRBL 1.1. With me it also works in 1.3a on ESP32
It is GRBL compatible tho. I played with FluidNC for a few hours on my ESP32 based controller the other day and was very impressed. However I reverted to GRBL 1.1 when I found Control won’t talk to it. it reminds me of Klipper for 3D Printers, all config is done in a config file and there’s no recompiling needed to change stepper motor drivers etc.
Thanks for the answers. Sorry for the misunderstanding, I don't want to deal with a FluidNC problem but understand how Openbuilds identifies the cards in order to modify FluidNC so that it can be recognized. Indeed there must be a reason why with one programming the card is recognized and with another it is no longer. Which is strange since the two programs have the same GRBL base. @dJOS_500 Thank you for giving me hope with your answer. I'm going to investigate the code a little deeper.
Only somewhat - both are based on standard Grbl (because Grbl's motion algorithms are solid) , but are projects in and of itself. FluidNC does not announce itself as Grbl, handles settings differently, etc. Its 'not grbl' and we ONLY support GRBL (actually only official Grbl from Home · gnea/grbl Wiki - even with 3rd party forks of that we'd refer you elsewhere for support. We only support the official Grbl). They claim Grbl Compatibility - but then go and "do things differently" in the form of other start/version strings, other configuration methods, etc thus making it "not grbl compatible". If it announces itself as Grbl (like GRBLESP32 did) it is still pretending to be Grbl. If it announces itself as FluidNC - well, rightly so its not Grbl. Going to close this topic shortly, understandably, CONTROL is for Grbl, as we use Grbl on our machine controllers. We are happy that 3rd party devices running Standard Grbl can benefit from CONTROL. We have no intention of either supporting (inside the software), or providing customer technical support to 3rd party controllers running non-standard Grbl, or non-Grbl firmwares as we have no familiarity with those and no need to support it. Of course if you do decide to get yourself an OpenBuilds BlackBox running Grbl - it would be a different story with full support in both software, and in technical support for it!
I understand your point of view and agree with you that if it's not GRBL there can be no support from you. By dint of seeing a multitude of developments we sometimes get lost a little. One last question and before I decide to take a BlackBox, on which processor is the firmware supported? Thank you for your clarifications and your response.
Thanks, but it's a bit low on CPU for continuous JOGGING. I have on MACH3 a continuous jog that doesn't stop midway or freeze the map. I tried with an Arduino UNO board with only GRBL and sometimes the board hangs. Buffer overloaded I think. So I'm looking for a solution that would reassure me on this side. Do you have in the near future a development that would be done on an ESP32 which seems to me to be better able to overcome this phenomenon?
Perfect Continuous jogging with BlackBox with CONTROL.... If you were using some other host that didn't implement Jogging properly it would feel weird. So good that on INTERFACE we don't even offer an Incremental mode anymore you don't even need it.
This is what interests me about your application. However, I have two other constraints. 1- The motor drivers integrated with BlackBox support a maximum of 4A and I need double that. My drivers are separate from my control board. 2- I just noticed that I can't uninstall the Openbuilds Control application. I got a message that the application is still in progress. I am offered to close the uninstaller automatically, to continue the uninstallation. But he doesn't. Bug of the latest version? I tried to reinstall to possibly correct the problem. Same result. Have you noticed this problem and what is the solution?
I've done this before but also shut down and restarted the pc without opening any apps, just tried uninstalling Open by running uninstall.exe from the Openbuild Control root folder. But same problem.
There is only what is strictly necessary to start the pc, no third-party applications other than graphics card drivers, sound, etc. No particular launch applications.
Press Ctrl+alt+Del Click Task Manager Click the Details tab and sort by Process Name Close the running instances of OpenBuildsCONTROL.exe which you'll find there
When reinstalling Openbuilds, I get a message telling me that there is already an installation in c:\Program Files and it will update the files in that folder. I let it install until the end without problems. The application launches normally and I then try an uninstallation which displays the same error messages and without going through the uninstallation procedure. I used the REVO UNINSTALLER app to uninstall and deleted the registry entries. I can then reinstall without having the message telling me that there is another existing installation. I install and then uninstall. Same problem as before, can't uninstall.
I just saw your screenshot, before uninstalling, there are no occurrences of Openbuild in task manager. But they do exist when I launch the application. So it works fine.
I just installed and uninstalled Open on a virtual machine. Carefree. Maybe there are incompatibilities with other of my applications.
Most likely. Or the OS is just a bit corrupted and needs a format/reinstall. Either way, glad you are sorted
Yes maybe also, MS does not always tell us everything.... I have a question but in private is it possible?
This is an automated reply: For support questions, please make use of our Forums (not private messages): Support is done via the public forum: - More people can see and thus answer your question quicker - Remember to search for your issue using the Search box. Its might already have been discussed a few times
I'm late to the game, and I have not updated to the latest version of FluidNC, but the prior version, while Control threw a couple of errors, worked just fine during my testing. The basic $ commands are still in place, so limits, homing etc, all still work. I guess after I redo my electronics (I just bought a box to replace the components being laid out on plywood, and I am using the 6 Pack), I will update and see if control still works.
They changed the startup string to FluidNC and we still expect Grbl. We are not planning on supporting FluidNC so we won't be adding a check for the nonstandard startup string. Thus the "firmware detection" fails.