Serial error line number is not last line number 1 last line

Andrew S

 

Сообщения: 431

Зарегистрирован: 20 янв 2014, 22:44

Откуда: 21RU

прог. языки: Assembler, Basic, Arduino IDE, PHP и др.

ФИО: Андрей С

Andrew S

 

Сообщения: 431

Зарегистрирован: 20 янв 2014, 22:44

Откуда: 21RU

прог. языки: Assembler, Basic, Arduino IDE, PHP и др.

ФИО: Андрей С

serovst

 

Сообщения: 3

Зарегистрирован: 13 мар 2014, 23:35

Andrew S

 

Сообщения: 431

Зарегистрирован: 20 янв 2014, 22:44

Откуда: 21RU

прог. языки: Assembler, Basic, Arduino IDE, PHP и др.

ФИО: Андрей С

mitya.zyu

 

Сообщения: 5

Зарегистрирован: 26 мар 2013, 13:47

Откуда: Ростов

Andrew S

 

Сообщения: 431

Зарегистрирован: 20 янв 2014, 22:44

Откуда: 21RU

прог. языки: Assembler, Basic, Arduino IDE, PHP и др.

ФИО: Андрей С

Andrew S

 

Сообщения: 431

Зарегистрирован: 20 янв 2014, 22:44

Откуда: 21RU

прог. языки: Assembler, Basic, Arduino IDE, PHP и др.

ФИО: Андрей С

neverdie

 

Сообщения: 12

Зарегистрирован: 14 мар 2014, 00:49

mitya.zyu

 

Сообщения: 5

Зарегистрирован: 26 мар 2013, 13:47

Откуда: Ростов

thel

 

Сообщения: 1

Зарегистрирован: 16 мар 2014, 06:36

Damir

 

Сообщения: 37

Зарегистрирован: 07 мар 2014, 21:48

Содержание

1. roboforum.ru
2. Новичкам. Задай вопрос — получи ответ
3. Re: Новичкам. Задай вопрос — получи ответ
4. Re: Новичкам. Задай вопрос — получи ответ
5. Re: Новичкам. Задай вопрос — получи ответ
6. Re: Новичкам. Задай вопрос — получи ответ
7. Re: Новичкам. Задай вопрос — получи ответ
8. Re: Новичкам. Задай вопрос — получи ответ
9. Re: Новичкам. Задай вопрос — получи ответ
10. Line Number is not Last Line Number
11. Comments
12. [BUG] Error: Checksum Mismatch, Last Line: xx #14124
13. Comments
14. Footer
15. Term tab
16. Recommended Posts
17. Create an account or sign in to comment
18. Create an account
19. Sign in
20. Our picks
21. Cura 5.3 Alpha With New Tree Support 🎄
22. Picked By
23. New here? Get ahead with a free onboarding course
24. Нужна помощь с принтером
25. Подпишитесь на автора
26. Подпишитесь на автора

PR «Encapsulate Stepper, Planner, Endstops в одноэлементных классах» # 3631 потенциально может повлиять на время выполнения ISR.

@ Sebastianv650
Какую хост-программу вы используете? Какой BAUDRATE вы используете? Существенно ли снижается частота ошибок при использовании более низкого значения BAUDRATE?

Если вы используете RepetierHost не в режиме пинг-понга, попробуйте пинг-понг или уменьшите «Размер кэша приема» примерно до 75%.

Если у вас есть подозрение, что ваш код LIN_ADVANCE занимает намного больше времени, например, когда «нормальный» шаговый ISR переходит в режим дублеста / квадрошага, попробуйте ввести:

      #ifndef USBCON
        customizedSerial.checkRx(); // Check for serial chars.
      #endif

Я использую pronterface со скоростью 250000 бод, безуспешно изменил его на 115200.
Я не использую диапазоны скоростей, в которых в последние дни происходило бы двойное тактирование, я перешел до 80% в одноступенчатый режим.

3631 потенциально может повлиять на время выполнения ISR

Нет, если компилятор умен. Во-первых, использование myObject.functionCall() не дороже, чем functionCall() . Так что одно это не должно добавлять никаких циклов. Во «Встроенном C ++» мы старательно избегаем virtual , this-> , objPointer-> и т. Д., Чтобы обеспечить более плоскую компиляцию.

Компилятор также должен уметь это делать:

ISR(TIMER1_COMPA_vect) { stepper.isr(); }

Он должен признать, что он не должен этого делать …

ISR_HANDLER:
  JSR Stepper_isr
  RET

… Но он должен сделать это…

ISR_HANDLER:
  JMP Stepper_isr

… И, честно говоря, он должен признать, что:

ISR_HANDLER == Stepper_isr

Я слишком доверяю компилятору?

Я просто не согласен с тем, что this->method() менее эффективен, чем method() когда внутри класса компилятор отбросит ссылку this и сделает JMP func() в обоих случаях преимуществом использования this-> является повышенная читаемость.

Я использую pronterface со скоростью 250000 бод, безуспешно изменил его на 115200.
Я не использую диапазоны скоростей, в которых в последние дни происходило бы двойное тактирование, я перешел до 80% в одноступенчатый режим.

Использование Promterface переводится для меня как использование пинг-понга, что делает маловероятным переполнение RX-буфера.
Отсутствие улучшений с 115200bd означает дублирование времени между поступающими символами. Это делает невозможным получение символа из регистра маловероятным.
Ошибки на USB между хостом и AT32U2 (используемым в качестве микросхемы USB) маловероятны из-за контрольной суммы блока USB.
Ошибки на последовательной линии между AT32U2 и AT2560 (аппаратная проблема). Это вряд ли изменится с выпуском версий. Но более вероятно, что с увеличением частоты сильноточных линий рядом с последовательными линиями.
Повреждение RX-буфера. Маловероятно с 8-битными индексами буфера и защитой от прерываний. Вероятность возрастает с увеличением количества содержимого буфера — маловероятно для пинг-понга. «Странный» указатель откуда-то? Неправильные индексы массива в соседнем массиве?

Трудно сказать, что происходит.
Может быть, маленькие помощники по отладке ввода @AnHardt могут подсказать .
https://github.com/AnHardt/Marlin/pull/32

Я использую pronterface со скоростью 250000 бод, безуспешно изменил его на 115200.

Это для меня каким-то образом очищает ошибки задержки ISR … иначе нам пришлось бы действительно накручивать его, чтобы по-прежнему влиять на 115,2 бит / с.

Мы уверены, что теперь это оборудование? Может ли быть шум на последовательной линии? Шум мог увеличиваться при увеличении частоты вращения двигателей на более высоких скоростях. У вас есть прицел?

К сожалению, объем недоступен. Не могу представить, что это железо. Я печатаю 70 идентичных деталей, поэтому все тесты проводятся с одним и тем же gcode. RC4 работает «гладко» даже с опережением (возможно, 4-5 ошибок в час), RCBugFix с другой стороны наводняет окно состояния пронтерфейса сообщениями об ошибках, и 1-2 раза в час принтер даже делает неправильные «печать» перемещается в один край печатной платформы (я полагаю, ограничен только пределами программного обеспечения).

Это для меня каким-то образом очищает ошибки задержки ISR … иначе нам пришлось бы действительно накручивать его, чтобы по-прежнему влиять на 115,2 бит / с.

Я могу ошибаться, но вы так думаете? Если нам нужно передать 10 команд для печати, скажем, каждая из них занимает 0,5 секунды (я знаю, только для облегчения расчета) при 115200 бод и 0,25 при 250000 бод, а ISR работает с фиксированной скоростью. Чем более вероятно, что ISR «попадает» в передачу медленных 115200 бод длиной 0,5 с, чем передача длительностью всего 0,25 с?
Для меня, как программиста-любителя, я бы сказал, что более высокая скорость лучше не влияет на шаговый ISR.

Я встрою AnHardt # 32 в свой код и проведу с ним несколько тестов, но для получения результатов потребуется некоторое время, поскольку мой принтер заблокирован на следующие 9 часов.

Да, но при снижении скорости передачи вы ожидаете увидеть разницу в количестве ошибок, если нет разницы, то может быть верно одно из двух:

• это не ISR
• это ISR с глубоким провалом

Но изменения ISR были минимальными.

Итак, последней хорошей версией была RC4, верно?

Хорошо, если честно, я не могу точно сказать, ухудшило ли это снижение скорости передачи. В обоих случаях ошибки появляются одна за другой. Если мы хотим знать это точно, мне нужно выполнить несколько прогонов с обеими скоростями передачи и посчитать среднее значение.

Да, я вижу ошибки и в RC4, но без предварительного просмотра, возможно, 1 из 10 часов. Не забывайте о цифре, но это показатель, о котором я не беспокоюсь.

RCBugFix, с другой стороны, наводняет окно статуса пронтерфейса сообщениями об ошибках.

@ Sebastianv650 Вы говорите о сообщениях «поддержки активности хоста», таких как » занято: обработка » или ошибках номера строки / контрольной суммы?

Все версии сообщений об ошибках: в основном контрольная сумма, некоторые несоответствия номеров строк, некоторые «нет контрольной суммы с номером строки».

Я внес изменения в отладку

SENT: N803 G1 X145.808 Y146.311 E0.14351*107
RECV: ok N802 P0 B2 R128 "N802 G1 X147.472 Y147.976 E0.11133"
SENT: N804 G1 X144.915 Y146.058 E0.15620*108
RECV: ok N803 P0 B2 R128 "N803 G1 X145.808 Y146.311 E0.14351"
SENT: N805 G1 X147.099 Y148.241 E0.19841*98
RECV: ok N804 P0 B2 R128 "N804 G1 X144.915 Y146.058 E0.15620"
SENT: N806 G1 X146.764 Y148.544 E0.20460*98
RECV: ok N805 P0 B2 R128 "N805 G1 X147.099 Y148.241 E0.19841"
SENT: N807 G1 X143.891 Y145.671 E0.26015*107
RECV: Error:checksum mismatch, Last Line: 806 "N803 G1 X145.808 Y146.311 E0.14351"
[ERROR] Error:checksum mismatch, Last Line: 806 "N803 G1 X145.808 Y146.311 E0.14351"
RECV: Resend: 807
SENT: N807 G1 X143.891 Y145.671 E0.26015*107
RECV: ok N806 P0 B3 R128 "N806 G1 X146.764 Y148.544 E0.20460"
SENT: N808 G10*24
RECV: ok N806 P0 B1 R128 "N806 G1 X146.764 Y148.544 E0.20460"

У кого-нибудь есть идея? Линия мне кажется нормальной …

Фактический обмен данными выглядит неплохо, хотя мы не видим всех контрольных сумм. Но меня озадачивает сообщение об ошибке — это 806 или 803 ошибка? И почему тогда происходит ресинхронизация на 807? Что на самом деле случилось с 803 по 806 … странно.

Линия мне кажется нормальной …

Мне это кажется странным. Он говорит нам, что когда он пытается интерпретировать строку «806», он видит текст строки «803».

Я уже спрашивал, какую версию Arduino вы используете для сборки?

Пользуюсь 1.6.8.
Я сделал тест, добавив customSerial.checkRx (); также в экструдере ISR. Это значительно снизило частоту ошибок, теперь оно составляет ~ 4 для 6-минутной печати, без этой второй проверки его >> 12.

Сожалею.
https://github.com/AnHardt/Marlin/pull/32 — это код отладки, который работал до того, как serial_line_buffer[] был введен в get_serial_commands() . Теперь, когда возникают ошибки, соответствующая строка все еще находится в serial_line_buffer[] и еще не скопирована в command_queue[cmd_queue_index_w] .
Печатается неправильная строка.
Сожалею.

@ Sebastianv650 Что ж, это интересно. Я не могу (вполне) представить, что сделало бы шаговый двигатель _ значительно медленнее между RC4 и RC6, но, похоже, это так. Я проведу дополнительные исследования по оптимизации кода C ++ и посмотрю, есть ли способ сохранить инкапсулированный метод Stepper::isr но при этом сохранить максимальную производительность.

@AnHardt @ Sebastianv650
Если функция gcode_line_error изменена так, чтобы принимать указатель на строку, тогда вы можете передать ей serial_line_buffer из get_serial_commands и вместо этого распечатать эту строку.

Спасибо за подсказки, @AnHardt , @thinkyhead ! Я внес изменения, и теперь он печатает поврежденную строку, вот одну из многих, которые я получаю:

SENT: N967 G1 X134.346 Y136.203 E2.96084*105
RECV: ok N967 P0 B3 R128 "N967 G1 X134.346 Y136.203 E2.96084"
SENT: N968 G1 X134.403 Y135.652 E2.96970*97
RECV: ok N968 P0 B3 R128 "N968 G1 X134.403 Y135.652 E2.96970"
SENT: N969 G1 X139.652 Y140.901 E3.08866*96
RECV: Error:checksum mismatch, Last Line: 968 "N969 G1 X19.652 Y140.901 E3.08866*96"
[ERROR] Error:checksum mismatch, Last Line: 968 "N969 G1 X19.652 Y140.901 E3.08866*96"

В командах отсутствуют отдельные символы, в этом примере «3» в координате X. Теперь также имеет смысл, что мое вчерашнее изменение (добавлениеustomSerial.checkRx () также в шаговый ISR) сделало его менее хуже: «ввод» проверяется чаще, а пропущенные символы уже не так часто встречаются.

Но я недостаточно умен, чтобы знать настоящий ответ: почему отсутствуют символы, когда основной шаговый ISR занимает больше времени?

Подумав о том, что написал

Отсутствуют символы -> ISR занимает слишком много времени, или CRITICAL_SECTION не закрывается должным образом. RX-прерывание сериалов выполнено слишком поздно — содержимое RX-регистров заменено на следующий символ.

и глядя, как Марлин обрабатывает доступные символы, я бы резюмировал следующее. Пожалуйста, поправьте меня, если я ошибаюсь:
.) При скорости передачи 250000 бод появляется новый символ каждые 40 мкс. Если символ не читается, он заменяется следующим, отправленным хостом.
.) Есть два способа сохранить новый char:
Прерывание срабатывает при получении нового символа — но у этого есть почти самый низкий из возможных приоритетов, доступных на Atmega, поэтому оно может быть «отложено» прерываниями timer0, используемыми шаговыми двигателями, еще хуже с таймером1, используемым предварительным шаговым двигателем ISR.
Это может быть причиной того, что внутри шагового ISR есть еще одна контрольная точка, которая пытается сохранять char в каждом цикле. Но если этот цикл занимает более 40 мкс, символ исчезает — теперь появляются мои сообщения об ошибках.

Итак, ответ, почему я получаю намного больше ошибок с включенным продвижением, ясен: я делаю еще несколько вычислений внутри шагового ISR. Это может приблизить ISR к 40 мкс.
То, что ошибок в RC6 еще больше, означает, что шаговый ISR немного медленнее, чем в RC4. Может быть, немного, но 40 мкс — это тоже немного ..

Чтобы доказать это, я снова установил скорость 115200 бод. Я уже сделал это, так как видел ошибки, когда начал предварительное кодирование, но безуспешно. Но с того дня я оптимизировал код. При скорости 115200 бод Atmega имеет в 2 раза больше времени, чтобы получить символ из буфера. С последним предварительным кодом это решило 100% сообщений об ошибках! (Помните: я использую версию RC4. Мне нужно посмотреть, верно ли это и для RC6.)

Это приводит к двум следующим вариантам:
.) Живите с «всего» 115200 бод. Кто-то проверял, повлияет ли это когда-нибудь на печать? Может быть, влияние быстрого символа на 250000 бод хуже, чем «медленная» скорость передачи 115200 бод?
.) Найдите способы улучшить шаговый ISR, чтобы он занимал меньше циклов.
.) Проверьте, помогает ли это, когда у устройства последовательного приема есть собственный ISR, запускаемый с фиксированной скоростью в зависимости от выбранной скорости передачи. Таким образом, никакой символ не должен быть потерян. В худшем случае это приведет к остановке остальной части кода из-за высокой скорости проверки, но в этом случае текущая реализация не должна быть лучше, чем вы получите пропущенные символы ..

Твое мнение?

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

Я рассматриваю этот вариант, который в основном означает возврат всех синглтонов обратно к (еще лучше инкапсулированному) плоскому коду C с привязкой static . Но прежде чем я это сделаю, я постараюсь исчерпать все остальные возможности, например, обнаружение компилятора C ++ может быть «умнее» и создать машинный код, столь же эффективный, как и старый код.

Честно говоря, я не знаю, насколько действительно отличается вывод компилятора. Но я ожидал, что компилятор будет достаточно умен, чтобы увидеть, что синглтоны в основном используются просто как «пространства имен» для инкапсуляции некоторых функций. Но компоновка — это то, к чему компиляторы иногда до странности религиозны.

Хотелось бы, чтобы у нас было лучшее профилирование, чтобы мы могли видеть, на что тратятся все наши циклы. Симулятор Марлина, вероятно, мог бы помочь с этим, поскольку на него также повлияла бы связь.

То, что ошибок в RC6 еще больше, означает, что шаговый ISR немного медленнее, чем в RC4.
Помните: я использую версию RC4. Я должен посмотреть, верно ли это и для RC6.

Если проблемы с производительностью и ошибки связи проявляются в RC4 возможно, текущие синглтоны не являются главным виновником. Запуск Advance ISR со скоростью, в многоступенчатое выполнение в Advance ISR является лучшим решением.

Опять же, правильное _профилирование_ было бы очень полезно!

Это действительно указывает на голод, то есть у процессора не хватает времени, и он в основном работает только с ISR. Я не уверен, что то, что создается с помощью кода C ++, медленнее, чем C, хотя должен сказать, что вероятность этого довольно высока.

Это зависит от флагов / настроек компилятора. Обратите внимание, что IDE arduino использует довольно оптимизированную версию этих флагов. Это не будет (намного) лучше, чем это.

Мне нравится, когда теорию подтверждают тестом.

250000 <-> 115200 бод. Прием с 115200bd должен быть в порядке. Отправка с 115200bd может быть проблемой. Марлин занят ожиданием, пока пишет. (https://github.com/MarlinFirmware/Marlin/blob/RC/Marlin/MarlinSerial.h#L122 https://github.com/MarlinFirmware/Marlin/blob/RC/Marlin/MarlinSerial.h#L152 ++)
Запись для 80 символов означает около 3,2 мс при 250000 бод, более 6 мс при 115200 бод. Это может иметь значение, если мы будем отправлять не только «ОК», но и много отладочной информации. Однако ISR могут прервать занятое ожидание.

Последовательный прием имеет собственный ISR

Уже есть. Но никакое (программное) прерывание не может прервать другое прерывание. Приоритет прерывания только определяет, кто будет следующим, если в регистре находится более одного запроса прерывания после завершения текущего прерывания.

Мне нравится, когда теорию подтверждают тестом.

Спасибо тестировщикам, фидбекерам! Без вас мы, хорошо знающие код, но не платформу или компилятор, часто чувствуем себя немного потерянными в темноте. Но благодаря такому опыту можно многому научиться. Всем огромное спасибо!

Или вы можете включить передачу в процедуру TxInterrupt ….
10 мая 2016 г., 12:16, «Roxy-3DPrintBoard» [email protected]
написал:

Отправка с 115200bd может быть проблемой. Марлин занят ожиданием, пока
письмо.

Это своего рода метод грубой силы, чтобы обойти это … Но это сработает
для скорости 115 000 или 250000 бод. И нет большого штрафа
потому что мы все равно заняты ожиданием. Пока мы кружимся в ожидании
посмотреть, можем ли мы передать символ, нам, вероятно, следует проверить, чтобы увидеть
если на приемной стороне UART появился символ. Мы бы просто добавили
немного дрожания, когда мы вернемся:

FORCE_INLINE void write(uint8_t c) {
  while (!TEST(M_UCSRxA, M_UDREx))
    checkRx();
  M_UDRx = c;
}

—
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/MarlinFirmware/Marlin/issues/3680#issuecomment -218190029

Или вы можете поместить передачу в процедуру Tx-Interrupt ….

Да. И если это произошло, может иметь смысл проверить статус Rx в обработчике прерывания. Добавим к нему несколько строк кода:

      if (TEST(M_UCSRxA, M_RXCx)) 
          checkRx();

Я всегда печатал со скоростью 250 кбит / с, могу подтвердить, что с RC6 я также вижу случайные ошибки контрольной суммы.

Resend: 9399
Error:checksum mismatch, Last Line: 11315
[ERROR] Error:checksum mismatch, Last Line: 11315

Resend: 11316
Error:checksum mismatch, Last Line: 12547
[ERROR] Error:checksum mismatch, Last Line: 12547

Resend: 12548
Error:checksum mismatch, Last Line: 12580
[ERROR] Error:checksum mismatch, Last Line: 12580

Resend: 12581
Error:checksum mismatch, Last Line: 13270
[ERROR] Error:checksum mismatch, Last Line: 13270

Resend: 13271
Error:checksum mismatch, Last Line: 14503
[ERROR] Error:checksum mismatch, Last Line: 14503

Каков текущий статус этой темы?

Я всегда печатал со скоростью 250 кбит / с, могу подтвердить, что с RC6 я также вижу случайные ошибки контрольной суммы.

Я думаю, что AnHardt уже сделал это, но было бы хорошо распечатать строку с ошибкой контрольной суммы. Скорее всего, потерялись какие-то персонажи. Если это так, мы бы хотя бы знали, что нам нужно лучше справляться с поступающим потоком символов.

Хорошо, я проводил тесты ..

• Prointerface: случайные ошибки контрольной суммы при печати 5 м, но печать выполняется успешно
• Repetier Host (опция Pin-ping включена): случайные ошибки контрольной суммы во время 5-метровой печати, но печать успешно
• Repetier Host (опция Pin-ping отключена): печать тормозит, не удается завершить печать из-за большого количества ошибок контрольной суммы

Все тесты проводились с DISABLE_HOST_KEEPALIVE , RC6 без каких-либо модификаций.

@jbrazio
Не могли бы вы попробовать

• Repetier Host (опция Pin-ping отключена) Размер буфера уменьшен до 50% (64)

Бьюсь об заклад, вы также можете увидеть недостающие символы с модами AnHardts ..
Между прочим, я провел несколько измерений времени, которые подтверждают мое предположение о времени работы основного шагового ISR:

Время выполнения ISR с включенным Advance, но K = 0: 81 мкс
Время выполнения ISR с включенным Advance с K <> 0: 95 мкс
Таким образом, очевидно, что при нынешнем способе обработки входящих символов невозможно обеспечить скорость 250000 бод.

Но расчет нового сегмента (добавить его в буфер и пересчитать все существующие сегменты) занимает 3,15 мс , поэтому я бы сказал иначе:
Если вы вводите 30 символов на команду, вы можете отправлять около 384 команд в секунду со скоростью 115200 бод. Но с планировщиком, которому требуется 3,15 мс на новую строку, вы можете обрабатывать только до 317 строк (команд) в секунду. Если учесть, что у FW больше дел, чем только пересчет входящих отрезков линии, цифры становятся еще хуже ..

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

Ах. Числа.
Насколько глубок ваш буфер планировщика?

Не могли бы вы попробовать
Repetier Host (опция Pin-ping отключена) Размер буфера уменьшен до 50% (64)

Я сейчас печатаю SD, сегодня вечером постараюсь доложить вам.

Если вы вводите 30 символов на команду, вы можете отправлять около 384 команд в секунду со скоростью 115200 бод. Но с планировщиком, которому требуется 3,15 мс на новую строку, вы можете обрабатывать только до 317 строк (команд) в секунду.

Это может быть справедливо, если вы предполагаете состояние синхронизации, поэтому у нас есть буферы.

Я не менял размер буферов, поэтому он должен быть тем же, что и в коде RCBugFix по умолчанию.
@jbrazio , это правда, это расчет наихудшего случая. Но это верно даже для буфера: если буфер заполнен, вам вообще не нужна скорость передачи (нет места для вычисления новых строк). Если он пуст, более 317 строк не могут быть обработаны / с, поэтому 115200 — это максимум. используемая скорость передачи данных. Если бы код мог получить все символы на скорости 250000 бод, я бы, конечно, не увидел недостатков в использовании 250000!

Окончательное исправление (или, по крайней мере, улучшение) ошибок связи будет заключаться в переписывании Stepper (и Planner , Temperature , Endstops ) для использования static данные и методы, потому что в настоящее время все эти вызовы нестатических методов имеют дополнительный параметр this , а элементы шаговой ISR замедлены настолько, чтобы заставить ее работать слишком долго. Любые другие умные оптимизации, о которых мы только можем подумать, также помогут!

3730 — это тема для этого небольшого отступления.

Пока что я получаю много жалоб на компилятор (ошибки ссылок), поскольку я делаю вещи static протяжении Stepper , поэтому ищу полезные советы по совершенствованию этого. Я могу опубликовать ссылку на свою ветку, если кто-то захочет предложить советы по коду в качестве комментариев к коммитам.

На AVR gcc ведет себя как дебил, или я не понимаю, почему «this->» является мусором по сравнению со статической переменной.

Ключевое слово Static указывает компилятору, что переменная является переменной класса, совместно используемой всеми экземплярами класса, с другой стороны, «стандартный» класс var доступен только самому экземпляру (или другим экземплярам того же класса, но это другая история) ).

«this» — не более чем указатель на экземпляр класса.

AVR-gcc должен оптимизироваться и выполнять прямой адресный «переход» либо при доступе к статической переменной, либо к переменной, вызываемой как «this-> foo».

@jbrazio Компилятор C ++ не догадывается, что при вызове stepper.my_instance_method() всегда будет только один экземпляр этого класса. Итак, всегда есть скрытая переменная this переданная в метод в стеке в качестве первого аргумента. Это обычное соглашение о вызове методов _instance_. Чтобы избавиться от скрытого аргумента this , вы используете static , и теперь это метод _class_. И, конечно же, у вас нет this , но вы можете, например, синтезировать переменную « me » (довольно распространенная практика с синглтонами) для обращения к экземпляру.

Извините, если это всего лишь обзор C ++.

Когда дело доходит до ISR, сама ISR (обычно) является глобальной статической функцией в стиле C. Для Stepper ISR в настоящее время он вызывает stepper.isr() . Это передает &stepper из стека в метод Stepper::isr() , который получает его как переменную « this ». ( Stepper::isr не является FORCE_INLINE , но я полагаю, что это могло быть, если переместить тело метода в заголовок stepper.h . Это, вероятно, сохранит один вызов stepper.isr() при этом не передает stepper как this в стек, но ничего не делает для вызовов других синглтонов, все _instance-методы_ которых берут эти дополнительные this параметр.

Чтобы получить более компактные соглашения о вызовах в стиле C-функций и сэкономить на вызовах методов экземпляра, единственный вариант — объявить данные и методы класса как static . Они по-прежнему могут быть volatile или inline или даже FORCE_INLINE с ключевым словом static .

Части класса, не зависящие от производительности, могут оставаться данными и методами экземпляра, если это имеет смысл, но большую часть класса необходимо «сплющить» в один статический «экземпляр класса», чтобы получить максимальную производительность с помощью этого компилятора.

Я также пробовал флаг -fwhole-program , который может выполнять дополнительную магическую статическую оптимизацию, но мне не удалось успешно скомпилировать его. Мне было любопытно посмотреть, не повлияет ли это на производительность, если он автоматизирует некоторые из этих вещей. Но похоже, что мне нужно делать больше «вручную» и разбираться с ошибками компиляции.

Так что я пошел по пути ASM и узнал новое.

Подопытный.

class aClass {
  public:
    char i;
    static char j;

  void foo() {
    this->i = 5;
  }

  static void bar() {
    aClass::j = 10;
  }
};

int main (void)
{
  aClass a;
  a.foo();
  a.bar();
}

Код разборки для a.foo(); .

void aClass::foo() { ; 34 clk, 2.125 uS
 132: cf 93         push  r28              ; 2 clk
 134: df 93         push  r29              ; 2 clk
 136: 1f 92         push  r1               ; 2 clk
 138: 1f 92         push  r1               ; 2 clk
 13a: cd b7         in  r28, 0x3d ; 61     ; 1 clk
 13c: de b7         in  r29, 0x3e ; 62     ; 1 clk
 13e: 9a 83         std Y+2, r25  ; 0x02   ; 2 clk
 140: 89 83         std Y+1, r24  ; 0x01   ; 2 clk
  this->i = 5;
 142: 89 81         ldd r24, Y+1  ; 0x01   ; 2 clk
 144: 9a 81         ldd r25, Y+2  ; 0x02   ; 2 clk
 146: 25 e0         ldi r18, 0x05 ; 5      ; 1 clk
 148: fc 01         movw  r30, r24         ; 1 clk
 14a: 20 83         st  Z, r18             ; 2 clk
}
 14c: 0f 90         pop r0                 ; 2 clk
 14e: 0f 90         pop r0                 ; 2 clk
 150: df 91         pop r29                ; 2 clk
 152: cf 91         pop r28                ; 2 clk
 154: 08 95         ret                    ; 4 clk

Код разборки для a.bar(); .

void aClass::bar() { ; 17 clk, 1.062 uS
 156: cf 93         push  r28             ; 2 clk
 158: df 93         push  r29             ; 2 clk
 15a: cd b7         in  r28, 0x3d ; 61    ; 1 clk
 15c: de b7         in  r29, 0x3e ; 62    ; 1 clk
  aClass::j = 10;
 15e: 8a e0         ldi r24, 0x0A ; 10    ; 1 clk
 160: 80 93 00 02   sts 0x0200, r24       ; 2 clk
}
 164: df 91         pop r29               ; 2 clk
 166: cf 91         pop r28               ; 2 clk
 168: 08 95         ret                   ; 4 clk

Вывод: для обновления переменной класса требуется 2,125 мкс (34 тактовых цикла), для обновления статической переменной класса требуется 1,062 мкс (17 тактовых циклов), что ровно вдвое меньше.

Подопытный.

class aClass {
  public:
    char i;

  void foo() {
    this->i = 5;
  }

  void baz() {
    i = 15;
  }
};

int main (void)
{
  aClass a;
  a.foo();
  a.baz();
}

Код разборки для a.foo(); .

void aClass::foo() {
 12c:   cf 93           push    r28
 12e:   df 93           push    r29
 130:   1f 92           push    r1
 132:   1f 92           push    r1
 134:   cd b7           in  r28, 0x3d   ; 61
 136:   de b7           in  r29, 0x3e   ; 62
 138:   9a 83           std Y+2, r25    ; 0x02
 13a:   89 83           std Y+1, r24    ; 0x01
  this->i = 5;
 13c:   89 81           ldd r24, Y+1    ; 0x01
 13e:   9a 81           ldd r25, Y+2    ; 0x02
 140:   25 e0           ldi r18, 0x05   ; 5
 142:   fc 01           movw    r30, r24
 144:   20 83           st  Z, r18
}
 146:   0f 90           pop r0
 148:   0f 90           pop r0
 14a:   df 91           pop r29
 14c:   cf 91           pop r28
 14e:   08 95           ret

Код разборки для a.baz(); .

void aClass::baz() {
 150:   cf 93           push    r28
 152:   df 93           push    r29
 154:   1f 92           push    r1
 156:   1f 92           push    r1
 158:   cd b7           in  r28, 0x3d   ; 61
 15a:   de b7           in  r29, 0x3e   ; 62
 15c:   9a 83           std Y+2, r25    ; 0x02
 15e:   89 83           std Y+1, r24    ; 0x01
  i = 15;
 160:   89 81           ldd r24, Y+1    ; 0x01
 162:   9a 81           ldd r25, Y+2    ; 0x02
 164:   2f e0           ldi r18, 0x0F   ; 15
 166:   fc 01           movw    r30, r24
 168:   20 83           st  Z, r18
}
 16a:   0f 90           pop r0
 16c:   0f 90           pop r0
 16e:   df 91           pop r29
 170:   cf 91           pop r28
 172:   08 95           ret

Заключение: использование this для повышения общей читаемости класса не имеет значения с точки зрения производительности, поскольку компилятор создает точно такой же код ASM.

Ага, как и ожидалось. Использование this-> _ внутри методов экземпляра_ совершенно безвредно, но мы получаем удар, вызывая _instance методы_ из любого другого места. Итак, static методы будут нашим другом, особенно там, где мы в настоящее время вызываем _instance methods_ из ISR.

Подскажите, пожалуйста, как вам удалось разобрать на C ++
Рекомендации?
Хорошая работа, кстати

В среду, 18 мая 2016 г., в 22:17, Скотт Лахтейн [email protected]
написал:

Ага, как и ожидалось. Использование this-> внутри _class methods_ является
совершенно безвредны, но мы получаем удар, вызывая _instance methods_ из
где-нибудь еще. Итак, статические методы станут нашим другом, особенно
где мы в настоящее время вызываем _instance методы_ из ISR.

—
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/MarlinFirmware/Marlin/issues/3680#issuecomment -220203062

Где бы вы использовали this не находясь внутри экземпляра? ..

Вы знаете, что использовать статические переменные класса — это то же самое, что использовать глобальные переменные? (Риторический вопрос, я знаю, вы знаете)

Чтобы представить ситуацию в перспективе, если внутри ISR мы обновляем четыре нестатических переменных класса, мы все еще находимся в пределах разрешающей способности функции micros() на плате с частотой 16 МГц.

Так .. есть некоторые места , и некоторые очень специальные объекты , где класс статического вара может быть , имеет смысл , поэтому мы можем сжать один микро секунд.

Дамп был выполнен с помощью avr-objdump -F -S , когда двоичный файл распакован и вы делаете это внутри папки с исходным кодом, кажется, что это встроено.

Где бы вы использовали это, не находясь внутри экземпляра?

Я никогда не собирался поднимать тему » this » как вызывающую беспокойство. Все хорошо.

некоторые места и некоторые особые объекты, где static var

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

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

@jbrazio

Вы знаете, что использовать статические переменные класса — это то же самое, что использовать глобальные переменные? (Риторический вопрос, я знаю, вы знаете)

В ASM да, но главное преимущество перед глобальными переменными — это инкапсуляция и контекст пространства имен! Так что структура классов действительно правильная …

@jbrazio
Кстати: отличный анализ. Итак, теперь мы знаем, о чем говорим!

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

Тогда давайте измерим влияние … Я повторно воспользуюсь предыдущим ассемблерным кодом, потому что мы можем отлично видеть вызовы, начав с самого большого блока asm, который является кодом для a.foo(); , _нестатического метода_, мы делаем diff для блока a.bar(); asm, _static method_, конечный результат — это общие накладные расходы.

void aClass::foo() {
 (...)
 136: 1f 92         push  r1               ; 2 clk
 138: 1f 92         push  r1               ; 2 clk
 (...)
 13e: 9a 83         std Y+2, r25  ; 0x02   ; 2 clk
 140: 89 83         std Y+1, r24  ; 0x01   ; 2 clk
 [ignoring here the specific var type IO]
}
 (...)

Это оставляет нам 8 тактовых циклов, что означает 0,5 мкс (да… полмикросекунды ).

Некоторые эмпирические данные ..

Невозможно попытаться измерить части кода, которые мы обсуждали [вызовы методов / накладные расходы], поэтому я измерил время выполнения всего метода для статического и нестатического. Это не даст нам реальных чисел, но, по крайней мере, позволит пользователю увидеть разницу между одним типом вызова и другим в сравнении . Также важно отметить, что с Arduino минимальная разница во времени между двумя micro() составляет _4 микросекунды_, даже если между ними прошло меньше времени, пытаясь сравнять это. Я вызываю каждый метод 10000, чтобы я мог вычислить в среднем.

Тема текста.

class aClass {
  public:

  void foo() {
    return;
  }

  static void bar() {
    return;
  }
};

void setup() {
  Serial.begin(115200);

  aClass a;
  uint32_t s, e, j;

  const int32_t cycles = 10000;

  for (uint8_t i = 0; i < 5; i++) {
    s = micros();

    for (j = 0; j < cycles; j++) {
      a.foo();
    }

    e = micros();
    Serial.print("a.foo(): ");
    Serial.print((float) (e-s) /j);
    Serial.println("uS");

    s = micros();

    for (j = 0; j < cycles; j++) {
      a.bar();
    }

    e = micros();
    Serial.print("a.bar(): ");
    Serial.print((float) (e-s) /j);
    Serial.println("uS");

    Serial.println();
  }
}

void loop() {}

Какие выходы:

Welcome to minicom 2.7

OPTIONS: I18n 
Compiled on Feb  7 2016, 13:37:27.
Port /dev/ttyACM0, 17:36:00

Press CTRL-A Z for help on special keys

a.foo(): 4.42uS
a.bar(): 3.48uS

a.foo(): 4.43uS
a.bar(): 3.48uS

a.foo(): 4.43uS
a.bar(): 3.48uS

a.foo(): 4.43uS
a.bar(): 3.48uS

a.foo(): 4.43uS
a.bar(): 3.48uS

Заключение: эмпирическая разница на вызов метода составляет ~ 0,95 мкс, что приводит меня к выводу, что мое предыдущее аналитическое предположение о 8 тактовых циклах путем «сравнения» не является точным на 100%.

У меня была аналогичная ошибка контрольной суммы при 60 мм / сек и выше. @ 50мм / сек почти не осталось. @ 40мм / сек все было под контролем. изменение скорости передачи не повлияло. Он ушел, но вернулся в 8aa594c в меньшей степени. 60 сейчас почти хорошо.

Я хочу вложить свои 2 цента вместе с тем, что я подозревал, подтвержденным кем-то другим в отношении проблемы случайного превышения температуры, которую я наблюдал при использовании термопар MAX31855 и MAX6675.

https://github.com/Smoothieware/Smoothieware/issues/894

Проблема вполне может быть связана с высокими электромагнитными помехами от шаговых двигателей, влияющих на линии SPI.

Это было бы почти невозможно исправить в прошивке, поскольку это проблема с заземлением / защитой оборудования.

@Grogyan, эта проблема здесь определенно не EMI, ее довольно легко воспроизвести с разными кодовыми базами и включением / отключением LIN_ADVANCE. ЦП просто перегружен и не может вовремя обрабатывать входящие символы, в зависимости от конфигурации и версии Marlin.

@ Sebastianv650 Интересно, если бы вставка следующего кода в цикл advance_isr steps сделала бы последовательное соединение более надежным … или это только замедлило бы другие вещи …

#ifndef USBCON
  customizedSerial.checkRx(); // Check for serial chars.
#endif

я по-прежнему считаю, что петли слишком велики, и программное обеспечение не может достаточно быстро обслуживать последовательный поток. Дело не в надежной последовательной связи.
Когда я запускаю принтер на скорости 40 мм / сек или меньше, я не получаю ошибок. Чем быстрее он работает, тем больше ошибок я получаю, особенно при заполнении сотовой структурой. Ошибки указывают на пропуск шагов и, следовательно, возврат неправильного ответа. Его необходимо протестировать с интенсивным потоком команд на любой максимальной скорости, которую вы хотите указать Marlin. ЧТО, кстати, я не вижу указанного. S / W — это не только функции, и я не думаю, что это оборудование ограничивает скорость — думал, что это может иметь какое-то отношение к Arduino. Но я считаю, что прошлые выпуски работали нормально. Это было так давно, я уже не могу вспомнить наверняка. Вероятно, текущая выпущенная сборка 1.0.2

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

@ruggb Да, у нас уже есть консенсус по этому

Мне также были бы интересны любые идеи о том, как мы можем собрать информацию о времени и получить некоторое представление о том, насколько велика нагрузка, сравнивая различные флаги оптимизации.

Когда я запускаю принтер на скорости 40 мм / сек или меньше, я не получаю ошибок

Это декартово исполнение?

какую бы максимальную скорость вы не указали, на которую способен Марлин. ЧТО, кстати, я не вижу указанного

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

S / W — это еще не все функции

При интеграции новых функций, во-первых, они по умолчанию отключены. Во-вторых, они не должны мешать работе. Другими словами, мы стараемся, где это возможно, не переписывать более общий код только для его адаптации. Таким образом, хотя в очереди есть некоторые новые функции, которые влияют на то, как управляются степперы, и мы обернули степперы в класс, низкоуровневый код для степпинга остался почти таким же. Кое-где мы объединили исправления (например, исправление ускорения от Printrbot), которые добавляют немного больше накладных расходов Планировщику. Но мы хотим, чтобы низкоуровневые пошаговые функции оставались максимально производительными.

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

прошлые выпуски работали нормально

Я уверен, что выпуск 1.1.0 тоже будет отличным. Мы не перегружали пошаговые подпрограммы «функциями», но у нас есть более надежный код во многих местах, а в некоторых случаях он может быть медленнее.

Это декартово исполнение?

Нам лучше иметь возможность делать декартову шкалу со скоростью 40 мм / сек!

@thinkyhead Я играл с дополнительной позицией checkRX, когда этот поток был запущен, без особого успеха.
Но, как я уже писал ранее (https://github.com/MarlinFirmware/Marlin/issues/3680#issuecomment-219460929), я не думаю, что важно, чтобы Marlin мог обрабатывать 250000 бод, пока другие вычисления для новой строки сегментные и шаговые ISR не способны обрабатывать такой большой объем входных данных. Вот почему я перестал экспериментировать с ним и сейчас у меня скорость 115200 бод.

До сих пор я не мог найти реального потенциала улучшения в команде Planner::buffer_line , которая, на мой взгляд, является самой тяжелой.

это самая тяжелая команда, я думаю

Функции вне шагового ISR действительно некритичны и не связаны со скоростью движения. Я уверен, что мы получаем достаточно «отрезков линий в секунду» в планировщике, особенно на декартовых машинах, где линии обычно оставляют на всю длину. Основная проблема заключается в количестве времени, которое остается функциям ISR, чтобы они не сталкивались сами с собой, не занимали все время основного цикла и не мешали друг другу.

Мы не совсем «раздули» шаговый ISR, но я уверен, что он потребляет больше циклов процессора, чем шаговый ISR в Marlin 1.0.2-1. Так что нам действительно нужно найти как можно больше стратегий, чтобы снизить здесь нагрузку и, если возможно, сделать шаговый ISR даже быстрее, чем в 1.0.x.

_ «Чтобы ускорить, сделайте меньше.» _

Итак, я смотрел последний код Grbl… чтобы увидеть, где они оптимизировались с тех пор, как Marlin впервые от него отделился. Но это сложно! Может быть проще оптимизировать то, что у нас есть, или просто взять каждую из их идей по крупицам.

@thinkyhead посмотрите на github / grbl базу для марлина, которая только что выпустила новую версию. 0,9j

(x4) + Faster Planner: планирование вычислений улучшилось в четыре или более раз за счет оптимизации> сквозных операций, которые включали оптимизацию вычислений и введение> указателя планировщика, чтобы определить местонахождение неустранимых частей буфера и не тратить циклы> пересчитывая их.

Этот код работает на скорости передачи данных @ 1153200, которую я использую для запуска своего китайского лазерного резака k40. Я погрузился в код еще с тех пор, как был занят своими домашними проектами, включая преобразование k40. Однако когда у меня будет время, я сравню и посмотрю, какой трюк они используют для достижения таких огромных улучшений.

отправлено с моего айпада

26 июня 2016 г. в 9:14 Скотт Лахтейн [email protected] написал:

это самая тяжелая команда, я думаю

Функции вне шагового ISR действительно некритичны и не связаны со скоростью движения. Я уверен, что мы получаем достаточно «отрезков линий в секунду» в планировщике, особенно на декартовых машинах, где линии обычно оставляют на всю длину. Основная проблема заключается в количестве времени, которое остается функциям ISR, чтобы они не сталкивались сами с собой, не занимали все время основного цикла и не мешали друг другу.

Мы не совсем «раздули» шаговый ISR, но я уверен, что он потребляет больше циклов процессора, чем шаговый ISR в Marlin 1.0.2-1. Так что нам действительно нужно найти как можно больше стратегий, чтобы уменьшить здесь нагрузку и, если возможно, сделать шаговый ISR даже быстрее, чем в 1.0.2.

«Чтобы сделать это быстрее, сделайте меньше».

—
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите обсуждение.

@thinkyhead Моя машина — доморощенный CoreXY с Arduino Mega 2560 и Ramps 1.4 — я понятия не имею, на что она способна сама по себе. Но похоже, что он будет работать 120-150, может быть, даже 200.

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

МОЖЕТ БЫТЬ решена неправильная проблема из-за пропущенных шагов и ошибок ????
У меня создалось впечатление, что Марлин сделал паузу, когда больше не мог принимать команды. Если это так, он должен остановить ошибки связи и пропущенные шаги, поскольку Repetier не будет отправлять пропущенные команды и ждать неправильного ответа. Если обработка команд выполняется медленно и / или оборудование работает медленно, это просто ограничивает скорость и не приводит к нарушению модели из-за пропущенных шагов и сообщений об ошибках. Если Марлин не делает своевременную паузу, то шаги пропускаются и возникают ошибки. Возможно, более низкая максимальная скорость BAUD даст Марлину достаточно времени для ответа — хотя это не идеальное решение.

RE много данных —
Если скорость Marlin указана относительно «СТАНДАРТНОЙ» платы (какой бы она ни была), и вам не нужно беспокоиться о получении данных с большого количества оборудования. Если моя доска или компьютер работает медленнее, то я знаю, где находится узкое место. Если он быстрее, то я знаю, что он справится со всем, что может дать Марлин.

Если функция влияет на время обработки команды печати, вам необходимо указать ограничение скорости. IE., Использование этой функции ограничивает скорость печати до 50 мм / сек.

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

@ruggb , это не так просто. Марлин может остановить передачу, если буфер заполнен, но проблема не в этом. Ошибки возникают в течение одной передачи, когда буфер не заполнен. В качестве примера возьмем G1 Y20 F2000. Марлин говорит: ОК, еще одна команда! Затем хост начнет отправлять G1 Y20 F2000, каждый символ с шагом времени 40 мкс (= 250000 бод) — Marlin не может сейчас остановить этот поток. Последовательное прерывание имеет очень низкий приоритет, поэтому, если есть другие запущенные прерывания, они будут вызываться первыми. Если требуется чуть больше 40 мкс, прежде чем Марлин найдет время, чтобы снова прослушать последовательный порт, символ теряется. Теперь строка, например, читается как «G1 Y2 F2000».
Единственный шанс решить эту проблему — сделать все ISR как можно меньше и быстрее.

Все платы, на которых работает Marlin, должны работать почти с одинаковой скоростью, потому что все используют одно и то же семейство ATMEGA с частотой 16 МГц. Только такие вещи, как используемый тип отображения и включенные параметры, должны значительно изменить скорость выполнения.

Я думаю, что невозможно повлиять на скорость работы функции. Некоторые функции будут взаимодействовать друг с другом, поэтому функция A может снизить мощность до 99%, функция B может дать 98%, но обе могут не дать 99 * 98% .. Даже если вы хотите указать число, это не будет мм / сек. . Действительное число может быть только частотой в сочетании с ограничением, например:

• Максимум. скорость движения без новых отправленных команд: 30 000 шагов / сек.
• Максимум. новых команд в секунду, при длине команды 30 символов и отсутствии активного шагового ISR: 200 / с

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

Система CoreXY повлияет на максимальную скорость печати (обработки команд)

Это правда. Есть некоторые дополнительные вычисления для COREXY на уровне шагового двигателя. Кроме того, машины COREXY задействуют шаговые двигатели намного больше, чем декартовы машины. Самое замечательное в CoreXY заключается в том, что во многих случаях вы можете использовать степперы с низким крутящим моментом, потому что CoreXY перемещает степперы как быстрее, так и в сочетании. Это приводит к гораздо большему количеству шаговых импульсов в секунду и, таким образом, оказывает влияние на шаговый ISR и, таким образом, дополнительно ограничивает вашу максимальную скорость. Возможно, вы даже сможете получить на 50% — 100% более быструю печать на декартовой системе координат по сравнению с CoreXY на том же процессоре.

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

@ Sebastianv650 — спасибо, отличное объяснение. Так что, если я уменьшу скорость передачи данных, когда увеличу SPS более 60 мм / с, это действительно может помочь уменьшить количество пропущенных шагов. Это может замедлить его в некоторых областях, но насколько быстрой должна быть скорость передачи данных, без учета ISR, чтобы поддерживать, скажем, 100 мм / сек?

Вы можете печатать со скоростью 100 мм / с с любой скоростью передачи. Как только команда будет передана (даже если это займет несколько минут), принтер выполнит ее со скоростью, заданной параметром F. Вопрос в том, сколько точек вы должны выполнять в секунду, и это зависит от вашего разрешения stl, настроек слайсера и скорости печати. Если вы пытаетесь пройти более 100 точек из-за круга в пределах 1 секунды, вы должны быть уверены, что можете передавать 100 команд в секунду через последовательное соединение. Опять же, это зависит от вашей средней длины команды, потому что скорость передачи дает вам «символов в секунду», и ваша команда может иметь различное количество символов ..

Таким образом, у вас есть два варианта, если вы хотите знать это точно: сделать пробную распечатку и найти наилучшие значения или попытаться сделать предположение на основе вычислений в Excel. Выбор за вами, однозначного ответа нет

Это исправлено? было ли это протестировано с RC7?

Всем привет, я установил RC7, и я думаю, что столкнулся с этой проблемой на PrintrBoard Rev F. Я установил его на 115k бод, контрольную сумму (на Octoprint), и даже простое перемещение кровати (не во время печати ) приводит к тому, что звучит как пропущенный шаг, но на самом деле это что-то в прошивке. Есть идеи, что еще я могу сделать, чтобы отладить это?

@lucacri Чтобы RCBugFix . Со времен RC7 было выпущено множество патчей, так что лучше начать с этого места. Попробуйте и посмотрите, как он себя ведет. Тогда мы можем смотреть дальше.

Если вы обнаружите, что проблема все еще существует, опубликуйте свои файлы Configuration.h и Configuration_adv.h . Вы можете просто сделать из них ZIP-архив и добавить в свой ответ.

Всем привет, я установил RC7, и я думаю, что столкнулся с этой проблемой на PrintrBoard Rev F. Я установил его на 115k бод, контрольную сумму (на Octoprint), и даже простое перемещение кровати (не во время печати ) приводит к тому, что звучит как пропущенный шаг, но на самом деле это что-то в прошивке. Есть идеи, что еще я могу сделать, чтобы отладить это?

@lucacri Могу я попросить вас отправить сообщение людям, занимающимся PrintRboard, и сказать им, что их отсутствие интереса к работе с последней версией Arduino на их плате вызывает недовольство клиентов? Вы можете указать им на это сообщение и попросить их ответить на него. Они говорят людям использовать Arduino V .22, и они думают, что это квалифицируется как «поддержка Arduino».

Команда Marlin изо всех сил старается поддерживать любое оборудование, на котором запускается Marlin. Но поставщик оборудования, который отказывается обновлять поддержку своего компилятора чаще, чем каждые 3 года, очень затрудняет серьезное отношение к нему. Вы можете предложить сотрудникам PrintRboard связаться с нами и спросить, что нам нужно, чтобы лучше поддерживать их клиентов. Будем рады диалогу с ними. Но печальная правда в том, что они даже не хотят тратить несколько дней на то, чтобы запустить последнюю версию Arduino на своей плате. (И поверьте мне … Я знаю … У меня есть PrinteRboard, который я собираюсь заменить на RAMPS, потому что он работает с последней версией Arduino !!!!)

Прямо сейчас мой совет всем, кто готов слушать: НЕ ПОКУПАЙТЕ Печатную доску !!!! У вас будут проблемы, потому что компания на самом деле не заботится о ее поддержке. Их интересует только обналичивание вашего чека.

@thinkyhead Спасибо за помощь! Я загрузил сюда свои configuration.h и configuration_adv.h.

Мне не было известно о ветке RCBugFix, поэтому я просто перекомпилировал прошивку и загрузил ее в Play. Я печатаю Benchy с теми же настройками, что и раньше, надеюсь, у меня не появятся «прыщики» на прямых линиях. Я должен сказать, что если эта проблема будет исправлена, благодаря LIN_ADVANCE у меня будут самые красивые отпечатки, которые у меня когда-либо были. Отличная работа, ребята!

@ Roxy-3D вау, я не знал, что ситуация такая сложная! Я думал, что Printrbot разветвлял Marlin только для того, чтобы они могли указать пользователям, чтобы они делали более легкую компиляцию … Я ошибаюсь, даже попробовав на нем vanilla Marlin?

LIN_ADVANCE — тоже мой любимец. @ Sebastianv650 проделал отличную работу, собирая и тестируя его. Я только что отправил PR сегодня, чтобы помочь немного оптимизировать его, особенно для смесительных экструдеров.

вау, я не знал, что ситуация такая сложная! Я думал, что Printrbot разветвлял Marlin только для того, чтобы они могли указать пользователям, чтобы они делали более легкую компиляцию … Я ошибаюсь, даже попробовав на нем vanilla Marlin?

@lucacri Я думаю, что это даже сложнее, чем то, что только что было раскрыто. Частично проблема состоит в том, что группа Arduino разделена на две конкурирующие половины, и обе продают аппаратные платы. Они обеспечивают поддержку множества различных плат, которые продают, но продавцы конкурирующих плат напрямую не поддерживаются. И поскольку IDE компилятора изменяется, эти файлы поддержки платы необходимо обновить.

Я думаю, что разработчики PrinteRboard запустили свой файл платы 3 года назад с версией .22 и никогда не оглядывались назад. Они просто говорят использовать Arduino v.22, но с тех пор было исправлено множество ошибок компилятора. Если вы ослабите «проверку работоспособности», которая мешает Marlin компилировать с версией 22, вы, вероятно, столкнетесь с проблемами синтаксиса, которые также необходимо устранить. Я столкнулся с некоторыми проблемами синтаксиса, когда препроцессор просто менял с версии 1.6.8 на версию 1.6.9.

@thinkyhead Хорошо, я сделал два отпечатка: один с RC7 и один с RCBugFix. Вот результаты

Как видите, особой разницы нет. Я получаю массу «прыщиков», и это не при смене слоя (смена слоя происходит в том же месте на задней стенке скамейки, чтобы удалить переменную), а на прямых линиях.

Есть подсказка, что это может быть?

@ Roxy-3D Я знаю о войне с Arduino, но в этом случае мне удалось без проблем скомпилировать прошивку на 1.6.0. Мне просто очень повезло ??

Я знаю о войне с Arduino, но в этом случае мне удалось без проблем скомпилировать прошивку на 1.6.0. Мне просто очень повезло ??

Я предполагаю, что вы используете внешний программатор. Потому что без соответствующих файлов платы Arduino не может прошить микросхему AVR. Если это работает для вас, это здорово!

Я использую Arduino 1.6.9, Teensyduino 1.29 и PrintrBot Firmware Update для отправки файла (вы перетаскиваете .hex на значок, и он отправляет его). Это похоже на вашу среду?

@thinkyhead Я пробовал ваш PR # 4738, но все равно получаю те же идентичные результаты. Я даже попробовал другой цвет и марку PLA, и Benchy, как и раньше, получился неровным. Есть ли другие предложения о том, что я могу сделать? Я тоже разработчик, так что если мне нужно погрузиться в код, я сделаю это!

А если серьезно, то LIN_ADVANCE — это сдвиг парадигмы в 3D-печати. Если мы это сделаем, это будет просто plug-and-play

@lucacri Я не ожидал большой разницы с # 4738. Это больше просто уборка. Вы пробовали использовать разные рулоны нити? Иногда неровности являются признаком наличия воды или других примесей в нити, вызывающих резкие скачки давления. Кроме того, не могли бы вы опубликовать пару фотографий результатов печати, чтобы мы могли лучше диагностировать? Пятна на острых углах или в начале / конце хода, скорее всего, связаны с дополнительными настройками.

Я пробовал с двумя разными рулонами (красный — последний отпечаток). Обе нити отлично работали с предыдущей прошивкой (майская версия printrbot).

Вы можете увидеть результаты здесь: https://imgur.com/a/d1rjE

Я удалил переменную смены слоя / конца / начала цикла, разместив ее на передней части корабля. Таким образом, любая неровность, которую вы видите, это просто движение сопла, затем его дергание на долю секунды и повторный запуск. Это происходит, даже когда я отправляю команду G0 / G1, перемещаясь с одной стороны кровати на другую (ось X или Y, не имеет значения)

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

В configure.h есть масса переменных. Есть ли такой, который упрощает вычисления на процессоре? Не знаю, что-то вроде MIN_STEPS_PER_SEGMENT или SERVO_DELAY? На самом деле, я плюю сюда, ха-ха

Вау, это очень неровно, хорошо.

когда у меня были такие проблемы, я обнаружил, что настройки ускорения и рывков вместе с темпом решают проблему.
Хотя с RC7 f / w этого не было.

@ruggb Я их обоих опустил (до ползания) но без изменений

Я следую этому принципу — минимальный уровень не обязательно улучшает его.

Основная причина отпечатков с пятнами в углах и других местах — это низкий параметр РЫЧАГ. Если вы увеличите настройку JERK, вы увидите, что капли исчезнут. Если он установлен слишком высоко, по углам будет звенеть.

рывок = 20-30% скорости печати >> скорость печати 60 мм / сек = рывок 15 мм / сек
M205 X ## для изменения + M500 для сохранения

Ускорение — установите медленную скорость печати == M203 X100 Y100
Установить дифференциал для подвижной кровати — то же для CoreXY == m201 X9001 Y9001
Тестовая деталь со 100% прямоугольным заполнением == без потери шагов, увеличьте на 20% и попробуйте снова
Оставьте запас прочности 20% от критического значения.

Скорость — никогда не будет намного выше 200 мм / сек, особенно с короткой станиной
Параметр F — мм / мин, поэтому для проверки используйте G1 X335 F12000

Рывок E и ускорение используются во время втягивания, поэтому они важны и оказывают определенное влияние на печать. Для Tantillus я установил ускорение на 10000 для E и толчок на 100 из-за необходимости втягивания троса Боудена на 5,5 мм, и мы хотим, чтобы это происходило мгновенно. Это может не работать для большинства принтеров, поскольку на машине Боудена упругости нити достаточно для очень быстрого ускорения экструдера назад и предотвращения пропуска шагов при втягивании.

Я считаю, что это необходимо повторно открыть, поскольку это все еще проблема с d63230d73e710b6ebc8b77fc99f9571687852f12. Подключаюсь к принтеру со скоростью 115 кбит / с, печатаю через Printrun. В основном я просто вижу ошибки «контрольной суммы» и «номера строки» (может быть, несколько десятков за час активной печати), но иногда я получаю сбой, когда X или Y внезапно просто перемещаются к одному краю объема печати (после чего , печать возобновится в обычном режиме).

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

Ничего особенного, просто LIN_ADVANCE и, как вы уже догадались, выравнивание кровати (3 балла).

Однако, если я подниму MINIMUM_STEPPER_PULSE (до 8; обычно у меня установлено значение 4, так как LIN_ADVANCE в противном случае приводит к потере шагов у моего экструдера), ура, серийные ошибки проходят через крышу, принтер заикается при попытке печати и практически не может сделать ничего полезного.

Может, нам стоит начать новую тему — эту перепутали с другими вещами ……….
НО я по-прежнему придерживаюсь мнения, что Марлин пытается сделать слишком много — или он не может делать то, что ему нужно, в промежутках между командами. Снижение скорости передачи данных может помочь, но не решит проблему. У меня сработало снижение скорости печати — до тех пор, пока Марлину не было добавлено больше вещей, которые он мог бы делать между командами. Возможно, единственное решение — это больше мощности оборудования и больше оперативной памяти.
ИМХО, ошибка связана с тем, что принтер пропускает команду, а затем отвечает на следующую команду, в то время как компьютер ждет ответа от предыдущей. Модель явно показала результат пропущенных команд.

@VanessaE Бьюсь об заклад, причина в том, что MINIMUM_STEPPER_PULSE увеличит продолжительность каждого шагового ISR, и поэтому вероятность пропуска символа гораздо выше.

@ruggb Боюсь, что если мы создадим новую
Повышенная скорость процессора может снизить частоту ошибок (поскольку ошибки почти никогда не видны), но недостаток находится внутри конструкции. Если шаговый ISR блокируется в нужное время, и это занимает так много времени, что следующий символ уже поступает, когда ISR завершается, ошибка неизбежна.

Символы могут потеряться, если (E_step_loops * pulse_length > 1 / (baudrate / 10))

Может быть

    #ifndef USBCON
      customizedSerial.checkRx(); // Check for serial chars.
    #endif

внутри петли помогает. В идеале между запуском и остановкой импульсов.

Я думаю, возникает очевидный вопрос: достаточно ли у оборудования мощности для одновременного запуска как ISR, так и обработки потока данных ввода-вывода? Если нет, то есть три варианта:

1. Требуется более высокая производительность H / W для запуска Marlin. — это, вероятно, не переборщит с пользователями.
2. Исключите функции, которые мешают ISR — это не доставит удовольствия пользователям.
3. Сделать код более эффективным — это может стать БОЛЬШОЙ проблемой для разработчиков.
   Я полагаю, что @thinkyhead указал в предыдущей
   Есть ли в коде накладные расходы на отключенные функции?

Я не считаю это основной проблемой вычислительной мощности, поскольку @ Blue-Marlin доводит ее до сути. Если бы мы могли сказать ATMega, что последовательная связь имеет более высокий приоритет, чем шаговая ISR, и что она должна прерывать шаговую ISR, не было бы проблем. Но это невозможно. Размещение некоторых checkRX() на хороших позициях внутри шагового ISR может сработать.

При расчете Blue Marlins существует предел 87 мкс при 115200 бод и 40 мкс при 250000 бод.
На данный момент шаговый ISR занимает около 50 мкс, поэтому, работает ли 250 кбод, более или менее зависит только от того, насколько вам повезло.

@ruggb только отключение функций, которые выполняют вычисления внутри шагового ISR, может минимизировать частоту ошибок. Их немного: MIXING_EXTRUDER , LIN_ADVANCE , ADVANCE и MINIMUM_STEPPER_PULSE . Каждый из них добавит несколько мкс, если включен.

У меня создалось впечатление, что в коммуникаторе было что-то вроде DSR, так что хост ждал, пока принтер не будет готов принять данные. Это строка ответа, и если да, то отправляет ли ее Марлин преждевременно?

IE вместо того, чтобы отправлять его, как только он получит команду, он должен подождать, пока он не будет готов передать другую команду — и это связано с заполнением буфера.

Раньше мы использовали RTS / CTS для управления потоком на старых 8-битных процессорах с быстрыми модемами — здесь такое существует?

Нет.
У ардуино всего две линии (RX, TX). Для аппаратного рукопожатия потребуются еще два.

В одном из этих потоков кто-то сказал, что при заполнении буфера хосту было отправлено сообщение для ожидания.
Если это правда, то в этом процессе может быть проблема. Как будто он отправляет ожидание ПОСЛЕ того, как буфер заполнится, а хост получает его ПОСЛЕ того, как хост отправил другую команду. Может случиться так, что ему нужно отправить сообщение ДО того, как буфер заполнится, и позволить другой команде или двум быть rcvd.
Просто догадываюсь …….

@ Sebastianv650 Я понимаю, что — я не говорил о персонажах, я имел в виду сообщения или команды — я думаю.

Ухх. Это больно. Вы не могли ошибаться.
Марлин отправляет «ОК», когда он выполнил команду или поставил ее в очередь. Это сигнал хосту для отправки следующей команды. Большинство хостов делают некоторые предположения о том, насколько глубоки буферы Marlins, и отправляют «некоторый» код вперед.

Пожалуйста, посмотрите это.

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

ISR экструдера занимает всего несколько мкс. На самом деле он такой короткий, что я не мог его измерить.
Когда я читал ваш ответ, у меня возникла идея … Может быть, не очень хорошая, но, может быть, нам стоит подумать об этом. Что, если бы мы сделали что-то вроде этого в начале шагового ISR:

• Отключите все ISR, кроме UART ISR
• Снова включить глобальные ISR: sei ()
• Если сейчас происходит событие UART, оно может прервать работу шагового двигателя.
• В конце шагового ISR снова включите все отключенные ISR (восстановите регистр, сохраненный ранее)

Это было бы не так хаотично, как настоящая неблокирующая ISR, но не следует терять символы ..

Марлин отправляет «ОК», когда он выполнил команду или поставил ее в очередь.

@ Blue-Marlin Вот каково мое восприятие. Вопрос в том, что произойдет, если Марлин не отправит ОК? — есть ли тайм-аут?

хост отправляет cmd, marlin отправляет OK, хост отправляет cmd, Marlin пропускает его, время ожидания, хост отправляет другой cmd, Marlin отправляет OK, ошибка генерируется, потому что номер строки был для пропущенного.
Если нет, я не вижу, как генерируется эта ошибка == Error:Line Number is not Last Line Number+1

Если есть тайм-аут, то я говорю, что, возможно, просто гарантирую, что Marlin сможет принять следующую команду b4, он отправит OK, а не отправка OK только потому, что он поставил команду в очередь, решит проблему.

И если в этом нет смысла, то это потому, что я понятия не имею, как это действительно работает.

Я полагаю, что @thinkyhead указал в предыдущей

Кажется, что всегда есть больше возможностей для оптимизации. Предварительный расчет значений в планировщике. Замена деления умножением в ISR. Такие вещи. Будет полезно продолжить профилирование шаговой ISR, чтобы увидеть, где можно сделать улучшения и где лучше всего вызвать checkRx() . Может быть, не в начале ISR, а где-то посередине.

По этому поводу я вижу, что checkRx() вызывается для каждого цикла в for (int8_t i = 0; i < step_loops; i++) { . . . } . А сам вызов checkRx() добавляет некоторые накладные расходы. Может, его нужно вызывать только при i & 1 == 1 ?

Жаль, что это не может быть вызвано между началом и остановкой импульса. Это устранило бы необходимость в MINIMUM_STEPPER_PULSE в этот момент. Но я думаю, что звонок на checkRx() на самом деле сделает импульсы слишком длинными.

Я не вижу, как возникает эта ошибка == Ошибка: номер

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

Недавно у меня была такая же проблема. из-за плохого USB-кабеля я купил экранированный, и теперь все работает нормально.

Хм. Я использовал бета-версию Cura 4.0.0 и Slic3r 1.3.1-dev для отправки заданий через последовательный порт (USB) на Ender 3. Может быть, несколько десятков отпечатков, без ошибок. В Slic3r заметил сообщение «Номер строки не номер последней строки + 1» в последовательном тексте, но он отображал его только один раз при подключении к принтеру и, похоже, после этого работал нормально. Еще ни разу не провалился в середине печати. Итак, исследование этой ошибки показало, что это большая потенциальная проблема, поэтому было решено создать и загрузить последнюю версию 1.1.9 Marlin bugfix fw. Теперь у Slic3r есть бесконечный запас «Номер строки не номер последней строки + 1», и он отказывается что-либо печатать. Хотя от Cura печатает нормально!

@ mj1911
Код, относящийся к этому, несколько раз менялся с момента этого обсуждения — 2 года назад.
Пожалуйста, откройте для этого новый выпуск. Если возможно с некоторыми журналами вокруг ошибки.

В случае, если это помогает, я вижу эту ошибку как непрерывную, когда она происходит, каждое сообщение не выполняется на 115200. Я считаю, что закрытие слайсера и сброс принтера устраняют проблему. Кажется, это происходит только тогда, когда я запускаю программу слайсера в некоторых, еще не определенных ситуациях. Я видел, как это начинается сразу после начала новой печати, голова будет как какое-то случайное пятно на поверхности, и каждое сообщение, отправленное слайсером, не работает. Пока это произошло только на первом уровне.

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

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

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