$ command extentions

[J-Dunn]

Oicking up a suggestion I made on the main GRBL git. https://github.com/grbl/grbl/issues/980#issuecomment-215768016

I have been using GRBL with L6474 driver boards ( Arduino pin-out ) , which require some additional set-up parameters since they are a lot more configurable than the typical STEP/DIR boards commonly used.

The boards use classic STEP/DIR pins but the rest goes through a SPI daisychain including ENABLE / DISABLE.

There's a bunch of parameters like slew-rate etc that can be set but the main difference is programmable current setting; a hardware error FLAG and status byte which needs to be read to clear the error.

I have added a few $ commands to the GRBL interpreter to set and interrogate the various parameters and an interrupt to respond to error pin input. The most common error conditions are over-temperture warning, over-temperture error ( hard fault ) and supply under-voltage condition.

I am going to be tidying this up a bit now and wondered whether there are any guidelines for extending GRBL's interpreter so that I can avoid clashes with future work any maybe provide something of more general use.

As an example I have commands like the following to set chip parameters for each board: $P[board_id]:[param_id]=[param_value]

Boards are becoming more configurable and this sort of situation will start becoming more common. If there is not any defined way of extending the current code set, it may be good think about providing one.

The primary requirement will obviously be to avoid clashes with any NIST GCODES and anything that may be tentatively in the making for additional GRBL commands.

[J-Dunn]

what I have put together is specific to the needs of the L6474 chip. Though this is probably fairly typical of SPI configurable h/w that is becoming more common.

The STM L6474 devices can be daisy-chained and a series of commands sent to any combination of the driver boards in the chain. Typical communications involve either setting or reading chip parameters. These commands can be 1 ,2 or 3 bytes long. There is also a h/w interrupt line that needs servicing.

Valid Non-Command Words: F, I, J, K, L, N, P, R, S, T, X, Y, Z

Hooking some new functions into the existing command structure is fairly simple. I tucked it in under $# parsing: case '#' : // Print Grbl NGC parameters

I used S to query status bytes of any/all chips.

       case 'S' : // get L6474 status
       case 'L' : // send L6474 command
       case 'P' : // getL6474 param
       case 'Z' : // get L6474 status without clearing error

Sending commands is used to enable / disable the chip , there is no input pin for this.
There is a non destructive status read and similar one which is used to also clear the error condition.

I also took advantage of what looks like a free bit in the exec bit map. #define EXEC_DRIVER_ERR bit(7) // crit error on one or more L6474 cards. This is just an example of the sort of things that need to be catered for in this kind of context.

While there are plenty of spare letters, may be it is a bit wasteful to eat up four of them, though this was easiest to hack into the existing code structure. Maybe these could be a two letter code?

On the three card test system, I used a card_id from 1..3 and zero to indicate all cards get the same ( eg. ENABLE ) . Even on a Uno this can be quite fast. I got reading the status bytes of all three cards down to about 19us of SPI comms, plus the time needed to get in and out of the ISR . It is fastest to just block the processor while all this happens rather than using interrupts.

That is the minimum interaction which is needed to differentiate between a non-critical error ( temp warning ) and a chip shut down error like over-temp or under-voltage, both of which can trigger a h/w signal on FLAG pin.

This gives the attractive possibility to respond to a temp warning with a controlled stop that does not lose position. Other conditions need to be treated like a limit switch tripping since at least one drive will be in shut down.

[chamnit]

@J-Dunn : One brief comment. Anything after a '$' is not sent to the g-code parser. So anything goes, as long there is nothing in the message that contains a real-time command character. The '$' is good way to keep Grbl system level commands and functions completely separate from the g-code.

[J-Dunn]

What is the list of these chars to be avoided? Are you referring to ! and ~ ?

I did this on Arduino just to get familiar with the code base. I'm now moving it to stm32. That will take off the shackles and allow some more interesting possibilities.

[chamnit]

@J-Dunn : Yes. The fact that there is a lot of flash space on the Mega means we don't have to necessarily need to try to fit these new commands into the existing one. It's possible to add a new parser for system commands. Although, I do prefer to keep things very concise and somewhat human-readable when possible. This keeps the comm traffic to a minimum and is easier to learn.

[J-Dunn]

OK, so there's no particular objection to the way I've implemented this and it does not clash with any existing plans for future work. That was the point I wanted to check by bringing this up. Thanks.

[J-Dunn]

A word of advice, please.

using L6474 driver chips there are critical errors like thermal shut down where the driver goes into its HiZ state and position is lost. I flag this by calling :

mc_reset(); // Initiate system kill.
system_set_exec_alarm_flag( ( EXEC_CRITICAL_EVENT | EXEC_ALARM_STEPPER_FAIL)); 

There are also non-critical errors like an invalid parameter setting was sent via SPI, or thermal warning condition.

In the case of thermal warming, I'd like to bring the machine to a controlled stop without losing position. Is it sufficient to set the exec_state?

system_set_exec_state_flag( EXEC_FEED_HOLD); // do soft-stop;

Thanks.

[chamnit]

@J-Dunn : Probably, but not sure. The alarm system wasn't designed to account for a feed hold to prevent position loss. However, the soft-limit system was. I would look at the soft limit alarm handling in motion_control.c and the cycle stop routine in protocol.c to see how its done.

[J-Dunn]

OK, thanks f or that suggestion.

It seems that hard and soft stops end up needing a reset as the code stands.

    // Halt everything upon a critical event flag. Currently hard and soft limits flag this.
    if (rt_exec & EXEC_CRITICAL_EVENT) {
      report_feedback_message(MESSAGE_CRITICAL_EVENT);
      system_clear_exec_state_flag(EXEC_RESET); // Disable any existing reset
      do {       
        // Block everything, except reset and status reports, until user issues reset or power 
        // cycles. Hard limits typically occur while unattended or not paying attention. Gives 
        // the user and a GUI time to do what is needed before resetting, like killing the
        // incoming stream. The same could be said about soft limits. While the position is not 
        // lost, streaming could cause a serious crash if it continues afterwards.

"The same could be said about soft limits. " I don't quite see the problem here. Maybe I'm missing the point. Current speed is zero and presumably once the input buffer is full the host will have stopped sending GCODE. If the hold condition is removed the planner will calculate a new path up to the current max move or cutting speed. What is this warning related to? How could streaming cause a crash, unless the host is not responding correctly to a buffer full situation , in which case it could cause a crash under normal running conditions.

There seems to be something that I'm not anticipating here. What is the problem that this comment is warning against?

Thx.

[chamnit]

@J-Dunn : Streaming can cause a crash if the GUI is over-stuffing the serial RX buffer in particular. The GUI can also forget to handle an alarm state (or g-code error) correctly and keep streaming. It's common. This enforces an acknowledgement by a GUI developer.

[J-Dunn]

Thanks, so this is to take care of bugs in Gcode senders which keep spewing output that is not being accepted. I've seen this kind of issue on other GCODE interpreters too.

What is the fundamental problem here? Is it a lack of hardware handshaking when using USB, short-comings in Windows VCOM drivers, or simply host software which is not well designed and not taking any account of handshaking?

I've read that software handshaking is not really effective since XOFF often, itself, gets held up and does not get the message through in time to be effective.

The only strategy that I recall seeing that was reckoned to work was host sofware counting lines out and "ok" lines back and keeping a tally.

This is a bit of side issue w.r.t. soft limits but it's good that it has come up since it is something that needs attention and was on my TODO list. I've stared breadboarding an STM32 system with a MAX3232 to provide true RS232 I/O , mainly for this reason.

What is your perception of the root cause here?

thanks.

[chamnit]

@J-Dunn : I'm not quite sure what you are asking, when the question seems to be answered and acknowledged by your post. Anyhow in my experience, there are all sorts of GUIs/senders, written in all types of programming languages. Some threaded and not well timed. Some not following the interface guidelines in the Grbl wiki. Some that use an intermediary process between the GUI and Grbl. If there is anything I can do on Grbl's side to ensure safety protocols are followed, even though it may be a slight inconvenience, I'll do so. This is what the critical event alarm is for.

What isn't clear is what your perceived issue with soft limits is. Perhaps clarify on how you think a soft limit error should be handled. I do agree it is not graceful in its current state, but not sure how to 'improve' it and not make it less safe.

[J-Dunn]

It may be that GRBL needs to take a lowest common denominator approach. That seems to be the current case which makes it less that optimal. Maybe a build option could help cover all bases.

My question was trying to get at the root cause of the problem. Is it just poorly written senders, that use a variety of often indirect methods of communication or it is a fundamental problem with doing serial comms over USB?

Since soft limit is a controlled stop which retains position, it seems that it should be possible to restart, rather than power cycling or resetting the CPU. That is the improvement I would like. That is generally applicable. My specific interest is that you suggested this in relation to what I was doing with L6474, where I would like the thermal warning condition to a controlled halt that can be restarted.

Turning a soft limit into a hard limit seems to negate the point of having a soft limit which can retain position count.

I hope that is clearer.

[chamnit]

@J-Dunn : Position is not lost upon a soft-limit alarm. It does a controlled deceleration to a stop before alarming. Just issue a soft-reset to exit the critical alarm and remove the alarm with an unlock $X. That's it.

[J-Dunn]

Yes, I realised I can do $X, thanks. So that leaves the machine at rest and all pending moves have been dumped and it's out of sync with the sender. Is that correct?

My fundamental question is about the cause of senders spewing GCODE when GRBL has stopped listening. That is what I'm trying to establish. Is this just poor sender design or an unavoidable weakness in serial over USB. Are you able to comment on that.

[chamnit]

@J-Dunn : Yes. Out of sync and cleared. I think what you are asking for is a program restart. This is not quite as trivial as you may think. Gcode is modal and parsers can be slight different from each other. If the initial gcode state and positions are not exactly right at the resume point, your program can result in a crash. In my view, a soft-limit alarm is a job-ending occurrence and it's best to check your gcode program (with $C) to see if the program will bring up a soft-limit beforehand. It doesn't take much time to do so and since you are using Grbl's parser directly, it will be exactly how Grbl will interpret the job.

There is no problem with serial over USB, not sure why you keep asking that. If a communication protocol is properly designed, you can avoid common issues like latency and bandwidth of whatever you use, even bluetooth, ethernet, or MPI. But, both the host and client have to follow the formal rules established for doing proper communication. If one side doesn't, you can have problems like senders spewing GCODE, as you say, when they shouldn't.

[J-Dunn]

"Yes. Out of sync and cleared. " OK, thanks. So that will not damage the work piece, That is the essential criterion. $C is fine for what you describe but will not anticipate thermal conditions in the driver, which is the specific condition I was trying to address. A controlled stop with the work intact is a good start and that may have to do for now. The nice thing about the L6474 is that you get a Th_warning while the driver is still functional and this gives the time to do a controlled stop. Thanks for the help on that.

"There is no problem with serial over USB, not sure why you keep asking that. " I kept asking because I did not get a reply. ;) Maybe too many points in one comment.

While the char counting described as the best method in the Wiki seems to be fairly reliable it is rather crude and cumbersome. If comms were done over a four wire RS232 link then h/w handshaking could ensure data stopped and started as required.

I'm not sure this is possible with serial over USB and 'virtual' comms ports or whether it is catered for by FTDI chips. I've been trying to find a definitive description of this situation for about 6mo without finding a clear answer. I've been finding conflicting answers.

[J-Dunn]

The current implementation may be the best that can be done on the AVR platform. However, in moving to STM32 or similar hardware there is the choice of using four wire RS232 and proper h/w handshaking. This means that flow control happens at the level of the serial port driver and there is no need to do byte counting or impose 'protocol' restrictions on the sender. Also screw-in D-type connectors seem more appropriate to machine control than drop out USB cables.

This implies using desktop format PC with a real physical serial port, through that would also be better for a workshop environment than dust prone laptops . ( Not a problem for those only interested in melting bits of plastic.).

[sebbra]

I am using the ST-Boards with L6474 as well. I have a breakoutboard with two Arduinos, one for the spi-configuration and one with a "normal" grbl. The grbl-Arduino is in reset on startup and is released when the spi-setup is done. The Error-out is connected to a Limit-Error-input, so the machine will stop on error, but that has never happened so far. For the grbl-Arduino everythink looks like a normel Step/Dir driver.

[splitn2]

hi @chamnit hey I am going to start another cnc build and was wondering about grabbing a Mega and starting to evaluate 1.x versions of GRBL. Do you think its likely the main stream 1.x will be based on the Mega 2560? I am building a large automated horizontal bandsaw for milling small timber logs and making strong laminated timber for ski and snowboard cores, this is an ideal controller for it to control the gantry feed rate and also the vertical positioning of the timber to control the timber slicing width. In theory its a 2 axis machine but I can see a third axis be handy , and also pwm control for the main electric cutting motor VFD control. Have you ever thought about MODBUS interface for allowing GRBL to do RS485 comms to VFD for speed control and status updates from the VFD like current and load? cheers Rich

[chamnit]

@splitn2 : For the short term, Grbl-Mega will be the one being pushed forward as a bridge to the ARM version, after v1.0 is released as master. I can't tell you exactly how long it'll be before the ARM version is made public. It could be by the end of the year to sometime in 2017. Hard to tell at this point.

As for speed control, yes, I'd like to include more complex controls for both spindles and stepper drivers. Grbl on the 328p is so limited in flash space that I can't do it there.

[splitn2]

@chamnit thats excellent, I've ordered a Mega 2560 and will start testing the releases as I see them come up. Thanks so much for your generousity. Cheers

[jackjameshoward]

@chamnit Any idea which electronics platform you will be choosing for the ARM version?

[chamnit]

@jackjameshoward : There's been a lot of discussion in the background with hardware integrators. We've settled on something, but I'd rather not say at this moment. However, I will say it's readily accessible and the core tenants of Grbl, like ease of installation, are still valid.

[splitn2]

nice!!!!! this is super exciting!

[langwadt]

not that I mind but I'm curious about keeping things so secret, is it hardware integrators asking for a head start?

[chamnit]

@langwadt: Not being secretive intentionally. It's more I don't want to say anything to commit to something I may change my mind about. ARM chips change constantly and a perfect chip still doesn't exist. It's always what's fits best this month. But some ARM boards are finding the niches how I expected them to and fit the bill acceptably for the short term. That's it. Nothing else.

[swarfer]

my question is "will I be able to get this board here in Africa" We can get Arduino's ok, but anything unusual gets expensive very quickly.

[chamnit]

@swarfer : I hadn't considered ITAR restriction before, but usually things powerful enough, like a Beaglebone, are export controlled. I did check some of your local distributors in South Africa. You can get a dev board with what I'm targeting. It's a not an overkill powerful chip per se. I'm pretty sure this includes just about every international country as well.

[swarfer]

thanks!

[langwadt]

Beaglebone just an example of ITAR, or are you considering cortex-A ? that would be a major change