Full graphic smart controller не работает

Re: Marlin Проблема при подключении графического контроллера

mixasty » 15 апр 2014, 18:39

Re: Marlin Проблема при подключении графического контроллера

EASY_ » 16 апр 2014, 00:28

А какой Марлин?
У меня запустилось сразу.

UncleSam писал(а): Приобрел себе вот такого зверя

Как в инструкции скопировал либу U8glib в ардуино из аддона.
раскоментировал строку.
#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER //(без этой строки все работает нормально).

Скомпилировал, зашил в плату, на выходе имею вот такое.

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

Делаю 3D модели по вашим эскизам/идеям/описаниям.

Re: Marlin Проблема при подключении графического контроллера

Iro4ka » 04 авг 2015, 23:24

Так какой Марлин? У нас с этим экранчиком пока даже прошивка не компилируется. Библиотеку U8glib загрузили. Куда копать?

Добавлено спустя 35 минут 59 секунд:
На всякий случай сама себе отвечаю — надо было скачать отсюда новую версию библиотеки https://bintray.com/olikraus/u8glib/Arduino , и сразу всё заработало.

Re: Marlin Проблема при подключении графического контроллера

Maxer » 05 авг 2015, 06:24

Re: Marlin Проблема при подключении графического контроллера

Iro4ka » 05 авг 2015, 07:56

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

Re: Marlin Проблема при подключении графического контроллера

ales2k » 05 авг 2015, 17:48

Re: Marlin Проблема при подключении графического контроллера

Maxer » 07 авг 2015, 12:17

Re: Marlin Проблема при подключении графического контроллера

xm32 » 09 авг 2015, 14:12

Re: Marlin Проблема при подключении графического контроллера

holomrn » 09 авг 2015, 14:57

Re: Marlin Проблема при подключении графического контроллера

xm32 » 09 авг 2015, 15:01

положил и один фиг ругается

Marlin.ino:44:101: fatal error: U8glib.h: No such file or directory

покидал повсюду куда только можно вроде схавало. Сейчас допечатает пойду проверять.

Источник

[BUG] FULL_GRAPHIC_SMART_CONTROLLER problem #15833

Comments

TreeTwo27 commented Nov 7, 2019

Description

Steps to Reproduce

Required: Please include a ZIP file containing your Configuration.h and Configuration_adv.h files.

1. [First Step] Set the value of delta and 12864lcd on the skr1.1 board before installing Marilyn 2.0.
2. [Second Step] I checked there was a problem with the LCD screen. And when I turned the knob, there was a reaction. After that, I manipulated the printer with printrun and it worked normally.
3. [and so on. ] I searched Google for similar symptoms, but I couldn’t find them. When I connected 12864lcd to another printer, I found that it reacted normally. Is it possible that the skr1.1 board had an initial defect?

Expected behavior: [What you expect to happen] I tried to safely apply the firmware, turn on the printer, and operate it.

Actual behavior: [What actually happens]Lcd 12864 is a strange screen showed.
If you move the knob, it will react. There’s nothing wrong with the print run. Applying the lcd to another printer did not show the same symptoms



Marlin.zip

Additional Information

• Provide pictures or links to videos that clearly demonstrate the issue.
• See How Can I Contribute for additional guidelines.

The text was updated successfully, but these errors were encountered:

3Dangel commented Nov 7, 2019

This is what I use .
it is from another forum’s member who’s coding ..
#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER
#define ST7920_DELAY_1 DELAY_NS(125) //these help keep the display from being weird
#define ST7920_DELAY_2 DELAY_NS(125)
#define ST7920_DELAY_3 DELAY_NS(125)
#endif

try and see if any help

ruggb commented Nov 8, 2019

I already opened this bug on #15745

thisiskeithb commented Nov 8, 2019

It’s not clear they were the same issue.

ellensp commented Nov 8, 2019

I tried this on a SKR 1.3 and a geeetech clone of the RRD GLCD (Closest I have, same MPU)

Using the latest marlin bugfix 2.0, changed #define MOTHERBOARD BOARD_BIGTREE_SKR_V1_3 and #define SERIAL_PORT -1
Then enabled the lcd #define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER. Updated .platformio with default_envs = LPC1768
Made no other changes
It works fine.
NB with this clone display you do need to flip the cables on the back of this display 180 degrees to work on the SKR 1.3, but you get nothing if you don’t do this, not a scrambled screen.

So this may be SKR 1.1 specific.

TreeTwo27 commented Nov 8, 2019 •

이것이 내가 사용하는 것입니다.
그것은 .. 코딩있어 다른 포럼의 멤버 출신
#DEFINE REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER
#DEFINE ST7920_DELAY_1 (125) //이 도움이되는 것을 표시를 유지 DELAY_NS 이상한
#DEFINE ST7920_DELAY_2 DELAY_NS (125)
#DEFINE ST7920_DELAY_3 DELAY_NS (125)
#endif 다음을

시도하고 도움이 있는지 확인하십시오

I tried to add it, but it didn’t work out. There was no change in the symptoms.

ruggb commented Nov 8, 2019

It’s not clear they were the same issue.

How do we clear that up? Multiple people, different configs, same display, very similar symptoms == scrambled display. The only diff is they are not all scrambled the same way. Yeah, I guess that makes them diff issues. But for one, they all corrected with the same patch. And the patch was posted on a diff forum. Maybe you need to get that person on your team.

3Dangel commented Nov 8, 2019

Treetwo27
Have you set your Marlin to work on another language? Or it is “en”?
Also, there were different set ups as for the serial port.
Try to modify the serial ports and see if that helps.

thisiskeithb commented Nov 8, 2019

By including configs when opening an issue like the issue template asked 🙂

Otherwise, we’re left trying to guess which hardware config this fix applies to.

AnHardt commented Nov 8, 2019

This is clearly a timing problem.
If the already mentiond delays do not work even when doubled, tripled you can try to define

#define DOGM_SPI_DELAY_US 5 (Configuration_Adv.h)

with increasing values up to about 10.

Also improving the hardware may help.
Shorter, better shielded cables.
Large capacitor between Vcc and GND on the display.
.

If you can see, what you see, your display is connected correctly. Maybe check at the display if Vcc is 5V.

ruggb commented Nov 8, 2019

By including configs when opening an issue like the issue template asked 🙂

Otherwise, we’re left trying to guess which hardware config this fix applies to.

why was this confirmed as a BUG if the info was insufficient?

@AnHardt
ALSO, why is this now a hardware issue, when previous versions of Marlin worked fine? = FOR MANY PEOPLE. I know, it is because you are a software person, right?

AnHardt commented Nov 8, 2019

Because it was always a hardware issue. The ST7920 is slow and picky about signal and power quality.

In theory at 5V a 16MHz AVR needs half a NOP delay in ST7920_DELAY_3 and nothing else.
In practice all of my various ST7920 based displays (7) do work completely without delays (On MEGA + RAMPS 1.4 + smart adapter + 200 mm standard flat cables.)

At the 20MHz AVRs one NOP is required in ST7920_DELAY_3 else you’ll see this typical noise on shreen.
If i remember correctly next was adding more delays for MELZI boards. We never properly investigated why these boards (16MHz AVR) behave worse than Arduino MEGA with RAMPS. But we also could not find Melzis working without delays.
Later we added more delays for other boards.
For the faster 32bit processors the reason is clear. The additional increased delays for 3.3V systems are also obvious (see ST7920 datasheet).

Others reported to see noise on long cables and fixing this with more delay.
Others reported to fix noise by shielding the cables and being able to reduce the delays again.
Others reported stabilizing Vcc by a capacitor helped to reduce the delays.

My conclusion:
You can fight a wide range of noise (signal/power quality) issues with additional delays.
By improving the signal/power quality you can reduce the delays down to the values from the datasheet (and sometimes below of that).

Источник

Marlin2, FULL_GRAPHIC_SMART_CONTROLLER и кракозябры на экране

Подпишитесь на автора

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

Отписаться от уведомлений вы всегда сможете в профиле автора.

Статья относится к принтерам:

Решил тут обновить прошивку на бутерброде из RuRAMPS4d v1.3 и Arduino Due и с удивлением обнаружил, что на прошивке от июня 2018 экран работает прекрасно, а на прошивке от июня 2019 показывает исключительно кракозябры.

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

Одно из решений, это тотально все экранировать, фольга, ферритовые кольца.

Но раньше ведь оно и без этого работало. В багтрекере марлина нашлось решение:

В сегодняшней прошивке нужный код находится в файле

и должен быть модифицирован вот в такую форму:

// RepRap Discount Full Graphics Smart Controller

#if DISABLED(SDSUPPORT) && (LCD_PINS_D4 == SCK_PIN) && (LCD_PINS_ENABLE == MOSI_PIN)

#define U8G_CLASS U8GLIB_ST7920_128X64_4X_HAL

#define U8G_PARAM LCD_PINS_RS // 2 stripes, HW SPI (shared with SD card, on AVR does not use standard LCD adapter)

#define U8G_CLASS U8GLIB_ST7920_128X64_4X