Issues with Universal-G-Code-Sender(UGS)

[physisisics]

I've been software testing this port of GRBL on the teensy3.1 . My hardware is disconnected at the moment and I've been using https://github.com/winder/Universal-G-Code-Sender because it's complete, interfaces nicely with GRBL and has a gcode visualizer. There are three issues that I've come across so far:

1. You know this already, but I want to make this information more accessible to anyone wishing to use your port of GRBL. Storing settings in eeprom/flexram is not currently working.

2. At the moment, I can send commands through the UGS terminal manually, but when I try to run a gcode file, I get a "GRBL is not initialized" error. This seems to be an issue with report_init_message(). The command is printPgmString(PSTR("\r\nGrbl " GRBL_VERSION " ['$' for help]\r\n")); and GRBL_VERSION is defined in "Settings.h". Perhaps the usb_serial is not initialized when report_init_message() is called? At what point is the usb_serial initialized?

3. Also, the real-time positioning readout isn't working. I haven't had time to investigate this yet.

[matthewSorensen]

1. Should be somewhat resolved - I was doing something wrong with the built-in checksum hardware, so I switched to the original software checksum. Haven't tested work-coordinates or startup lines.

2. and 3) are interesting. I suspect that UGS is reliant on the standard arduino behavior of establishing a serial connection resetting the device. UGS then sees GRBL's initialization line and figures out that it's talking to a fully initialized recent (0.8c or newer) verion of Grbl, and enables position readout and executing files. Relevant UGS commit.

In order to test this, I added a few lines of code to send a thousand status lines in the first 10 seconds after boot. If you establish the UGS serial connection during this window, it correctly detects Grbl and everything works. This approach is, of course, an extremely ugly hack.

I think this is definitely a problem, but am not sure which piece of software is to blame. This could be a bug in my control-x handling, but I'm 90% sure that it's just a consequence of the different serial-port semantics between the Teensy 3.x and Arduinos. UGS could implement the detection of hardware differently - for example, it could just attempt to read Grbl's position, and use the response to determine if real-time positioning readout works. Alternately, a command-line flag essentially telling it to just assume it has valid hardware connected could work...

[physisisics]

On one hand, I dislike the fact that GRBL/arduino resets on serial a connect because if something freezes and UGS needs to be restarted, I lose my current machine position. On the other hand, when you establish a serial connection, i think the default is to do a device reboot. As much as I recall, every USB serial device I've used tends to have a start-up type behavior when a connection is made.

I don't have time to look until tonight, but is there a command we can issue to get GRBL to do a system reboot? If not, perhaps I can add that and then call it from UGS. It seems like a much cleaner hack than repeatedly sending a start-up message.

[matthewSorensen]

I think the teensy's behavior of not resetting when a serial connection is opened is appropriate for the application, and I'm not really interested in trying to emulate the reset.

This is the point of control-X (0x18) - resets the motion control etc. UGS sends a control-x right after connecting, but modifying the control-x handler to also print an initialization message doesn't seem to impact UGS's detection behavior.

[physisisics]

Thanks. I'll look into control-X tonight and see if I can trace down why the init message isn't being received/interpreted by UGS.

Not resetting on serial connect does seem like the better option if there are plans to add additional interfaces to GRBL; For example: if you do a direct read of gcode from an sd card and you don't want the machine to reset if it is connected or disconnected to usb. However, since (at the present) the only interface is through the serial port, I disagree. The only means to communicate feed holds etc. to GRBL is through usb serial. If that cable becomes disconnected, or the connection is disrupted, it seems an automatic halt is in order, no?

Now that I think about it, perhaps GRBL and the host program should have a handshaking-type connection where GRBL pings the host every so often and initiates a feed hold when there is no response (it already almost does this with real-time positioning). When the connection is lost and reestablished, the host then responds and GRBL passes it's start-up line to the host and the cycle resumes. Of course, this feature would not work on an avr GRBL without a modification of the bootloader (or perhaps usb-serial hardware) to not reset on reconnect.

PS. I just want to have a discussion on the best way to implement GRBL and if I'm annoying you or overstepping my bounds, please say so. I know you have your own direction for where you want to take this project and we are all limited on the amount of time we can spend on this.

[matthewSorensen]

Actually, Grbl does have some IO pins for feed holds and such, but yes, USB serial is definitely the essential interface.

Loosing physical connectivity should definitely stop motion and put the device into an error condition. I haven't tested what happens when the USB cable is removed and the teensy is on an independent power source. What I'm not sure about is the correct behavior when Grbl is connected to the host computer and a program opens the device file or com-port - right now, Grbl keeps running. Being able to deal with crashy host programs is definitely a good thing, but this does make interfacing with UGS trickier.

perhaps GRBL and the host program should have a handshaking-type connection

A binary protocol designed for non-interactive use would be great, and would probably improve move throughput and position read-out latency. This would require serious work on the host side, and pigeon-holing k20-grbl into a specific host might be counterproductive for encouraging adoption. This is the sort of radical change I'm not particularly interesting in making in the near-term, but would love to discuss for future work.

I just want to have a discussion on the best way to implement GRBL and if I'm annoying you or overstepping my bounds, please say so. I know you have your own direction for where you want to take this project and we are all limited on the amount of time we can spend on this.

No, go ahead - at this point, any attention that Grbl on the teensy 3.1 gets is good! If you have problems or suggestions, go ahead and file bug reports or write wiki pages. Right now my plans are rather conservative. In the short term, I'd like to fully test k20-grbl on real hardware, clean up parts of the code, and update the documentation. Grbl's strength is that it's really clean, well-documented, and values correctness over a massive feature set. Attempting to match,or surpass that level of quality is probably the best course of action for the DIY CNC community. Of course, this port opens the door to lots of exciting new features, as the K20s have tons of cycles, io, and code-space to spare. I think we could easily implement 6-axis control, as well as all of the advanced peripheral interfaces people keeping trying to implement. Once I'm happy with the stability and quality of the port, I plan a fork that implements a giant list of interesting features.

[physisisics]

I will do. I'm just curious, do you plan on porting GRBL Edge V0.9a after the initial testing of this port? 0.9a has independent x,y,z-axis speed/acceleration management. It's what I've been using on my gantry style cnc and it has been excellent. It seems that if you are planning on moving to a 4-6 axis machine, these features would be a necessity.

[matthewSorensen]

Ya, I really should have just started with 0.9a... I need to review the new algorithms in stepper.c, but I think most of should be as easy to get working as 0.8 was. In this situation, the resource constraints of the 328 are in our favor, as the code doesn't need to be quite as clever or optimized.

[physisisics]

For anyone who is interested, here is my hack to get UGS to work with teensy GRBL: At the beginning of the function report_grbl_help(), I placed a call to report_init_message(). Then, when I start UGS, I simply type $ in the command line and UGS initializes. As far as I have tested, this makes UGS fully functional with teensy GRBL.

[matthewSorensen]

Is this a modification that is worth making? I can't think of any downsides to reporting the version when reporting the help message...

[physisisics]

I don't see any downside to this per se, it's just not particularly well organized. The initialization message says "$ for help", but you don't get that information until you enter $.