Автономный контроллер своими руками.

[Виталий]

Поддерживаемые команды grbl 1.1h:
List of Supported G-Codes in Grbl v1.1:

- Non-Modal Commands: G4, G10L2, G10L20, G28, G30, G28.1, G30.1, G53, G92, G92.1

- Motion Modes: G0, G1, G2, G3, G38.2, G38.3, G38.4, G38.5, G80

- Feed Rate Modes: G93, G94

- Unit Modes: G20, G21

- Distance Modes: G90, G91

- Arc IJK Distance Modes: G91.1

- Plane Select Modes: G17, G18, G19

- Tool Length Offset Modes: G43.1, G49

- Cutter Compensation Modes: G40

- Coordinate System Modes: G54, G55, G56, G57, G58, G59

- Control Modes: G61

- Program Flow: M0, M1, M2, M30*

- Coolant Control: M7*, M8, M9

- Spindle Control: M3, M4, M5

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


Вместо М6 надо ставить М1 ТЫЦ

 

[homega]

Второй вариант поинтереснее.

...запоминает это положение в память, с флагом незавершённой работы и номер строки УП.
А также величины подачи и частоты вращения шпинделя.
Тогда питание можно выключить и продолжить на следующий день, после поиска дома.

приблизительно по такой логике хочу возобновить работу при потере питания
- маломощный UPS для логики ( скажем на 10секунд )
-при отлкючение питания подается команда на запись номер строки со всеми данными (подача, скорость .....)
- при возновобление основного питания --в дом
- вызов записанной строки
-(если добавить Z0 то можно и сменить инструмента )
- команда на выполнение

 

[Sany-sch]

приблизительно по такой логике хочу возобновить работу при потере питания
- маломощный UPS для логики ( скажем на 10секунд )
-при отлкючение питания подается команда на запись номер строки со всеми данными (подача, скорость .....)
- при возновобление основного питания --в дом
- вызов записанной строки

Не получится. Потеряются команды которые находятся в буфере обмена. Ведь вы их уже отправили, но они ещё не выполнены. И опрос текущего местоположения выдаст именно текущее. Вот поэтому и планирую:

прекращаем подачу команд, но те что находятся в буфере обмена продолжают выполняться. Контроллер в это время посылает сигналы о состоянии с некоторым интервалом, допустим в 0,5секунды. И когда движение прекращается, запоминает текущее положение и состояние.

То есть нужно дождаться остановки, а только потом сделать запись состояния.

 

[Samokatoff]

А количество команд в буфере - известное число? Что мешает учесть их при определении номера последней реально выполненной команды?

 

[Sany-sch]

А количество команд в буфере - известное число? Что мешает учесть их при определении номера последней реально выполненной команды?

Насколько я знаю - неизвестное.
Но можно, например,после каждой сотой команды делать остановку, сохраняться и ехать дальше, или каждой тысячной. Пауза будет незаметна.
Но это пока намётки. Сначала пауза.
Пока застрял на этапе как из информации о положении и состоянии станка создать нужные нам команды для возврата. Отслеживать движется станок или уже остановился - получилось.

 

[Alexf]

Но можно, например,после каждой сотой команды делать остановку, сохраняться и ехать дальше, или каждой тысячной.

Может стоит сохранять только номер строки?

Пока застрял на этапе как из информации о положении и состоянии станка создать нужные нам команды для возврата.

достаточно зная строку, на которой произошел останов, сначала дать команду на подъем шпинделя на безопасное расстояние, после чего дать команду на выполнение с строки, на которой произошел останов.
Разумеется предварительно придется отхоумиться по всем осям

 

[homega]

Не получится. Потеряются команды которые находятся в буфере обмена. Ведь вы их уже отправили, но они ещё не выполнены. И опрос текущего местоположения выдаст именно текущее. Вот поэтому и планирую:

То есть нужно дождаться остановки, а только потом сделать запись состояния.

значит буфер будем архивировать и возобновить цикл с него ....

 

[Sany-sch]

Может стоит сохранять только номер строки?

Номер строки сохранять не сложно, но что это даст?

достаточно зная строку, на которой произошел останов, сначала дать команду на подъем шпинделя на безопасное расстояние, после чего дать команду на выполнение с строки, на которой произошел останов.

У нас в каждой строке не задаются все координаты, а зачастую одна или две. Поэтому точного местоположения мы не достигнем.
Нужно сначала вернуться в точку где остановились, а затем давать команду. Иначе испортим заготовку.

 

[Alexf]

Номер строки сохранять не сложно, но что это даст?

Будем знать откуда продолжать

У нас в каждой строке не задаются все координаты, а зачастую одна или две. Поэтому точного местоположения мы не достигнем.
Нужно сначала вернуться в точку где остановились, а затем давать команду. Иначе испортим заготовку.

Да это так, как правило x и y, в таком случае запоминаем текущие координаты и строку, на которой произошел останов.
Тогда при новом запуске восстановив координаты и зная номер строки, можно продолжить
вроде ничего не упустил

 

[Sany-sch]

Но можно, например,после каждой сотой команды делать остановку, сохраняться и ехать дальше, или каждой тысячной. Пауза будет незаметна.

думал такое. А теперь размышляю и прихожу к тому, что ардуинка не может одновременно с двумя файлами на карте памяти работать. Нужно один файл, с г-кодом, закрыть, открыть и записать данные в другой файл, снова закрыть и открыть первый файл. И вот здесь мы теряем очередь первого файла и приходится начинать сначала.
Кто разбирается в картах памяти и ардуинках, поясните, я прав или есть выход?

 

[OlegK]

ардуинка не может одновременно с двумя файлами на карте памяти работать

По идее, создать две файловые переменные и должно работать без лишних открыть-закрыть.

Можно вообще держать и обновлять нужные данные в памяти (не так их и много), а при необходимости скинуть их в файл или в EEPROM.

 

[Sany-sch]

По идее, создать две файловые переменные и должно работать без лишних открыть-закрыть.

Для паузы, несомненно, такое решение подойдёт.
Я имел ввиду сохранять контрольные точки работы на случай отключения света.

а при необходимости скинуть их в файл или в EEPROM.

Если свет выключили, мы не успеем их скинуть. Либо менять схему и отслеживать напряжение.

 

[Shturman]

А если по другому... команда из буфера ушла... отработала/не успела... запомнили последнюю команду (естественно с координатами) и если что... (отключения энергии, сбой станка, кошка решила поиграться и т.д. и т.п.) возобновляем работу УП с последней (отработанной/отправленной/подтвержденной и т.д команды), можно минус 1-2-3 до этого...

 

[OlegK]

Пара мыслей...
1. Электричество может пропасть в любой момент, в том числе и в момент записи (не важно, на карту или в ЕЕПРОМ). Т.е. целостность данных, в этом случае, под вопросм.
2. На странице автора про взаимодействие с ГРБЛ есть способ с подсчётом символов.
Абзац "Streaming Protocol: Character-Counting". Это к вопросу, про отслеживание состояния буфера.
3. Возобновление работы УП: в запланированном случае можно начинать с той строки, где прекратили работу.
В незапланированном/аварийном можно и на несколько строк раньше начать.

 

[Alsan]

Для паузы, несомненно, такое решение подойдёт.
Я имел ввиду сохранять контрольные точки работы на случай отключения света.

Если свет выключили, мы не успеем их скинуть. Либо менять схему и отслеживать напряжение.

Пара мыслей...
1. Электричество может пропасть в любой момент, в том числе и в момент записи (не важно, на карту или в ЕЕПРОМ). Т.е. целостность данных, в этом случае, под вопросм.
2. На странице автора про взаимодействие с ГРБЛ есть способ с подсчётом символов.
Абзац "Streaming Protocol: Character-Counting". Это к вопросу, про отслеживание состояния буфера.
3. Возобновление работы УП: в запланированном случае можно начинать с той строки, где прекратили работу.
В незапланированном/аварийном можно и на несколько строк раньше начать.

В программировании профан, но думаю имеет смысл добавить буферный источник питания на Li-ion аккумуляторе с подзарядкой от платы GRBL для питания автономного контроллера. И программу сохранения запускать по сигналу пропадания основного питания станка. И отключение питания после завершения программы сохранения.