Communication problem with 1.9.0-RC1 and 1.9.0-RC2

[mayhem2408]

I have been using cncjs V1.8.14 on my Raspberry pi without any problems. I thought I'd try V1.9.0 RC on my Windows PC and found a problems connecting to my GRBL-Mega V1.1e. I can select the port and baud rate is correct, but when I connect, it says it is connected by nothing works. The Status Reports, Modal Groups and Queue Reports are all blank. If I try to execute a command or jog, nothing happens. If I load a gcode program and run it, it starts, but stops after a few lines have been sent.

So I rolled back to V1.8.14 on my Windows PC and found everything is working correctly. Status Reports, Modal Groups and Queue Reports and all showing the correct data and I can see the serial buffer bouncing around a little as status messages are being sent.

I went back to V1.9.0 RC2 and the same problem. I also have the same problem with V1.9.0 RC1. So it seems my Board is working with V1.8.14 on Windows and my Raspberry Pi, but not on V1.9.0 RC1 or RC2 on Windows. I will try V1.9.0 RC2 on my Raspberry pi soon, but want to backup my existing working setup before I try it.

Is anyone else seeing a problem like this?

[cheton]

Related to #150

[cheton]

Fixed by 7e10f4b in 1.9.0-rc.3

Bad (w/ Node.js v4 or earlier versions)

const re = new RegExp(/\[[^\]]+\]/, 'g');		

Good (all Node.js versions)

const re = new RegExp(/\[[^\]]+\]/g);

[cheton]

Please let me know if 1.9.0-rc.3 works for you.

[mayhem2408]

Just installed RC3 for Windows 64bit. Didn't fix the problem.

[cheton]

Just installed cncjs-1.9.0-rc.3-win-x64.exe, but I cannot reproduce this issue. You can see my screenshot below:

If possible, could you press Ctrl + Shift + I to Toggle Developer Tool, and check if there are any error messages logged to the console? Thank you.

[mayhem2408]

@cheton Here are some screen shots for you.

V1.9.0-RC3 is showing errors

And V1.8.14 on the same PC with the same GRBL board is not showing any errors and works OK.

[cheton]

The last two errors DeprecationWarning: Calling an asynchronous ... should be fine, it will not block further code execution, I just fixed it in 6804c95.

For the first two errors, it shows that your workspace settings was corrupted. I tried to corrupt my file in C:\Users\<Username>\AppData\Roaming\cncjs\cnc.json, and now I'm able to get the same error message:

You can go to Settings > Workspace to restore to defaults, then the first two errors should disappear. I will add more sanity checks to eliminate these errors.

However, I can continue to use the web interface after encountering these errors, but your installed version of 1.9.0-rc.3 didn't have Grbl initialized correctly. It should show the welcome message as below:

Grbl 1.1f ['$' for help]

Have you ever tried disconnecting the USB cable and then connect it again? In some rare cases, I may encounter the issue that Grbl won't response after connection established, but disconnect USB cable and then connect it again will resolve this issue.

[mayhem2408]

When I connect, I do not see and responces in the command console. There are no prolems with responsed from V1.8.14 or PuTTY.

Installed V1.9.0-rc4. Getting an internal error now. It does not load the GUI.

[mayhem2408]

@cheton I also noticed the file download size dropped significantly with rc4. rc3 was 37.3Mb, rc4 is 34.7Mb. Is something missing from rc4?

[mayhem2408]

@cheton As you can see from the screen shots, V1.8.14 command console is responding OK, but V1.9.0 rc3 is not.

[cheton]

@cheton I also noticed the file download size dropped significantly with rc4. rc3 was 37.3Mb, rc4 is 34.7Mb. Is something missing from rc4?

Oops. I updated a 3rd-party dependency "delay" to its latest version (v1.3.1 -> v2.0) in 1.9.0-rc.4, but delay@2.0 seems to be broken, and unfortunately it didn't fail the build:
https://ci.appveyor.com/project/cheton/cncjs/build/199-dev#L5962

I will rollback this change and submit a new build to fix this issue for 1.9.0-rc.4.
sindresorhus/delay#17 (comment)

---

Otherwise, I installed 1.9.0-rc.3 (win-x64) on another Windows machine, and it can connect to Grbl without problems. A major difference between 1.8 and 1.9 is the installed program path:
1.8
C:\Users\<Username>\AppData\Local\Programs\cnc\cnc.exe
1.9
C:\Users\<Username>\AppData\Local\Programs\cncjs\cncjs.exe

This issue might be affected to Electron app only, I will try to find a way to dump console logs from a running Electron app to check if there are error reported from the node.js server.

[cheton]

@mayhem2408

Could you try launching the program from command line to check console output? You'll see server logs as shown below:

Note. Launching program from command line on Windows may show "Error: Can't set headers after they are sent.", but it seems not a problem because I also got the same error messages with v1.8.14.

[mayhem2408]

@cheton I've attached some screen shots, but did notice once interesting thing. I started cncjs.exe from the command prompt and took a screen shot. Then pressed the Open button, but nothing happened in the cmd window, so I pressed the closed button and in the cmd window got an error that the com port was already closed. so it appears the com port wasn't open even though the GUI indicated it was. So I tried open and close again, and again got an error that the com port was not open.

After pressing the close button.

[mayhem2408]

@cheton The error in the cmd windows in V1.9.0-rc may not be relevant as I am seeing the same results in V1.8.14 even though it works.

[cheton]

I found a way to troubleshoot Electron app:

1. Go to https://github.com/electron/electron/releases, and download electron-v1.6.4-win32-x64.zip for Windows x64 platform.
2. Extract the ZIP file to a temporary folder. For example, C:\Temp\electron-v1.6.4-win32-x64\
3. Go to C:\Users\Username\AppData\Local\Programs\cncjs\resources\app\
4. Run C:\Temp\electron-v.6.4-win32-x64\electron.exe main.js -vvv, then you will be able to see verbose output with -vvv.

[cheton]

Update: Electron v1.6.4 is a beta release for running an upgraded version of Chrome, the stable release is https://github.com/electron/electron/releases/tag/v1.3.14

[mayhem2408]

@cheton I have run cncjs via electron and here are two screenshots. The first is the initial startup and the connection has been established. The second is after a ? command has been sent from the console.

[cheton]

Thank you for providing this. Will it go back to normal after clicking the Reset button on the navigation bar? It looks probably a serial communication issue especially when running Electron app for Windows, but not always reproducible on other Windows machines.

I listed all version changes of electron and electron-builder between cncjs 1.8.14 and 1.9.0-rc.5:

cncjs	electron	electron-builder
1.8.14	~1.4.14	~11.2.4
1.8.15	~1.4.14	~11.2.4
1.8.16	~1.4.14	~11.2.4
1.8.17	~1.4.14	~11.2.4
1.9.0-alpha	~1.4.14	~12.2.0
1.9.0-alpha.1	~1.4.14	~13.5.0
1.9.0-alpha.2	~1.4.14	~13.5.0
1.9.0-alpha.3	~1.4.14	~13.5.0
1.9.0-alpha.4	~1.4.15	~14.5.1
1.9.0-alpha.5	~1.6.2	~15.1.1
1.9.0-beta	~1.6.2	~15.4.2
1.9.0-beta.1	~1.6.2	~15.5.1
1.9.0-rc	~1.6.2	~15.6.2
1.9.0-rc.1	~1.6.2	~15.6.2
1.9.0-rc.2	~1.6.2	~16.0.1
1.9.0-rc.3	~1.6.2	~16.0.1
1.9.0-rc.4	~1.6.2	~16.3.0
1.9.0-rc.5	~1.6.2	~16.3.0

A major change is that I started to use Electron 1.6.2 since cncjs-1.9.0-alpha.5. I just realized that Electron 1.6.2 is running an upgraded Chrome and may have some instability.

If you can run well with v1.9.0-alpha.4, but no luck with 1.9.0-alpha.5, it should be probably caused by an upgraded Electron version.

https://github.com/cncjs/cncjs/releases/tag/v1.9.0-alpha.4

Otherwise, I will try to rollback Electron to 1.4.15 (stable release) and provide a new release later.

[mayhem2408]

Pressing the reset button on the navigation bar did not change anything. I can see in the console that a special character was sent, but no response. I am downloading 1.9.0 Aplha 4 now and will let you know how it goes.

[mayhem2408]

@cheton Just install V1.9.0 Alpha 4 and it is working fine as you can see from the screen shot.

[cheton]

Wow. That's great news! I will publish a new release soon.

[cheton]

1.9.0-rc.6 is ready to download
https://github.com/cncjs/cncjs/releases/tag/1.9.0-rc.6

[mayhem2408]

@cheton Interesting.. The roll back of electron didn't fix it. I am going install each release from Alpha 4 and see exactly when it stops working.

[mayhem2408]

@cheton This is really weird. I can't get Alpha 4 to work now. I'm going all the way back to 1.8.14 and work up from there.

[cheton]

Thank you for all your assistance. Hope this won't take up too much of your time,

[mayhem2408]

@cheton Just installed Alpha 3 and it worked. Reinstalled alpha 4 and its not working. Went back to alpha 3 and it worke again. Up to alpha 4 and I can't get it to work. I'm not work what made alpha 4 work before.

[cheton]

@mayhem2408,

Okay. I will create a separate dev-151-electron branch and downgrade electron-builder as well. I will let you know when it's done.

[cheton]

See https://github.com/cncjs/cncjs/releases/tag/dev-151-electron-latest

There were two files created by AppVeyor CI. The first link is the downgraded version of electron-builder, which is pretty similiar to 1.9.0-alpha.3. The second link the exactly the same thing as 1.9.0-rc.6.

• cncjs-1.9.0-dev-151-latest-5822dd19-win-x64_electron-1.4.15_electron-builder-13.5.0.exe

  • Similar to 1.9.0-alpha.3
  • electron 1.4.15
  • electron-builder 13.5.0

• cncjs-1.9.0-win-x64_electron-1.4.15_electron-builder-16.3.0.exe

  • Same as 1.9.0-rc.6
  • electron 1.4.15
  • electron-builder 16.3.0

My screenshot for first download link cncjs-1.9.0-dev-151-latest-5822dd19:

My screenshot for second download link cncjs-1.9.0-latest-caa256e3:

[mayhem2408]

I have something and will look back a previous version now, but with both versions above it did not work at first but this is the procedure I followed on both and it worked.
1/ I launched dev-151
2/ I connected the by grbl board. No response in the console
3/ I pressed the reset reset button in the nav bar. The console shows that something was send ">", but no response
4/ I pressed "?" and again the console shows that "?" was sent, but no response.
5/ I pressed "#" and again the console shows that "#" was send, nit again no response.
6/ I pressed the physical reset button on the Arduino board. I got the Grbl welcome response.
From where everything works normally.

I retested by pressing the close button. Pressed Open and got no response, pressed the reset button on the Arduino board and it came to life.

I repeated this with dev-151 5 times and repeatedly got the same result.

This is not something I have to do in V1.8.x.

I tried cncjs-1.9.0-win-x64_electron-1.4.15_electron-builder-16.3.0.exe and got the same results.

I and going to installed Alpha 3 again and make sure it worked, then install alpha 4 and see if the above steps works. Give me 15 minutes.

[mayhem2408]

@cheton 1.9.0-Alpha3 connects and I get the grbl welcome message without having to press the reset button on the Arduino. However I did notice the grbl welcome message takes about 7 seconds to appear. If I press the Arduino reset button again, the welcome message appears almost instantly.

1.9.0-Alpha4 connects, but after 30 seconds still no grbl welcome message in the console. I pressed the Arduino reset button and instantly the welcome message appears and everything is working.

Now to 1.9.0-RC6, the same result as 1.9.0-Alpha4. I have the press the Arduino reset button to get it to work.

I have repeated these tests 3 times and set the same result.

[mayhem2408]

@cheton Just went back to 1.9.0-rc3 and the same result. I have the press the Arduino reset button to get the grbl welcome message, and after that it works OK.
Did anything change between alpha 3 and alpha 4 as far a initializing the grbl board?

[cheton]

There is one change between 1.9.0-alpha.3 and 1.9.0-alpha.4. I added a mechanism to check if status (?) and parser state ($G) query has not been updated for a long time, it will automatically send ? and $G after waiting for a certain period if it didn't get response from Grbl.

1.9.0-alpha.3
https://github.com/cncjs/cncjs/blob/v1.9.0-alpha.3/src/app/controllers/Grbl/GrblController.js#L314

1.9.0-alpha.4
https://github.com/cncjs/cncjs/blob/v1.9.0-alpha.4/src/app/controllers/Grbl/GrblController.js#L318

I looked back to your logs, this was activated by 5~6 seconds after connecting to Grbl, so I didn't think this issue might be related to the change.

2017-03-27T20:57:21.677Z  [Grbl] Connected to serial port "COM10"
2017-03-27T20:57:27.246Z  [Grbl] Continue status report query: timespan=5050ms
2017-03-27T20:57:32.324Z  [Grbl] Continue parser state query: timespan=10128ms

Your screenshot:

Otherwise, I didn't find any significant change to the Grbl controller regarding serial communication part. I think this should have no problems on RPi, you can try npm installation later once you have time.

Sorry for that currently I don't have any ideas on that. Do you have any other Windows, Mac, or Arduino boards other than Arduino Mega for testing? Use a shielded USB cable might be worth a try (see #133 (comment)). If your Arduino wasn't re-flashed with the latest firmware, you can try https://github.com/grbl/grbl/wiki/Known-Bugs#usb-to-serial-transmission-errors, and check if it can resolve your problems.

[mayhem2408]

@cheton I haven't experienced any serial transmission problems in the past and I have sent some very large files. You will probably recall I raised the issue with large files on the Raspberry Pi which is now working perfectly.

I have installed V1.9.0 and still experiencing the same problem, I have to press the reset button on the Arduino before it starts working.
I have flashed grbl V1.1f onto an UNO and it works fine without a reset having to be pressed. I swapped straight out to my mega and it is still having the problems.

I downgraded back to Alpha 3, and I have no problems with either the UNO or the MEGA board.
I then upgraded to Alpha 4 and the problem resurfaces.

There must be some small change in Alpha 4 that is affecting this. It's easy enough to work around, but still something to look into.

I have also check and both my UNO and my MEGA and running the same CH340 USB/Serial chip.

[cheton]

Good news! I got an Arduino MEGA and flashed with https://github.com/gnea/grbl-Mega, now I can reproduce this issue. It took me about 7~10 seconds to see the welcome message with Alpha 3, but nothing returned since Alpha 4, unless I press the hardware reset button. I will try to find out what went wrong.

[cheton]

Got some results after several tries. When connecting to Grbl Mega from the web interface, both 1.8.14 and 1.9.0-alpha.3 will wait for a certain amount of time (e.g. 6~10 seconds) before you can see Grbl welcome message. Is it right?

If I continuously send '?' or '$G' commands from the Console widget within the period, I won't be able to see the welcome message, unless I stop sending commands and then wait for another 6 to 10 seconds. This should explain why it didn't work with Alpha 4, because it will send '?' and '$G' in a 5 and 10 seconds interval if not getting response from Grbl. I can use a quick workaround by not sending commands unless the first Grbl welcome message has arrived.

I just tried a terminal tool provided by the node-serialport library, and I can see the Grbl welcome message within 1 second. There should be something wrong with my implementation. I will take a look into it later.

[cheton]

Just figured out the difference between Grbl and Grbl-Mega.

In the initController function, it set the "ready" flag with a delay of 500ms right after a serial connection is established. For example:

setTimeout(() => {
    this.ready = true;
}, 500);

Once the "ready" flag is set to true, the controller will continuously send ? and $G commands to query Grbl status report and parser state at regular intervals (e.g. 250ms and 500ms).

However, the Grbl startup message might delay around 900ms after establishing a serial connection. If I repeatedly sending status query (?) at a 250ms interval before the start up message, it will take block about 9 seconds long for Grbl Mega (Mega 2560) to display. For Grbl (Uno/Nano), it only takes about 1.5 seconds. You can check the differences below:

Grbl (Uno and Nano)

2017-03-30T09:20:22.953Z - debug: [Grbl] Connected to serial port "/dev/cu.usbmodemFA131"
2017-03-30T09:20:23.191Z - silly: Query status report (?)
2017-03-30T09:20:23.446Z - silly: Query status report (?)
2017-03-30T09:20:23.698Z - silly: Query status report (?)
2017-03-30T09:20:23.950Z - silly: Query status report (?)
2017-03-30T09:20:24.202Z - silly: Query status report (?)
2017-03-30T09:20:24.454Z - silly: Query status report (?)
2017-03-30T09:20:24.536Z - silly: [Grbl] <
2017-03-30T09:20:24.543Z - silly: [Grbl] < Grbl 1.1f ['$' for help]
2017-03-30T09:20:24.710Z - silly: Query status report (?)
2017-03-30T09:20:24.724Z - silly: [Grbl] < <Idle|MPos:0.000,0.000,0.000|FS:0,0|WCO:0.000,0.000,0.000>
2017-03-30T09:20:24.967Z - silly: Query status report (?)
2017-03-30T09:20:24.977Z - silly: [Grbl] < <Idle|MPos:0.000,0.000,0.000|FS:0,0|Ov:100,100,100>
2017-03-30T09:20:25.223Z - silly: Query status report (?)

Grbl Mega (Mega 2560)

2017-03-30T09:14:22.550Z - debug: [Grbl] Connected to serial port "/dev/cu.usbmodemFA131"
2017-03-30T09:14:22.792Z - silly: Query status report (?)
2017-03-30T09:14:23.050Z - silly: Query status report (?)
2017-03-30T09:14:23.303Z - silly: Query status report (?)
2017-03-30T09:14:23.558Z - silly: Query status report (?)
2017-03-30T09:14:23.810Z - silly: Query status report (?)
2017-03-30T09:14:24.063Z - silly: Query status report (?)
2017-03-30T09:14:24.314Z - silly: Query status report (?)
2017-03-30T09:14:24.566Z - silly: Query status report (?)
2017-03-30T09:14:24.819Z - silly: Query status report (?)
2017-03-30T09:14:25.076Z - silly: Query status report (?)
2017-03-30T09:14:25.332Z - silly: Query status report (?)
2017-03-30T09:14:25.589Z - silly: Query status report (?)
2017-03-30T09:14:25.845Z - silly: Query status report (?)
2017-03-30T09:14:26.101Z - silly: Query status report (?)
2017-03-30T09:14:26.356Z - silly: Query status report (?)
2017-03-30T09:14:26.609Z - silly: Query status report (?)
2017-03-30T09:14:26.860Z - silly: Query status report (?)
2017-03-30T09:14:27.114Z - silly: Query status report (?)
2017-03-30T09:14:27.370Z - silly: Query status report (?)
2017-03-30T09:14:27.626Z - silly: Query status report (?)
2017-03-30T09:14:27.881Z - silly: Query status report (?)
2017-03-30T09:14:28.136Z - silly: Query status report (?)
2017-03-30T09:14:28.389Z - silly: Query status report (?)
2017-03-30T09:14:28.640Z - silly: Query status report (?)
2017-03-30T09:14:28.893Z - silly: Query status report (?)
2017-03-30T09:14:29.145Z - silly: Query status report (?)
2017-03-30T09:14:29.396Z - silly: Query status report (?)
2017-03-30T09:14:29.649Z - silly: Query status report (?)
2017-03-30T09:14:29.903Z - silly: Query status report (?)
2017-03-30T09:14:30.159Z - silly: Query status report (?)
2017-03-30T09:14:30.411Z - silly: Query status report (?)
2017-03-30T09:14:30.662Z - silly: Query status report (?)
2017-03-30T09:14:30.915Z - silly: Query status report (?)
2017-03-30T09:14:31.169Z - silly: Query status report (?)
2017-03-30T09:14:31.426Z - silly: Query status report (?)
2017-03-30T09:14:31.681Z - silly: Query status report (?)
2017-03-30T09:14:31.820Z - silly: [Grbl] <
2017-03-30T09:14:31.826Z - silly: [Grbl] < Grbl 1.1e ['$' for help]
2017-03-30T09:14:31.937Z - silly: Query status report (?)
2017-03-30T09:14:31.948Z - silly: [Grbl] < <Idle|MPos:0.000,0.000,0.000|FS:0,0|WCO:0.000,0.000,0.000>
2017-03-30T09:14:32.189Z - silly: Query status report (?)
2017-03-30T09:14:32.199Z - silly: [Grbl] < <Idle|MPos:0.000,0.000,0.000|FS:0,0|Ov:100,100,100>

[mayhem2408]

@cheton I can reproduce your results with 1.8.14. If I keep sending '?' before the welcome, the welcome never appears, until I stop for about 7 seconds. I think the mega bootloader might be slower than the uno bootloader and it is reseting when it received the command, which is not a valid bootloader command, so it never starts the grbl firmware. However, the bootloader senses when reset via the reset button and starts the grbl firmware immediately without waiting.

[cheton]

Hi @chamnit

In my current implementation, it will send status query (?) to Grbl at a 250ms time interval right after a serial connection has established, although the Grbl start up message might appear later with a 900ms delay.

From my testing, these repeated commands will not cause problems to Grbl, but it did block Grbl-Mega to display start up message with a certain amount of time (e.g. 9 seconds or more). Is it related to the bootloader of an Arduino Mega 2560? Thanks!

[cheton]

@mayhem2408

I can confirm that it's fixed in e24a44c, I will inform you when a new build is ready.
Thank you for your support and patience.

[chamnit]

@cheton : Not sure what's causing a delay of 9 seconds or more. The arduino boot loader is usually no more than two or three seconds.

[mayhem2408]

@cheton I have installed V1.9.1 and tested it a dozen times. Worked flawlessly everything. Thanks for your persistence with this problem. It looks like your solved it.

[cheton]

Once a serial connection has established, a gcode sender should wait the bootloader to complete before sending any status query commands. Giving 1 second for Smoothie and TinyG boards seems to be enough. For Grbl running on an Arduino board, I modified the code to wait until a Grbl start up message has received. It should resolve the timing issue in 1.9.0 and all earlier versions.