search

terjeio / grblHAL

This repo has moved to a new home https://github.com/grblHAL
232 stars 90 forks source link

Pi4/Mac UGS "Grbl has not finished booting" Error #108

Closed wbatie closed 2 years ago

wbatie commented 3 years ago

I am trying to use Universal G-code Sender with grblHAL on a MAC and Pi4. I get a connection, but when every I run a command I get the error "Grbl has not finished booting. I am using version "grblHAL-3XU-compat.hex" on a Teensy 4.1-GrblHAL board. bCNC works fine on the same setup.ie Any suggestions?

Thank you, Bill Bag

phil-barrett commented 3 years ago

Hi Bill. Could you post the result of $i from the console?

HuubBuis commented 3 years ago

To get UGS working you need to set the compatibility level to 1 in the file config.h (line 50) replace #define COMPATIBILITY_LEVEL 0 to #define COMPATIBILITY_LEVEL 1

phil-barrett commented 3 years ago

Actually, the prebuilt "compat" ones on my github repository are set to level 10 (should still work). I tested it with UGS on windows and did not see the problem so I wonder if he still has the non-compat build.

wbatie commented 3 years ago

looked in all the UGS files on the Pi4 and found several Config folders, but no config.h file $i [VER:1.1f(IMXRT1062).20200907:] [OPT:VNMSLW,35,1024,3,0] [NEWOPT:ES,TC] [DRIVER VERSION:200907] [BOARD:T41U5XBB] ok

HuubBuis commented 3 years ago

looked in all the UGS files on the Pi4 and found several Config folders, but no config.h file

This is a grblHAL file located in the grbl directory. You have to change the file and flash the grblHAL controller again.

phil-barrett commented 3 years ago

Bill, I just built the attached .hex. UGS seems to be fine with it (G0 works ok, for example). You will need to unzip it and use the teensy loader to get it onto the board. [edit] UGS on Win 10. Dated 9/9/2020. Let me know what happens [/edit] grblHAL_Teensy4_Upload-1.ino.TEENSY41.zip

terjeio commented 3 years ago

FYI if [NEWOPT:...] and any following lines are only added to the $I report when COMPATIBILITY_LEVEL is 0. Do we need a $-command for reporting the selected level when it is > 0? $I+?

phil-barrett commented 3 years ago

Yes, I was just thinking of posting something like that. Or perhaps just add a [COMP LEVEL: x] to $I?

terjeio commented 3 years ago

Or perhaps just add a [COMP LEVEL: x] to $I?

That might be enough to break compatibility...

I'll add $I+ and report the same details as when COMPATIBILITY_LEVEL = 0 plus the configured level. I could even make the level settable at run time? But that is not as simple as adding $I+...

phil-barrett commented 3 years ago

I could even make the level settable at run time? But that is not as simple as adding $I+...

That seems like a great solution though I wonder if it's really necessary?

wbatie commented 3 years ago

Nothing changed! $i works with bCNC, does not with UGS which gives the same error

terjeio commented 3 years ago

That seems like a great solution though I wonder if it's really necessary?

If I ever do it it will have to wait - there are 37 matches for COMPATIBILITY_LEVEL in the source so not done on a whim.

A better idea will be to request grblHAL support from sender developers? Basic support is for them to just write the protocol parser in a defensive manner.

phil-barrett commented 3 years ago

grblHAL support from sender developers?

Yes, that is the heart of my "is it necessary" comment.

terjeio commented 3 years ago

Nothing changed! $i works with bCNC, does not with UGS which gives the same error

$I reports the same data as before?

wbatie commented 3 years ago

No. [DRIVER OPTIONS:USB.2] has been added [VER:1.1f(IMXRT1062).20200907:] [OPT:VNMSLW,35,1024,3,0] [NEWOPT:ES,TC] [DRIVER VERSION:200907] [DRIVER OPTIONS:USB.2] [BOARD:T41U5XBB]

phil-barrett commented 3 years ago

Nothing changed! $i works with bCNC, does not with UGS which gives the same error

Bill, have you looked at this? UGS Not Finished booting

wbatie commented 3 years ago

Yes I have. Works fine with bCNC!

wbatie commented 3 years ago

Is the grblHAL giving a "Grbl" response. Some say that can be the problem.

terjeio commented 3 years ago

Since the $I report contains NEWOPT and additional lines after that then COMPATIBILTY_LEVEL is still 0 in the controller.

As I write this I am running a gcode program with UGS version 2.0 from Aug 14, 2019 with COMPATIBILTY_LEVEL set to 1.

phil-barrett commented 3 years ago

Yes, I am testing it right now with UGS Win 10 to a T41 board. No problems at all.

Bill, I have a RasPi and will set it up to see if I can reproduce the problem. It's going to take some time, though. I suggest in the mean time you use bCNC.

wbatie commented 3 years ago

I am. It's just so hard to use.

terjeio commented 3 years ago

Bill, I have a RasPi and will set it up to see if I can reproduce the problem. It's going to take some time, though. I suggest in the mean time you use bCNC.

Is the Pi needed to flash the controller with a grblHAL version that has COMPATIBILTY_LEVEL set > 0?

phil-barrett commented 3 years ago

If Bill flashed the hex file I attached earlier in this thread, he is running with compat level set to 1.

wbatie commented 3 years ago

I used Teensy Loader on my MAC Pro

phil-barrett commented 3 years ago

By the way, Bill, have you tried completely clearing out UGS and reinstalling it? That is one of the "Not finished booting" suggestions.

terjeio commented 3 years ago

If Bill flashed the hex file I attached earlier in this thread, he is running with compat level set to 1.

Well, NEWOPT etc. is still in the $I report so not so.

wbatie commented 3 years ago

Yes, and I tried it on a Pi3 with same problem.

wbatie commented 3 years ago

Also tried it on MAC Pro which uses the same software.

breiler commented 3 years ago

@wbatie there is now a feature request over at UGS to get grblHAL working natively on UGS: https://github.com/winder/Universal-G-Code-Sender/issues/1468

I do not have a functioning device to begin working on this at the moment though, but when I do this should be a quick fix.

phil-barrett commented 3 years ago

I have set up a RasPi 3 and connected it to a Teensy 4.1 breakout board. I had trouble connecting to a COMPATIBILIY_LEVEL 0 build of grblHAL. It would give the now infamous "not finished booting" error. However, building for COMPATIBILIY_LEVEL 1 allowed a connection and I was able to run a GCode program successfully. Will continue testing but I think that COMPATIBILIY_LEVEL is sufficient to get it running.

FWIW, I downloaded the UGS Platform latest release (V2.0.6). Followed these instructions.

And, yes, this info belongs in the wiki, will add at some point.

breiler commented 3 years ago

@phil-barrett thanks! I've just received the Teensy 4.1, so whenever I get the time to look at this I will start fixing these problems in UGS so that it will work with COMPATIBILIY_LEVEL 0.

phil-barrett commented 3 years ago

Excellent! Hope you receive the T41 BOB soon. US Postal Service tracking does not give a lot of info after it left the country on Nov 12. Hard to tell how much longer it will take.

Let us know if you need any help.

terjeio commented 3 years ago

@breiler FYI the next build of grblHAL will get some additional $ commands for fetching details about current settings, error codes and alarm codes. Perhaps build info too. Output from these can be used instead data from the csv files that has to be kept in sync with the controller - not easy for end users.

Setting details will contain information about datatype, format, max and min value allowed etc. This can be used to build a settings UI similar to the one in ioSender. Settings grouping is on my todo list - when done it can be used to create a treeview of the settings.

breiler commented 3 years ago

I have just merged a small fix to make grblHAL to work with UGS and it looks like its working decently.

I noticed a couple of things that we need to keep working on:

The new changes should be available in the nightly build: https://github.com/winder/Universal-G-Code-Sender/#downloads

phil-barrett commented 3 years ago

That's good to hear.

Would it be possible for grblHAL to resend the boot string when it sees a connection? Does it know connection status?

Joacim, are you considering supporting an Ethernet connection? Telnet might not be too hard.

terjeio commented 3 years ago

Arduino UNO usually reboots when connecting to the machine but the Teensy does not ...

This is a tricky part with 32-bit ports, with USB or a network connection a hard reset is not possible. A soft reset via the grbl reset pin may do the trick though. To complicate matters grblHAL has an option of connecting an advanced DRO/MPG that may take control too...

ioSender startup is done this way:

At connection listen to incoming traffic for a short time, 500mS or so. If real time reports are detected the sender starts up in wait-mode waiting for the MPG/DRO to release control.

If out of wait mode or silence I send a real-time report request. If a response is forthcoming further steps can be taken. If not in an Alarm state query the controller with a $I command to determine what it is.

If in an alarm state then what? Some alarm states are defined as critical and and no action except a reset is possible - depending on settings. A problem for me was that I could not find out the reason for the alarm, and resetting the controller for no good reason is something I do not like to do. To improve on this I have added an option to add the alarm code as a substate to the Alarm status text, in the same vein as Hold or Door statuses in vanilla grbl. The alarm code can then be used for deciding next steps. If not critical I proceed with a $I command to find out what I am talking too, load settings, parser status and request a full status report so I can configure the sender for action. A full status report is an extension is grblHAL, added since vanilla grbl sends some statuses only on changes. This is ok if the controller can be rebooted, but again not always possible with 32-bit controllers.

For safety reasons grblHAL has configurable options for more strict behaviour than grbl in some situations. E.g if reset or estop inputs are asserted then it will not be possible to continune before the switches are deasserted. Same goes for hard limits asserted and homing required on startup. grbl allows a ctrl-X followed by $X to unlock the controller, maybe ok for small hobby machines but not for larger and likely dangerous ones. A sender should be able to handle this.

I should really start a Wiki page for sender developers and spell out the reasoning behind some of the extensions. Some, as mentioned above, is due to the different behaviour of 32-bit controllers, some are for safety reasons and some to add functionality that having of plenty of RAM and Flash available allows.

I have tried to follow the style/intentions in original protocol specification in order to make it simpler for sender developers to catch up. IMO "defensive" protocol parsing will go a long way to achieve that - and will ensure that any future extensions does not immediately render a sender unusable.

An issue for sender developers going forward is that ports may implement protocol extensions in different ways. IMO this should be avoided, possibly by having a separate project handling the protocol specification. A kind of standards body. And the protocol version should be well defined element in the $I output...

terjeio commented 3 years ago

Would it be possible for grblHAL to resend the boot string when it sees a connection? Does it know connection status?

Not generally possible for a UART connection (though some supports a hard reset via RTS and some via DTR), sometimes possible for USB and always possible for a network connection. If a MPG/DRO is in control then sending one is not good as the boot string implies a hard reset when received out of the blue.

HuubBuis commented 3 years ago

Arduino UNO usually reboots when connecting to the machine but the Teensy does not, so there is no boot string that lets UGS know what it has connected to. The only way to fix this is to disconnect/connect the USB cable.

Currently I use the build options ($I) to identify the connected grbl implementation. Couldn't grbl and clones use a unique number for uniform identification. A 32 bit hex, 16 bit for the the main version and 16 bit for sub versions. A git repository could be used to release the number for the main version and the developer can assign a sub version when appropriate.

breiler commented 3 years ago

Joacim, are you considering supporting an Ethernet connection? Telnet might not be too hard.

@phil-barrett We currently have support for connecting to TCP enabled devices, but I have never tried it myself. Also the feature is a bit hidden in the settings so it would need some UX attention to be useful: https://github.com/winder/Universal-G-Code-Sender/wiki/Connecting-the-Controller#smoothie--network

@terjeio thanks for the input of detecting the version of GRBL when connecting. I have some ideas on how to change this in UGS to allow for auto detecting different GRBL dialects and to load its implementations. But it will require some rework of the code to make this work.

HuubBuis commented 3 years ago

@phil-barrett We currently have support for connecting to TCP enabled devices, but I have never tried it myself. Also the feature is a bit hidden in the settings so it would need some UX attention to be useful: https://github.com/winder/Universal-G-Code-Sender/wiki/Connecting-the-Controller#smoothie--network

I have used this feature on grbl & mega controllers works OK. I am currently testing on grbl_ESP32.

HuubBuis commented 3 years ago

UGS build Universal Gcode Platform 202011193 is working (telnet bench tested) on grbl_ESP32 build 

[VER:1.3a.20201004:]
[OPT:VNMPHBSW]
[MSG:Using machine:ESP32_V4]

I get an error at startup, not sure the cause of it. This error is also reported by an older UGS build 04 2020.

ok
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0]
[Error] Error while processing response <ok>: An unexpected command was completed by the controller

I don't have telnet working on grblHAL ESP32 yet but it is on my todo list.

I also did a short bench test on grblHAL SAMD21 at compatibility level 0, no problems found yet.

breiler commented 3 years ago

I think that it would help to get a firmware variant from the $I-command, this would make things more simple to load a proper dialect implementation in the sender, eg: [FIRMWARE: grblHAL]

phil-barrett commented 3 years ago

This is a good idea. I would like to see compatibility level added to this. something like [FIRMWARE: grblHAL:1] If CLevel is 0, it could be left off so just [FIRMWARE: grblHAL] That would help debugging of problems related to sender variants.

terjeio commented 3 years ago

I think that it would help to get a firmware variant from the $I-command

A problem is compatibility with senders, not all are going to be updated, how to handle that? Fail early or fail late? Always report as "grbl"?

I can of course add [FIRMWARE: grblHAL], that would make it easier for me too. But adding that regardless of compatibility level may break senders. Catch 22? Add to the new $I+ command instead?

[COMPATIBILITY LEVEL:n] has already been added as a response to $I+. I am not sure senders needs this - IMO more relevant for support. Adding partial sender support according to compatibility level should be avoided - it is for backwards compatibility with senders not forward.

Not easy this...

terjeio commented 3 years ago

@breiler Am I loosing it? I have started writing a sender developers wiki page and while doing that I got back to the code and then I see that $I does not provide the neccessary information. I am sorry for that.

The way I detect grblHAL in my sender is to check for the presence off the $14 setting, not a good approach I know.

Perhaps a better way is to request the full real-time report request by sending 0x87 and wait a little for a reply? Legacy grbl does not respond to that and the character is filtered out from the input stream so it is safe to do so . If a reply is forthcoming one can be sure that it is not a legacy grbl controller one is communicating with.

The easiest way is of course to ignore the protocol specification and add the neccesary information to the $I response and tell users of senders that does not like that to update. What do you think?

BTW I have added [FIRMWARE: grblHAL] to the $I+ response (and $I response when compatibility level is 0) in the upcoming build.

breiler commented 3 years ago

@terjeio no worries 😄

I have discussed this with the Grbl_Esp32 team, and they suggested adding a [MSG:FIRMWARE:grblHAL] (or something like that) to the $I-command which would not break compability.

@MitchBradley had some ideas that he suggested he would write up in a specification. So you might want to wait on adding the [FIRMWARE: grblHAL] message so that we might get a unified way to do this?

terjeio commented 3 years ago

adding [MSG:...] ... to the $I-command which would not break compability.

Short of checking all senders this will not cut it. The specification for the $I response is that it is delimited by a ok at the end. Adding [MSG:...], or anything else for that matter, inside that response is IMO not in compliance with the spec and is logically wrong as well as push messages is something that is to be displayed for the user to see.

From the Wiki:

... These build info messages are followed by an ok to confirm the $I was executed, like this:

[VER:1.1d.20161014:]
[OPT:,15,128]
ok

A unified way to do this would be nice though - but please not by adding push messages to request responses...

MitchBradley commented 3 years ago

My first draft of a proposal addressing the identification issue is at https://github.com/bdring/Grbl_Esp32/wiki/Grbl-Version-Reporting---Proposal . Comments are solicited, either here, or I can create a specific ticket somewhere.

terjeio commented 3 years ago

@MitchBradley

When a new connection is established on an interface that is intended for use with the grbl serial protocol, the grbl controller shall issue a welcome message.

Not possible for a number of the processors/cards grblHAL supports. This means that getting the welcome message is not possible short of issuing a soft reset by ctrl-X.

To complicate matters many grblHAL drivers also supports my MPG extension where a secondary input only port is used when in MPG mode. The primary input port that a sender connects to is then inactive and any queries received will be discarded. A sender can (fairly reliably?) detect this mode by listening for real-time reports for a little while after connecting.

Perhaps a further complication is that my MPG implementation uses the welcome message to detect an external controller reset as this is AFAIKT the only way to reliably do so.

So IMO the welcome message is useless and cannot be used for identification.

I have added a new real-time report request character to grblHAL, 0x87, that could be used to detect an extended version of the protocol. I added this so my sender could get a complete status when required, this since some elements are only added to the report on a change. If a reply is received then an extended version of the $I report could be used for getting the neccesary details. I have added $I+ for that.

breiler commented 3 years ago

@MitchBradley thank you for your time writing up the spec!

@terjeio do you have a proposal for the specification of 0x87 and $I+? It could solve a lot of things by introducing a $I+ that would allow any [key:value] combination to be extended with in the future.

About the welcome message, could it be solved by adding a real time command for requesting a new one? This could be used if the sender wasn't greeted with one upon connection? The response could also only be sent on the channel that requested it (primary, secondary, network etc).

FYI I have invited Sonny Jeon to this thread, hopefully he will have some time to share his insights.