Duet wifi display support question

3dprinting meathead

I'm sure this has been answered elsewhere, but I couldn't find it.
Can you use a display other than the paneldue on the duet wifi?
It looks like an amazing display, and well worth the price tag, but it's out of my budget range and was wondering if there were any other options available.
If not, it's not a deal breaker, but other options are nice to have.
Thanks!

Werner

Hi 3Dprinting Guy,
I would beg borrow or steal to get the Paneldue!! It is awesome and is a real must have IMHO. I would just wait until I could save the money to get one.
Good luck Buddy!

dc42

Currently there are no other display options. The Duet WiFi has a connector for a 20x4 text display but there is no firmware support for it yet. I expect we will support a lower cost display eventually, but I think it may be a 12864-type graphical display instead of a 20x4 text display, because that is what most users of other electronics want these days and it doesn't need as many I/O pins as the text displays.

3dprinting meathead

Thank you for the response,
Now just waiting for my tax return… I can't wait to get the board

Zesty_Lykle

btw, love your handle.

3dprinting meathead

@Zesty_Lykle:

btw, love your handle.

Thanks, it makes it a lot easier when asking questions. Get a kick out of people with master, guru, expert or pro in their handle asking for advice or help.
Personally, I'm a landscaper, I type with 2 fingers, and never even heard of g-code until about 2 weeks ago. But I am mechanically inclined, and took electrical(not electronics) in high school, so I can learn this stuff, with the help of the vets on forum sites.

3DSTB

Hello David,
i'm not sure if it is difficult to add some lcd-support to the RADDS-firmware? There is a free adapter on thingiverse with some documentation. I'm especially interested for a support of the reprapdiscount smart controller (20x4). What do you think?

Regards
Steffen

Reprapdiscount Smart Controller (20x4)
http://reprap.org/wiki/RepRapDiscount_Smart_Controller

RADDS2LCD:
http://www.thingiverse.com/thing:1740725

[[language]]
RADDS2LCD in Repetier-Firmware for DEV-version (1.x.x)
======================================================

Hardware
--------

Box Header: pin 1 = red conductor from ribbon cable -> side is marked with "rt" on RADDS2LCD.u / RADDS2LCD.o
on RADDS: red conductor towards MOS-FETs and screw terminals

Repetier.h
----------

at end of block beginning with:
##################################
#define NO_CONTROLLER 0

add these lines:
#########
#define CONTROLLER_RADDS_LCD_16X2 997
#define CONTROLLER_RADDS_LCD_20X4 998
#define CONTROLLER_RADDS_FGSC 999

Configuration.h
--------------

replace this:
#####################
#define FEATURE_CONTROLLER ...

by this:
######
/*
		which display ???
		- full graphics smart controller is tested!
		- row / column display is NOT TESTED - use with own testing ;)
  */
//#define FEATURE_CONTROLLER CONTROLLER_RADDS_LCD_16X2	// RADDS2LCD -> LCD with 16 columns and 2 rows
//#define FEATURE_CONTROLLER CONTROLLER_RADDS_LCD_20X4	// RADDS2LCD -> LCD with 20 columns and 4 rows
#define FEATURE_CONTROLLER CONTROLLER_RADDS_FGSC	  	// RADDS2LCD -> Full Graphics Smart Controller

ui.h
----

after these lines
#######

#if  FEATURE_CONTROLLER == CONTROLLER_RAMBO
...
#endif

add these lines
###############

// RADDS + RADDS2LCD + Full Graphics Smart Controller / other 4-bit LCD
#if (FEATURE_CONTROLLER == CONTROLLER_RADDS_FGSC || FEATURE_CONTROLLER == CONTROLLER_RADDS_LCD_16X2 || FEATURE_CONTROLLER == CONTROLLER_RADDS_LCD_20X4)
  #undef SDCARDDETECT
  #define SDCARDDETECT -1
  #undef SDSUPPORT
  #define SDSUPPORT 1
#endif // FEATURE_CONTROLLER == CONTROLLER_RADDS_FGSC

DisplayList.h
------

before or after these lines:
###################

#if FEATURE_CONTROLLER == CONTROLLER_RADDS
#undef SDSS
...
void uiCheckSlowKeys(uint16_t &action) {}
#endif

add these lines
##############

#if (FEATURE_CONTROLLER == CONTROLLER_RADDS_FGSC || FEATURE_CONTROLLER == CONTROLLER_RADDS_LCD_16X2 || FEATURE_CONTROLLER == CONTROLLER_RADDS_LCD_20X4)
  #undef SDSS
  #define SDSS            10
  #undef SPI_PIN
  #define SPI_PIN         77
  #undef SPI_CHAN
  #define SPI_CHAN        0
  #define UI_HAS_KEYS     1

  #define UI_HAS_BACK_KEY 0

  // decide which lcd is used
  #if (FEATURE_CONTROLLER == CONTROLLER_RADDS_FGSC)
	#define UI_DISPLAY_TYPE DISPLAY_U8G
    #define U8GLIB_ST7920
    #define UI_LCD_WIDTH 128
    #define UI_LCD_HEIGHT 64

    //select font size
    #define UI_FONT_6X10 //default font
    #ifdef UI_FONT_6X10
      #define UI_FONT_WIDTH 6
      #define UI_FONT_HEIGHT 10
      #define UI_FONT_SMALL_HEIGHT 7
      #define UI_FONT_DEFAULT repetier_6x10
      #define UI_FONT_SMALL repetier_5x7
      #define UI_FONT_SMALL_WIDTH 5 //smaller font for status display
      #define UI_ANIMATION false  // Animations are too slow
    #endif

    //calculate rows and cols available with current font
    #define UI_COLS (UI_LCD_WIDTH/UI_FONT_WIDTH)
    #define UI_ROWS (UI_LCD_HEIGHT/UI_FONT_HEIGHT)
    #define UI_DISPLAY_CHARSET 3

  #elif (FEATURE_CONTROLLER == CONTROLLER_RADDS_LCD_16X2)
		#define UI_DISPLAY_TYPE DISPLAY_4BIT
		#define UI_COLS 16
		#define UI_ROWS 2	

  #else (FEATURE_CONTROLLER == CONTROLLER_RADDS_LCD_20X4)
	  #define UI_DISPLAY_TYPE DISPLAY_4BIT
		#define UI_COLS 20
		#define UI_ROWS 4	
  #endif

  #define UI_DISPLAY_CHARSET 3

  #define BEEPER_TYPE 1
  #undef BEEPER_PIN
  #define BEEPER_PIN             41
  #define UI_DISPLAY_RS_PIN      42
  #define UI_DISPLAY_RW_PIN      -1
  #define UI_DISPLAY_ENABLE_PIN  43
  #define UI_DISPLAY_D0_PIN      44
  #define UI_DISPLAY_D1_PIN      45
  #define UI_DISPLAY_D2_PIN      46
  #define UI_DISPLAY_D3_PIN      47
  #define UI_DISPLAY_D4_PIN      44
  #define UI_DISPLAY_D5_PIN      45
  #define UI_DISPLAY_D6_PIN      46
  #define UI_DISPLAY_D7_PIN      47

  // swap these two numbers to invert rotary encoder scroll direction
  #define UI_ENCODER_A           50
  #define UI_ENCODER_B           52

  #define UI_ENCODER_CLICK       48
  #define UI_RESET_PIN           -1
  #define UI_DELAYPERCHAR 50
  #define UI_INVERT_MENU_DIRECTION 0
  #define UI_BUTTON_BACK         71 // -1

  #ifdef UI_MAIN
    void uiInitKeys() {
      UI_KEYS_INIT_CLICKENCODER_LOW(UI_ENCODER_A, UI_ENCODER_B); // click encoder on pins 47 and 45\. Phase is connected with gnd for signals.
      UI_KEYS_INIT_BUTTON_LOW(UI_ENCODER_CLICK); // push button, connects gnd to pin
      UI_KEYS_INIT_BUTTON_LOW(UI_BUTTON_BACK);
    }
    void uiCheckKeys(uint16_t &action) {
      UI_KEYS_CLICKENCODER_LOW(UI_ENCODER_A, UI_ENCODER_B); // click encoder on pins 47 and 45\. Phase is connected with gnd for signals.
      UI_KEYS_BUTTON_LOW(UI_ENCODER_CLICK, UI_ACTION_OK); // push button, connects gnd to pin
      UI_KEYS_BUTTON_LOW(UI_BUTTON_BACK, UI_ACTION_BACK);
    }
    inline void uiCheckSlowEncoder() {}
    void uiCheckSlowKeys(uint16_t &action) {}
  #endif
#endif // controller RADDS2LCD

DisplayList.h - (optional)
--------------------------
if you want to swap rotary encoder scroll direction (count clock / clockwise rotation)
then swap 
##########################################
#if FEATURE_CONTROLLER == CONTROLLER_RADDS_FGSC
...
#define UI_ENCODER_A           52
#define UI_ENCODER_B           50
##########################################
to
##########################################
#if FEATURE_CONTROLLER == CONTROLLER_RADDS_FGSC
...
#define UI_ENCODER_A           50
#define UI_ENCODER_B           52
##########################################

dc42

It's a lot of work to add support for other LCDs and to maintain that support because the menu system and interaction with the rest of the firmware would need to be implemented. It's not going to happen any time soon.

It would be possible to use an Arduino or similar with a low-cost display and a rotary encoder to emulate some of the functions of PanelDue. Another user started implementing that, but AFAIK it wasn't finished.

HikariNoKitsune

So basically, something that is usually seen relatively easy to accomplish, is seen as too hard to maintain for the Duet? With the sheer amount of support there is out there for all these other displays that are out here in the wild, most notably the "Reprap Discount Full Graphic Smart Controller", it is abit mind blowing to hear someone state that it is difficult to not just add, but 'maintain' something that seemingly wouldn't ever need to be changed, and thus maintaining would something to not even really worry about.

The only issue I can see would be that since it isn't arduino based like a RAMPS, it obviously wouldn't be the same 'menu' and 'layout' as something like the Marlin firmware. Thus the layout and menu would need to be created. But, again, that seems insanely simple to do considering there is already a pretty amazing web interface that already has all the variables and such, not to mention the already existing code to interact with the PanelDue. Granted, I believe the PanelDue is kind of its own separate system in itself and is merely just being fed values and then spitting out gcode back to the Duet. So all the infrastructure to enable support for these other screens appears to be pretty straight forward, with the only other reason for not including support for them being to keep the ecosystem of components closed off to drive up sales of those components… That, or the hardware itself is designed in such a way that other displays couldn't be used, but then that thought gets tossed aside because the same exact pins that are used to connect to an 'external SD card' on the back of a screen, can be used for running a TFT28 or similar screen, or even the Full Graphic Smart Controller....

So it seems more of a 'We just don't want to do it' and not a 'its too much for us to do' when the board itself is basically finished and the firmware working near flawlessly.

3dprinting meathead

@HikariNoKitsune:

So basically, something that is usually seen relatively easy to accomplish, is seen as too hard to maintain for the Duet? With the sheer amount of support there is out there for all these other displays that are out here in the wild, most notably the "Reprap Discount Full Graphic Smart Controller", it is abit mind blowing to hear someone state that it is difficult to not just add, but 'maintain' something that seemingly wouldn't ever need to be changed, and thus maintaining would something to not even really worry about.

The only issue I can see would be that since it isn't arduino based like a RAMPS, it obviously wouldn't be the same 'menu' and 'layout' as something like the Marlin firmware. Thus the layout and menu would need to be created. But, again, that seems insanely simple to do considering there is already a pretty amazing web interface that already has all the variables and such, not to mention the already existing code to interact with the PanelDue. Granted, I believe the PanelDue is kind of its own separate system in itself and is merely just being fed values and then spitting out gcode back to the Duet. So all the infrastructure to enable support for these other screens appears to be pretty straight forward, with the only other reason for not including support for them being to keep the ecosystem of components closed off to drive up sales of those components… That, or the hardware itself is designed in such a way that other displays couldn't be used, but then that thought gets tossed aside because the same exact pins that are used to connect to an 'external SD card' on the back of a screen, can be used for running a TFT28 or similar screen, or even the Full Graphic Smart Controller....

So it seems more of a 'We just don't want to do it' and not a 'its too much for us to do' when the board itself is basically finished and the firmware working near flawlessly.

It is all open source, so you can implement it yourself if you want.

It would need to be changed as new features are continually added though.

The pins can be configured in almost anyway you can imagine, so I don't think pinout would be an issue.

The board has a 3.3v logic, which might be an issue.

They are rather busy perfecting the firmware, which is always being improved and new features added. But it is a wifi board, so you can control it on any computer, tablet, or smart phone. That kinda pushes it's necessity further down the priority list.

But I do feel that it is inappropriate to imply greed a a motivating factor for not having the time to write the support. They work very hard to develop the most advanced and most versatile board on the market today. Please check out the firmware wishlist to get an idea of the types of features they are constantly adding.

T3P3Tony

We initially planned on supporting a simpler LCD. that is why the headers are there on the board (LCD CONN and SD CONN). The reasons for not doing so yet are:

While it may seam trivial to you to add a whole menu system, and UI control, as it is not yet implemented within the Duet it is a significant amount of firmware work to put in place, its also (despite what you say) another area that will need frequent updating as new features are added to the firmware.
Most of our users who initially asked for a simple LCD, once they use the browser UI, feel its a lower priority than they may have initially thought. That is not to say it has no utility. Just that other firmware work is higher priority.

I actually developed a 3.3V version of the PanelOne, our simple LCD panel:
https://www.think3dprint3d.com/PanelOne
for this reason, however, once again it is not currently a high enough priority.

Cata

A 20x4 display for temps, and other fast reading values it's a great idea.

weput

@Cata:

A 20x4 display for temps, and other fast reading values it's a great idea.

<–-- i second this.

I recently (as in 3 or 4 days ago) finished setting the duet on my printer... and i really miss my LCD...it displayed temps... time and had a kill switch that is way easier to press than the reset button.

if 12864 is going to be supported... lets go for it.. it cost less than 20 bucks.

elmoret

@HikariNoKitsune:

Granted, I believe the PanelDue is kind of its own separate system in itself and is merely just being fed values and then spitting out gcode back to the Duet.

It sounds like you may not have done very much firmware development. Creating a whole new menu system is not "insanely simple". It is really time intensive, more so than other features that are currently on the wishlist. The cool thing about the wishlist is that it is an open voting system, the author of the firmware prioritizes based on community feedback. Which is admirable, in my opinion.

@HikariNoKitsune:

So all the infrastructure to enable support for these other screens appears to be pretty straight forward, with the only other reason for not including support for them being to keep the ecosystem of components closed off to drive up sales of those components…

The beautiful thing is that the hardware and firmware are both open source. There is nothing stopping you (or anyone else) from writing the code.

@HikariNoKitsune:

So it seems more of a 'We just don't want to do it' and not a 'its too much for us to do' when the board itself is basically finished and the firmware working near flawlessly.

No, it is more of a "there are other firmware feature requests that are much more popular/requested right now". You can see the list of requests here:

https://www.duet3d.com/forum/thread.php?id=961

sigxcpu

The protocol on the PanelDue socket is the simple serial console, right?
So an Arduino + cheap LCD with firmware for UI can emulate PanelDue.
Now the question is who will write a whole OS for that

The "net" is full of 3.2" touchscreens with adapter for Arduino Mega 2560.

PcS

With the web interface and the panel due you really don't need anything else. I hate with a passion anything with a rotary encoder wheel and layer after layer of menus. It is both not very unintuitive a very slow. Usually people buying this board do so with the touch screen in mind…At least I did bought both same day. I do not consider it too pricey for this much ability and fingertip freedom. To each his own of course...But why buy a top of the line controller and put an outdated display on it ? I had the old display on my other printer and took it off because I never used it as I always controlled it with Octoprint.

dc42

PanelDue originally supported a 3.2" touch screen, but I dropped support for that before release because I just couldn't fit as much information on the screen as I wanted to, and the 4.3" screen didn't cost much more. Like PcS, I hate having layer after layer of menus. PanelDue with standard firmware has just 4 pages, with popup windows appearing over them when necessary.

I have been trying to reduce the production cost of the PanelDue control board, and hence the price I charge. The Brexit vote put paid to my first attempt because my component costs increased sharply as the £ fell. But at least I managed not to increase prices, and customers outside the UK benefitted from the change in exchange rate. I'm prototyping a new version with a cheaper processor, in another attempt to reduce the production cost.

PcS

Thanks for the panel due. It was one item on a list of things that set this board apart from the competition for me personally. I find the menus well laid out and fast . The web interface is also a joy and the firmware configuration tool really sped up initial printer set up . I may have to upgrade the rest of my fleet . Thanks again.

Agniusm

I would like to add to this. I was too very exited about 5" i got but having used it and having both, PanelDue and 20x4 character i have to say, 20x4 is a lot friendly to use. It just gives you that feedback of having hardware know rather than touchscreen.
Perhaps its just an individual preference and in time paneldue will get more functionality.

dc42

What feedback from the 20x4 display are you referring to?