Unable to Validate Grbl Fork

[neilferreri]

What is the method for "validating protocol"? I tried to connect on a grbl based machine, the Carvey from Inventables, and receive an "unable to verify protocol".
The custom firmware originally caused an issue on CNCjs due to a custom "welcome message", but we worked to fix the issue with a change to the regular expression. I connect to the same machine routinely on CNCjs. Thanks.

[zaneclaes]

The Validating Protocol step should tell you a more specific reason underneath the Unable to validate protocol message. It should say either:

• (board not speaking at baud rate, or port is busy): meaning that no response was received from the board at all.
• Invalid response from board: subsequently prints all the lines it receives, indicating the invalid response.

I assume you're running into the latter. Could you paste the lines from this second message so I can see what's going on?

I didn't make any changes to the Grbl parser for the welcome message. I would expect the version to be emitted and detected as a valid confirmation of the protocol. Perhaps there are other differences with gCarvin, though.

[neilferreri]

Unable to validate protocol (board not speaking at baud rate, or port is busy) Request Protocol: Grbl At Baud Rate: 115200

So, it would seem that it's not connecting. The button changes to say "Disconnect", and I cannot connect via CNCjs until I disconnect with makerverse to free up the port.

[zaneclaes]

Strange. How did you install Makerverse? Have you tried looking at the server logs? They should give you a more specific reason (e.g., permissions error)...

If you used a web-server install, you can use docker logs makerverse.

[neilferreri]

Sorry, this is a Windows exe install.

[zaneclaes]

Well, assuming that the baud rate and ports are correct (which I don't doubt)... permissions are the most likely cause I can think of (i.e., installed the Electron app but perhaps Windows Defender is blocking access to the ports).

As a fallback, could you try this?

• Open the Arduino IDE
• Open the Serial Monitor for your board
• Run the two commands $$ and $I (to print board info)
• Paste all the output here so I can take a look

[neilferreri]

I have CNCjs installed on the same, Windows 10, machine and can connect without issue. I'm not by the machine right now, but I'll get you the $I soon. Why would the GRBL settings matter out of curiosity? The Carvey firmware does have a unique Spindle Current Threshold setting...they use $800.

[zaneclaes]

Why would the GRBL settings matter out of curiosity?

Settings shouldn't matter per se, but these are the two commands Makerverse runs during startup. In particular, I added the second one ($I) to query firmware version. Since I can't test Carvey myself, I'm going to use the data you give me to create a simulated test case for Carvey to see if I can recreate the issue.

[neilferreri]

[VER:2.0.0.20170522:CARVEY:R13:969-9510604:CTRL0] [OPT:VP]

And...

$0=10 (Step pulse time, microseconds) $1=255 (Step idle delay, milliseconds) $2=0 (Step pulse invert, mask) $3=0 (Step direction invert, mask) $4=0 (Invert step enable pin, boolean) $5=0 (Invert limit pins, boolean) $6=0 (Invert probe pin, boolean) $10=115 (Status report options, mask) $11=0.020 (Junction deviation, millimeters) $12=0.002 (Arc tolerance, millimeters) $13=0 (Report in inches, boolean) $20=0 (Soft limits enable, boolean) $21=0 (Hard limits enable, boolean) $22=1 (Homing cycle enable, boolean) $23=3 (Homing direction invert, mask) $24=25.000 (Homing locate feed rate, mm/min) $25=1500.000 (Homing search seek rate, mm/min) $26=250 (Homing switch debounce delay, milliseconds) $27=1.000 (Homing switch pull-off distance, millimeters) $30=12000 (Maximum spindle speed, RPM) $31=0 (Minimum spindle speed, RPM) $32=0 (Laser-mode enable, boolean) $100=88.889 (X-axis travel resolution, step/mm) $101=88.889 (Y-axis travel resolution, step/mm) $102=377.893 (Z-axis travel resolution, step/mm) $110=5000.000 (X-axis maximum rate, mm/min) $111=5000.000 (Y-axis maximum rate, mm/min) $112=600.000 (Z-axis maximum rate, mm/min) $120=500.000 (X-axis acceleration, mm/sec^2) $121=500.000 (Y-axis acceleration, mm/sec^2) $122=35.000 (Z-axis acceleration, mm/sec^2) $130=300.000 (X-axis maximum travel, millimeters) $131=203.200 (Y-axis maximum travel, millimeters) $132=80.000 (Z-axis maximum travel, millimeters) $800=1.750

Here's the welcome message: gCarvin 2.0.0 ['$' for help]

[zaneclaes]

Okay, well, I had a spare Arduino Mega laying around, which is what Carvey uses. So I installed their firmware:

Then I connected with Grbl:

Obviously, I can't do much with it since I don't have the rest of the machine.

At this point, I'm convinced that something is preventing Makerverse from having access to your machine. From what you've posted, Makerverse can't even get a single line of output from the port. I know that Windows Defender can cause things like this. Keep in mind, it's an unsigned application, so you have to make sure to give it the right permissions...

None of this has changed from CNCjs, though. I haven't touched how Makerverse connects to a machine or opens a port. And CNCjs was also an unsigned application...

[neilferreri]

Hey @zaneclaes, Sorry, I stopped pursuing this for a while. I am thinking this might be due to the hardware. The Carvey doesn't auto reset on Serial connection. I have to soft reset with CNCjs after connecting. I can't do that with Makerverse as it won't get past this step. Is there a way around that? Can Makerverse send a ^X on connection? I'd really like to try it out more. My other machine is in my cold garage, and I'd rather check everything out before I start fiddling with software out there.

[zaneclaes]

Hmm... maybe one of the events that you can configure from the settings?

FWIW, I've been hard at work on a huge, huge update. I've rewritten tens of thousands of lines of code already, and makerverse looks a lot different...

[neilferreri]

maybe one of the events that you can configure from the settings?

Makerverse does not allow moving past the connection screen. Any reason you don't just have the connection initiated from within the workspace, as has been with CNCjs?

I've been hard at work on a huge, huge update.

Looking forward to it!

[zaneclaes]

Makerverse does not allow moving past the connection screen.

On the left side, you should still be able to access the "Settings" tab. The screen you are describing is the "Home" screen. It is used to create a connection. Once the connection is created, then you create the workspace. From that point onward, you have a new tab for the workspace. You actually open the connection to the machine from the workspace tab.

Basically, the home screen = test connection & create workspace.

[neilferreri]

Right. But on the Carvey, I get stopped and can't get past the "Home" screen. It connects, but never gets a chance to validate because I need to send a soft reset.

[zaneclaes]

Yep. But you can nonetheless access the Events tabs in Settings, right? That was the point I meant to make. Thereby, perhaps you can issue a serial command, i.e., echo 'G0 X0 Y0\n' > /dev/ttyUSB0 (untested) ?

[neilferreri]

Thanks. Wouldn't the serial port be blocked by makerverse, though? I'll try that and just building the workspace via ~.makerverse

[zaneclaes]

Wouldn't the serial port be blocked by makerverse, though?

Not sure what you mean. Opening the serial port is the first step in connecting to any machine. So if it tries to connect at all, it opens a serial port (including when creating a workspace).

I'll try that and just building the workspace via ~.makerverse

I'm hoping this method lets you connect from the home screen, again, it should trigger the "open serial port" event I would expect (though not 100% sure).

[neilferreri]

Opening the serial port is the first step in connecting to any machine.

Yes, of course. But if I trigger an event to send a command to reset the machine ON SERIAL CONNECTION (which is what I think is needed to do it that way), the port wouldn't be able to be accessed by the system as Makerverse is already connected and using the port.

[zaneclaes]

the port wouldn't be able to be accessed by the system as Makerverse is already connected and using the port.

AFAIK, this is not a problem. You can run the command I pasted above while Makerverse has a port open (I just tested it again, to be sure, by echoing a command to my 3DP while the port was open by Makerverse). This simple shell script uses the raw serial buffer FIFO, rather than actually acquiring a lock over the resource.

[neilferreri]

I could not get that to work. It's most likely a combination of my (lack of) Windows command line experience and, possibly, permissions on my work PC. I tried variations of commands from here and here, using the correct COM port. Each time was met with something to the effect of "Access Denied".

I was able to connect, however, by manually creating a workspace for the machine. Doing that allowed me to open the connection and successfully control the machine.
I don't know that this issue is closed, but I was able to get around it.

[zaneclaes]

Windows command line

My fault. I just assume everyone is on Unix of some variety, based upon my background. I forget that most of this community is on Windows.

I was able to connect, however, by manually creating a workspace for the machine.

Great. Sorry you had the hassle.

I don't know that this issue is closed, but I was able to get around it.

I'll leave it open for now. Lots of stuff I'll need to return to with the rebuild, and this is a good reminder.