"ok" pops up consecutively in the console section

[VitaliiSadovshikov]

Description

Straight after the launching of the CNCjs in the console section consecutively appears "ok" word again and again, as though the CNCjs is sending some command consecutively. Thus I can't execute whatever in the CNCjs. The issue solely arise with macOS Monterey, meanwhile the same CNCjs version works properly on my old Macbook Pro with macOS Catalina.

Versions

• cncjs-app-1.10.1-macos-x64

How Do You Install CNCjs?

• NPM
• Download the CNCjs Desktop Application

CNC Controller

• Grbl
• Smoothieware
• TinyG/g2core

Hardware

• Raspberry Pi
• Desktop or Laptop
• Mobile Device

Operating System

• Not Applicable
• Windows
• Mac
• Linux

[cszatkowski]

I have a very similar issue. CNCjs v.1.10.3 running on native Windows 10 build.

Upon CNCjs software load the "Console" shows the GRBL initialization text.
....all is then quiet on the serial console's Western front...

However, if I ever later issue a GRBL (v1.1) "RESET" command the serial console is then flooded with the following every 10-seconds:

[GC:G0 G54 G17 G21 G90 G94 M5 M M9 T0 F0 S0]
ok

• Is there any way to stop this unrequested console communnication?

I also confirmed that if I connect directly serially to the same GRBL 1.1 controller using PuTTY, and I then issue the same GRBL "Soft RESET" command [Ctrl-X], PuTTY shows me the post-reset GRBL values setting BUT THEN REMAINS SILENT (as I would expect).

[cszatkowski]

Found an almost identical issue marked as "Closed":

• $G command spamming in desktop app - V1.10.1 $G command spamming in desktop app - V1.10.1  #805

It looks like the CNCjs code does intentionally send the repeated $G command every 10 seconds.

The issue is that CNCjs is supposed to receive, but then hide the returned response from the controller, but a bug in the code is still causing it to display. Note also (which made it even harder to troubleshoot), is that the CNCjs serial console also DOES NOT SHOW the G$ command issued by CNCjs.

[MitchBradley]

It sure would be nice if people filing bugs would tell us the controller/machine that CNCjs is talking to.

[MitchBradley]

The root cause of the problem is that the gcode report [GC:G0 G54 G17 G21 G90 G94 M5 M M9 T0 F0 S0] is malformed. The "M " without a number should not be there. Since that report is malformed, CNCjs cannot understand it. Instead of processing the report to set the status in the CNCjs UI, CNCjs just dumps it to the console.

The entity that generates the malformed report is the GRBL firmware that runs on the controller board. Since you did not tell us anything about the controller and its firmware version, we cannot tell you who to contact to fix the firmware.

[cszatkowski]

• I believe that you have nailed the issue.

I am seeing the second "M" field having no trailing numeric value.

This is on a Genmitsu 4040 Pro CNC which has a 32-bit controller with GRBL v.1.1f firmware loaded.

Maybe I can ask them for support on this issue.

[MitchBradley]

It must be a modified version of GRBL, because the GRBL 1.1f from the main repository at https://github.com/gnea/grbl/blob/bfb67f0c7963fe3ce4aaf8a97f9009ea5a8db36e/grbl/report.c#L312 does not output anything between "M5 " and "M9"

[cszatkowski]

Thanks.

There are so many Grbl forks, I have no idea.

Odd that different project forks would still report 1.1f on connecting...

Genmistu is using a GD32F103 processor manufactured by GigaDevice Semiconductor (Beijing).
This is a Chinese knock-off of the STM32 processor.

They could be using some form of FluidNC which was/is a grbl32 fork originally for the ESP-32 processor.
No idea exactly what code they are using and if they maintain it.

All of their forum support is on facebook and I don;t do facebook.

I can also check on a cheap 3018 CNC that I know is running a generic version of grbl 1.1f on a standard Mega-328p 8-bit CPU

[MitchBradley]

Odd that different project forks would still report 1.1f on connecting...

That is not surprising at all, considering that there is no standard for what grbl version numbers mean and how to manage them across different grbl variants. Some senders expect to see only specific historical grbl version numbers, so there is an incentive for people who do grbl variants to pretend that they are 1.1f or some other well-known version.

They could be using some form of FluidNC

I am one of the two primary developers of FluidNC and I can assure you that no version of FluidNC that I have ever seen runs on STM32. It might be grblHAL, but it is not FluidNC. FluidNC did have a different bug in GC: reporting, long since fixed, but it was not the M field that was the problem

All of their forum support is on facebook and I don;t do facebook.

Do not expect us to pick up the slack for your restrictions on which communication platforms you are willing to use.

[MitchBradley]

I tried to interest other grbl developers, most notably the author of grblHAL, in creating a standard way to report grbl version numbers, but he was not interested.