[Grbl_Esp32 Issue#481] Best way to take an alarm/fault input

#1 – bdring 于 2020-07-18

I think we need to expand the list of sysrtexec_alarm alarms.

currently

“C++
#define EXECALARMHARD_LIMIT 1
#define EXECALARMSOFT_LIMIT 2
#define EXECALARMABORT_CYCLE 3
#define EXECALARMPROBEFAILINITIAL 4
#define EXECALARMPROBEFAILCONTACT 5
#define EXECALARMHOMINGFAILRESET 6
#define EXECALARMHOMINGFAILDOOR 7
#define EXECALARMHOMINGFAILPULLOFF 8
#define EXECALARMHOMINGFAILAPPROACH 9
#define EXECALARMSPINDLE_CONTROL 10
`

We would then need to have some input I/O features with possible interrupts to watch that I/O

They could be generic like
`C++
#define ALARMINPUT1 GPIONUMxx
#define ALARMINPUT1TYPE EXECALARMMOTORFAULT
`

Eventually the same idea could be done without #defines`

It could quickly get messy if you want a separate input for each driver.

#2 – MitchBradley 于 2020-07-18

The alarm code value is used as follows:

* Several code paths check that it is nonzero
* protocol.cpp calls reportalarmmessage with the code, and then grblsendf(.."ALARM:%d\r\n", alarmcode);
* protocol.cpp checks for the specific values EXECALARMHARDLIMIT and EXECALARMSOFTLIMIT, treating those as “critical events”. Other alarm values are treated as non-critical

Some GCode senders parse the ALARM:n message. For example, CNCjs handles it as follows:

* The portion after ALARM: is extracted and spaces between : and n are removed.
* The result is converted to a number.
* The numerical value is looked up in a table that contains the number, a brief description, and a full description. For example, number 7 is “Homing fail” .. “Homing fail. Safety door was opened during homing cycle.”
* The table contains entries up to number 9. Number 10, which is EXECALARMSPINDLE_CONTROL, is not supported in CNCjs.
* If there is a match in the table, CNCjs sends the following message to the UI agent: ALARM: n brief_description. This is intended for GRBL 1.1 compatibility
* If there is no match in the table, CNCjs sends the entire ALARM:… message that it received, verbatim. This is intended for GRBL 0.9 compatibility.

GRBL 0.9 sent alarm messages in the form ALARM: brief_description . If we presume that GCode senders can handle GRBL 0.9 reporting, then we can send any new alarm types as text instead of numbers. Sending new alarm types as numbers will not be very friendly, unless we can manage to get senders to update their tables.

The possible failure mode would be if a sender, instead of inspecting the form of the ALARM: message and doing the right thing, were to switch on knowledge of the GRBL version.

If we assume that it is acceptable to send alarm messages in GRBL 0.9 text form, here is what we need:

* Each alarm needs a message string and a critical bit.
The clean way to do that is to create an alarm class with two fields, bool critical and const char message
* If we want to we can add a third field int alarmNum for the old grbl 1.1 compatible number – but I’m not sure that we need it.
* Instantiate that class for every existing alarm, and whenever a new alarm is needed, instantiate it again with the new message. There should not be a need to assign new numbers, because senders will not know them for new alarms anyway.

The argument to systemsetexecalarm() changes from uint8t to Alarm*.

#3 – karoria 于 2020-07-20

Thanks for considering it for improvement. For now, can I use step disable pin as input for such alarm to disable all the motors? Or any external arrangement to input to feedhold pin, so that till there is an alarm, user can not resume the program. Or simply operate a relay and cut off the power to drives.

#4 – bdring 于 2020-07-26

This has been added to the roadmap…closing