cnc-club.ru

Не надо переключать на горячую. Перемычка переключает "половинки" флешки с которой грузится FPGA, а прошивка всегда загружается во вторую половину (пользовательскую).
Первую половину можно перепрошить только через JTAG.

Ну тогда видимо я уже всё сделал.
Прошивку с mesanet скачал и прошил, и прямо, и как --fallback, --reload тоже сделал.
Можно что ещё придумать?

UAVpilot писал(а):Не надо переключать на горячую. Перемычка переключает "половинки" флешки с которой грузится FPGA, а прошивка всегда загружается во вторую половину (пользовательскую).
Первую половину можно перепрошить только через JTAG.

Точно?

Вот, что написано в мане (правда это к 7i76e):

DUAL EEPROMS
The second backup method relies on the fact that there are two flash memories on
the 7I76E card, selectable via jumper W9. If a configuration fails in such a way that it loads
correctly (has a valid CRC) but does not work, the fallback configuration will not be
invoked. To recover from this problem, the secondary flash can be selected by moving W8
to the DOWN position and using it to boot the FPGA (by cycling the power), restoring
remote access and allowing the primary configuration to be repaired via Ethernet. The
backup EEPROM is not write protected so if the primary EEPROM has been corrupted,
you should always restore W9 to the UP position to avoid writing a bad configuration to
both EEPROMS, necessitating a slow and awkward JTAG bootstrap.

Поправка: В область Failback можно что-то записать только со специальной опцией --failback, т.е. этого надо специально захотеть.
jtag понадобится, если поломать обе "прошивки".

В 7i76e стоят две флешки, в каждой есть failback и user области.

Вроде как вопрос не поднимался, но вот.
После обновления 2.6.0 Максимальная скорость JOG равна теперь максимальной скорости станка.
Если раньше в INI файле в секции (DISPLAY ) MAX_LINEAR_VELOCITY было ограничить возможную скорость ручного перемещения, то теперь указанная тут скорость ограничивает скорость всего станка.
Соответсвенно если тут поднять до максимума станка, то на да то бог двинуть станок в ручном режиме с зажатым SHIFT.

PS. если в ручнную задать параметh максимальной скорости станка ( у меня галетник холостого хода) связан непосредственно с пином halui.max-velocity.value , то скороть станка повысится до указанной в галетнике.
Соответственно эта проблема только в оболочке AXIS.

Дальше обновляйся - там этот баг поправили. Сейчас стабильная 2.6.9.

P.S. Чтобы без пользы не "толочь воду в ступе" я б советовал писать тут только о тех багах, которые есть либо в текущей стабильной версии, либо в последней нестабильной. Инфа об багах промежуточных версий просто не имеет смысла.

Это в 6.9 тоже присутствует. Проверил минут 5 назад

А, вспомнил! Это не баг, а фича.
В axis движок "Jog speed" регулирует макс. скорость ручных и холостых перемещений по каждой оси, а движок "Max speed" ограничивает суммарный вектор скорости по всем осям.

угу.. а по привычке после обновленя с ШИФТОМ чуть кучу не наложил!.. верните всё назад!!!!))))))

а переключение в G54 из любого другого по нажатию клавиши ESC во время работы - баг или фича? уж больно фиговая штука!

Ни то и ни другое. Проверил на 2.6.4, 2.6.9, 2.8.0 - везде не переключается.

В 2.4.* была проблема, когда жмешь на esc получалась какая- то фигня. Приходилось доролнительно прописывать М2 после останова. Потом в2.5 уже было автоматически м2. В 2.6 уже по нормальному) обновляйтесь)

я пишу про LINUXCNC - 2.6.9

Баг получен на LinuxCNC 2.8.0

Вот на что я наталкнулся, изменения в суброутине происходят по факту сохранения соответствующего ngc файла,
что довольно удобно для её отладки.
(Плохо что работать так не выходит и с обычными файлами, LinuxCNC теперь блокирует к ним доступ на запись.
Сделали бы эту фичу отключаемой, чтобы было удобно отлаживать программы)

В общем пишем суброутину И вызываем её в консоли MDI.
Так как суброутина написана без дефектов, то сообщений об ошибках при её работе не возникает.
Теперь вносим в неё дефект в виде подчёркивания в левой части:
#<_incremental> = #<_incremental>
И снова вызываем, появляется сообщение об ощибке:
Cannot assing to readonly parametr #<_incremental>
Убираем дефект возвращая суброутину к первоначальному виду и снова вызываем.
Снова выскакивает сообщение об ощибке записи в #<_incremental>
Убираем из суброутины строку #<incremental> = #<_incremental> И снова вызываем в MDI, опять таже ошибка.
Делаем пустуб суброутину Ошибки нет
Меняем её к виду Ощибка есть
Ну и так далее до перезагрузки программы.

В общем поскольку такое запоминание происходит только в таком случае, то я полагаю что это баг.

При включений в ini опцией [HAL]TWOPASS=ON двупроходного выполнения hal файлов конструкции вида
setp hm2_5i25.0.stepgen.00.dirsetup [AXIS_0]DIRSETUP
Приводят к появлению ошибки
twopass: Error in file ./SUDA-ST8070_5i25-7i76.hal:
invalid command name "AXIS_0"

torvn77 писал(а): [HAL]TWOPASS=ON

А что это значит?

Тут всё просто, да и вроде как уже устоявшийся стандарт записи раздела и пременной в ini.
Залез в ini, нашёл секцию [HAL] , добавил в неё строку и и сделал параметр TWOPASS=ON

В общем в первом проходе собирается информацию loadrt и пр. load, а потом для тех лоад,
где используется опция names все имена сливаются в большой общий список.

При чём если указать TWOPASS=OFF то опция будет продолжать работать.

Пожалуй на всякий случай из мануальника цитату добавлю

WOPASS = ON - Use twopass processing for loading HAL components. With TWOPASS processing, [HAL]HALFILE= lines are processed in two passes. In the first pass (pass0), all HALFILES are read and multiple appearances of loadrt and loadusr commands are accumulated. These accumulated load commands are executed at the end of pass0. This accumulation allows load lines to be specified more than once for a given component (provided the names= names used are unique on each use). In the second pass (pass1), the HALFILES are reread and all commands except the previously executed load commands are executed.

http://linuxcnc.org/docs/devel/html/con ... al_section

Тогда это можно смело в багтрекер LinuxCNC добавлять.

Хотя вообще странно - практически все стандартные конфиги содержат отсыл к ini.

Twopass по умолчанию не включен ну и нужен если пишешь нечто очень сложное, в чём очень легко запутаться.
По этому на стандартных конфигах это не заметно.

П.С. А они не собираются переезжать на github.com?

Nick писал(а):Тогда это можно смело в багтрекер LinuxCNC добавлять.

А на github.com им issue оставить можно или обязательно на sourceforge регистрироваться?
(Не хочу я разводить аккаунты)