Anyone interested in an LCD control panel for the Ormerod?

Quote
static65
Hmm, I have a 4.3" display kicking around I got from a Rohde and Schwarz handout advertising their software defined radio. It's apparently 1280x800, possibly touchscreen but it's hard to pin down the spec. It's an FPC4304006 (I think the 4005 version is non-touchscreen). Do you know if the board you're planning would be compatible with such a display? Touchscreen function aside of course. Just looking to cut down on costs if you're willing to ship without a display

Most displays with that sort of resolution require some format of continuously scanning video signal to drive it, and most these days can display greyscale or full colour. The smaller displays have built-in RAM and the LCD drivers that allow pixels to be either on or off (limited or no greyscale), and their display RAM can be written to with a simple parallel or serial I/O only when a change is required - so a very different concept.

Dave
(#106)

The display I'm planning to use is 320x240 pixels, 3.2" diagonal, with integrated SSD1289 driver chip supporting both parallel and SPI interface. It needs drive signals of around 3V, so I'll be running the atmega32u4 at 3.0 or 3.3V, except for the USB driver part.

It will take a week or two for the display and other parts to arrive, so in the meantime I will continue prototyping with the 128x64 display.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I now have a simple 20x4 character display that works for the Duet.

[blog.think3dprint3d.com]

What would be great is if the RepRap firmware future "display" class/es could be designed in such a way that they worked with both your upcoming graphical display and simple displays such as this one. For example having a generic "display" class to handle requests for information and responses in a standard way and then specific display_type classes that interfaced with the hardware. Using g-code macros on the SD card to handle as much as possible would also be excellent, especially if it allowed users to deal with language without editing the firmware.

Cheers

Tony

Nice to see that you've got it working.

The consensus of those who have expressed interest in the board I am developing is that they want a higher resolution display and separate processor. It might not be possible to run the hi res display off the Duet processor anyway, due to the I/O bandwidth involved in updating the display. I'm planning to use one of the serial ports to communicate with the Duet. I'm working on extending the existing USB/serial interface code on the Duet to accept rr_ commands similar to the ones that the web server supports as well as gcodes. Then I will replicate the serial I/O buffers so that the Duet can accept commands over the serial interface too. The result will be that almost anything that can be commanded or reported via the web interface will also be doable over serial or USB.

It would be good if we could agree on a file extension and SD card folder name for gcode files that are intended to represent commands to be executed from the display/encoder combo. I suggest we stick to .g as the extension, but use a new directory such as /commands on the SD card. The long filename of the file itself (without the .g extension) can serve as the command name to be displayed on the LCD menu. If you think there is a need for submenus, then subdirectories of /commands could represent submenus.

I see this facility as being useful on the web interface too.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Yeah a simple display such as the one described is trivial with the built in arduino library for character LCDs, the harder work it to design a generic and extensible addition to the firmware - hence sticking my nose in here!

I see that using the separate processor and hence a serial interface is the option for the graphic display, it has a lot of advantages for the more complex displays. Obviously as you are using a serial interface it makes sense to extend the USB/Serial part of the firmware to support your display, it would be good if it would work with only gcodes (might have to define a few extra gcodes to do this) rather than using rr_ commands as well - would that be possible? I like the method of using a "display" directlry with subdirectories to organise the menu tree and then the long directory names and filenames can be the command name. This means that they can be called other names to handle different languages.

The way displays have been implemented in Marlin approximately has lead to an ecosystem of loads of different simple directly connected displays, along with with I2C communication displays and graphic displays.

Within RepRap Firmware how can we support directly connected. serial communication, and future to be designed displays in the most simple and extensible way? If using the USB/Serial code it sounds like your implementation will look something like this (excuse the ASCII art):

RepRap Firmware--->USB/Serial ---> USB interface ---> PC (already exists)
|
------------>Serial interface ---> DC42 Display

That would require a separate system for non serial displays. what do you you think about this sort of design:


RepRap Firmware--->USB/Serial ---> USB interface ---> PC (already exists)
|
--------------->Display------>Serial interface ---> DC42 Display
|
------------>I2C interface ---> I2C Displays
|
------------>Directly connected interface ---> Simple character Displays


If the "display" class talked gcode only then all future displays could be easily implemented.

Cheers

Tony

---

DuetWifi.: advanced 3d printing electronics

The main issue I see with using gcodes is that the gcode interface uses a buffered stream of commands and returns a buffered stream of responses (or no response at all). This is OK for manual use and where no response is needed such as when printing a file, but badly suited to control and status monitoring. The protocol used by the web interface is much better, because it is transactional, so there is a more-or-less immediate response to each command. All the important status information can be obtained by sending a single command (rr_status) and it is in JSON format which is easy to parse. Delayed responses and error messages are passed back through a field in the response to rr_status.

In order to use gcodes throughout, I think we would need to implement at least the following:

1. A new gcode flavour, in which there is (probably) a response to every command, and the responses can be tied to the commands. One way would be for each response to be tagged with the line number of the command. Each response would have a definite terminator e.g. newline (implying that in multi-line responses, the newlines separating different lines would be replaced by something else).

2. A means to set a different gcode flavour for each input device. Should be easy to implement, just need to store the emulation mode in the gcode buffer instead of globally, except that a command to set the emulation mode in config.g should be actioned on all input channels.

3. A new gcode (or a modification to an existing one) equivalent to the rr_status command, returning all the important status information in JSON format. Possibly the M105 command could be repurposed to do this when the new gcode flavour is selected.

4. This new gcode would need to queue-jump gcodes being executed or awaiting execution. So would emergency stop, reset, and the command to pause the print (as already happens in the web interface code).

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
T3P3
If the "display" class talked gcode only then all future displays could be easily implemented.

This is what i had planned but with you guys working on it i can focus on some other projects.

What i liked about using gcodes over the serial interface was that not only could future displays be easily implemented but displays designed to work with the duet could be used on other electronics with little modification

I would definitely be interested in one.

I use pronterface predominantly to interact with my printer. When I start a print from the SD however pronterface doesn't update things like temperatures, positions, percentage of print done or expected print time remaining.

Would this LCD remain active when printing from SD, USB or Ethernet cable?

Tom

Quote
barkerboy
I use pronterface predominantly to interact with my printer. When I start a print from the SD however pronterface doesn't update things like temperatures, positions, percentage of print done or expected print time remaining.

Would this LCD remain active when printing from SD, USB or Ethernet cable?

Yes it will. I am taking some of the functionality that is currently only available via the web interface, and making it available via one of the spare serial ports on the Duet. I may even make it availabe via the standard gcode interface.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

HI,

i would be very interested.

-Liam

Hi,
Please add me to the list if possible

Alan

Add me to the list please!

@Barkerboy

Hi Tom, I use Pronterface nearly all the time, because otherwise I would be always editing my Web settings on the SD card.
The only time I've found it NOT to update temperatures is when homing, or the initial wait for the temps to be reached. We don't get that problem on the Web interface, so I think it's the firmware looping around waiting for the temps to be reached before it starts to print. During the print the temps are updated correctly, and unlike the Web Interface, we can alter the temps (unless this has been changed now) via Pronterface.

Sometime ago when the USB connection was removed or we disconnected Pronterface, the printer would stop. But DC has fixed this, and the printer will quite happily run on it's own, and allows you to re-connect/disconnect Pronterface as often as you like while printing... So it's perfect now...

After having the nozzle heater wires break a couple of times, I've added an LED to the Nozzle heater so that it's possible to check that the heater is getting a power signal ok.

I think the LCD display is going to be a really good, must have addition to the printer, and something that I think it should have had from the beginning.
Looking forward to using it.

Kim

---

Please send me a PM if you have suggestions, or problems with Big Blue 360.
I won't see comments in threads, as I move around to much.
Working Link to Big Blue 360 Complete

Quote
KimBrown
... and unlike the Web Interface, we can alter the temps (unless this has been changed now) via Pronterface.

FYI I fixed this in the web interface several months ago. The latest version (1.00) displays the current, active and standby temperatures of both nozzles on a dual nozzle machine, and lets you change both the active and standby temperatures.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

The TFT display finally arrived from China today. So I can get down to serious development of this project next week.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42

Quote
KimBrown
... and unlike the Web Interface, we can alter the temps (unless this has been changed now) via Pronterface.

FYI I fixed this in the web interface several months ago. The latest version (1.00) displays the current, active and standby temperatures of both nozzles on a dual nozzle machine, and lets you change both the active and standby temperatures.

That's cracking DC... Well done... I've enjoyed using the Web Interface in the past, but were I move the printer around and it's on four different networks during a month it's not practical to keep editing the config file.


While writing the above I've just had my first lock up during a print in a very long time. Up untill then the printer has been as good as gold for a few months now. The printer stopped dead after about an hour printing with the Nozzle heater ON constantly (I have a LED on my Nozzle heater, and the brightness stayed bright without dimming or altering brightness as it would normaly (so appeared to be stuck full on), however the Bed heater was cycling correctly trying to maintain the bed temp even while it was locked up. I'm using FIRMWARE_NAME:RepRapFirmware FIRMWARE_VERSION:0.65k-dc42 ELECTRONICSuet DATE:2014-06-28

Hmmmm, and another problem I've just discovered having returned to using the original Glass, is that in releasing the print from the glass, a chunk of the glass surface remained on the print stuck hard and fast. Never had that when I was using the thick Red glass.... So I'll need to find a glass shop tomorrow.

---

Please send me a PM if you have suggestions, or problems with Big Blue 360.
I won't see comments in threads, as I move around to much.
Working Link to Big Blue 360 Complete

I am putting together the preliminary design for this unit. The provisional specification is:

Display: 3.2 inch 320x240 colour TFT (similar to [imall.iteadstudio.com]) or 3.2 inch 400x240 widescreen (similar to [imall.iteadstudio.com]). Variable backlight brightness.

Processor: Atmega32u4 with Arduino Leonardo-compatible bootloader, 2.5K RAM, 32K flash.

Input devices: Rotary encoder with integral push button; resistive touch sensor on the display; separate emergency stop button.

Communications: async serial interface (probably at 115200 baud) for communication with Duet. USB micro connector and ICSP header for programming.

Power: +5V from Duet. Current consumption to be determined, estimated at 100mA.

My plan is to use the touch screen for navigating menus and selecting fields, and the rotary encoder for precise input. For those who don't like touch interfaces, I will provide for navigation and selection via the rotary encoder too.

Most of these displays include an SD card socket, however I am not planning to connect that, because the Duet already has one, and the data rate between the second SD card socket and the Duet would be too low to be useful IMO.

Any comments? Should I choose the widescreen display or the standard one? I am not intending to provide LEDs because the display will show all the necessary information.

Due to other work I have at the moment, the earliest I will ne able to ship these will be late November

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hi david,

i think a widescreen is a good Thing for a good design of the Information to Display on it.

More pixels = better, but I guess it will be the product designers / manufacturers (i.e. dc42) judgement call whether or not it is worth the extra cost. I'm personally not price-sensitive enough to say anything other than "go big".

Could the second SD card not be used for Admin stuff, like logging the start stop times, total hours, filament used, stuff like that?

---

Please send me a PM if you have suggestions, or problems with Big Blue 360.
I won't see comments in threads, as I move around to much.
Working Link to Big Blue 360 Complete

Regarding the second SD card. having it on the LCD controller makes a lot of sense - It is much more accessible than the controller which could be buried within the internals of the machine. We have found with the Panelolu2 and the Melzi that most people moved to using the one on the Panelolu2 because it was more convenient. If you are worried about data transfer rate then you could connect the Duet SPI bus directly t the screen SD card (bypassing the 32u4). The SPI bus is present on the expansion header, and on the expansion1 header on the duex4 and should be preserved through future expansion cards as its useful for exactly this sort of thing.

Cheers

Tony

---

DuetWifi.: advanced 3d printing electronics

A while back I had my printer oriented such that the SD card was a bit tricky to get to, and there were frequent changes to the SD card (uploading files through web ui wasn't complete), and I got an SD card "extension cord" to have it more accessible. I have stopped using that though, since I very rarely have to bother taking the SD card out. I only do that when there are multiple files changed on it (such as a big web ui update), usually together with a FW update. There is quite a difference compared to most other printer controllers, since they don't have ethernet you have to use the SD card to get gcode files to the printer and probably need to access it much more often. Also, compared to some other repraps, the SD card slot in the Ormerod is pretty easy to get to. In all, I just don't think there is much value in having the SD card be more accessible. If it is cheap and easy to add though, by all means go for it.

I honestly don't see the point in having a second SD card either. It would mostly just be an excellent source of confusion regarding what goes where. If there is a need (and fw implementation) for logging and such, that could just as well go on the regular SD card to be compatible with printers that lack the display addon.

Quote
T3P3
Regarding the second SD card. having it on the LCD controller makes a lot of sense - It is much more accessible than the controller which could be buried within the internals of the machine. We have found with the Panelolu2 and the Melzi that most people moved to using the one on the Panelolu2 because it was more convenient. If you are worried about data transfer rate then you could connect the Duet SPI bus directly t the screen SD card (bypassing the 32u4). The SPI bus is present on the expansion header, and on the expansion1 header on the duex4 and should be preserved through future expansion cards as its useful for exactly this sort of thing.

Tony, thanks for that suggestion, it should be simple enough to implement. I guess we can have the Duet firmware try the standard SD card slot first, and the secondary one if the card isn't found. Or vice versa.

Edited 1 time(s). Last edit at 09/04/2014 05:09AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hi
Sorry jstck I totally disagree, just my opinion and use case scenario:

I think dc's going to have a "cant please all the people all of the time" scenario

IMHO the reason for the LCD display is to give fine control whilst printing, and replace the web interface as you mention in other printers.
So if I dont have any ethernet connectivity and my printer is running well, I would just copy the stl to the SD card and pop it into the printer and use the LCD to launch the print, observe how its going making any fine adjustments as its printing.
In which case a very accessible, robust and easy to use SD card slot is essential, I'd like to be able to bury the duet board in the machine and never have to go near it.

So it depends what dc has in mind for the the target use case for the LCD, as a control panel to allow fine adjustments whilst easily watching the ongoing print, as a method of allowing stand alone operation, and/or some other use cases.

In any case, if dc makes the design open source as he has done with all his developement for the Ormerod, functionality can be added later, and as dc says some of the time the SD connnector comes free with a lot of LCD shields.

dc can the LCD electrical interface be made standard?
That way at a later date larger screens can be add if required?
Or does each different display use a different driver chipset and so make writing the software more complex (need for sw device driver etc)?

I suppose if the serial interface between the duet and the LCD is documented then a number of control panels can be developed by individuals to meet their own needs.

Lloyd

@dc42,
I think the larger widescreen display would be better, providing more space for the large amount of data that will need to be displayed, especially if it will enable the Ormerod to operate stand alone. So on one hand I agree that the second sd slot should be available as an either or with the duet slot. However, will the speed be fast enough with your planed communication with the duet being an async serial interface at 115200 baud. Would it be worth considering T3P3's suggestion instead?
Have you had any thoughts on a case or mounting of the display on the ormerod?

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

I would in no way be displeased if it came with an SD card reader, I just don't have any use for it and just assume most Ormerod users have network connectivity to their printer. But if it is cheap and easy to include, by all means, of course do it. If using the SPI lines, would it just be a "duplicate" of the on-board SD slot? So, wherever the card is inserted it will work the same? (And be doomed they who insert two cards at once)

If the Duet <-> Ormerod interface is generic enough (the display logic living entirely in the display, and just a gcode or similar interface) there is room for several different display versions sharing a lot of the same development effort.

Quote
ezwul
dc can the LCD electrical interface be made standard?
That way at a later date larger screens can be add if required?
Or does each different display use a different driver chipset and so make writing the software more complex (need for sw device driver etc)?

I think (but have not checked) that most of the displays listed by itead on the page I linked to earlier have the same pinout. I will be forking the UTFT library for this project, and that library can drive a few different chips, including the SSD1289, HX8352-A and SSD1963. So in principle, the board I sell could drive several different displays in that range.

The complications are:

1. The screen layout will have to be designed to suit the aspect ratio and screen resolution. So anyone using a different size screen from the one I support will need to adapt the software. I've already started the software, and I am trying to make it easy to adjust the screen layout, by using a table to define the positions of the displayed fields.

2. For ease of assembly, I plan to mount the rotary switch and push button directly on the board. This will place them in a fixed position relative to the display connector, unless you remove them and connect them with flying leads instead.

I haven't thought much about the case to hold the unit. I think a printed case (as used with the other LCD displays) makes sense, except perhaps for any Ormerod 2 owners who want to keep the EMI at low levels. I'm hoping that someone else will design the case once I have chosen the default display and provided the dimensions needed.

Edited 1 time(s). Last edit at 09/04/2014 10:58AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
jstck
I would in no way be displeased if it came with an SD card reader, I just don't have any use for it and just assume most Ormerod users have network connectivity to their printer. But if it is cheap and easy to include, by all means, of course do it. If using the SPI lines, would it just be a "duplicate" of the on-board SD slot? So, wherever the card is inserted it will work the same? (And be doomed they who insert two cards at once)

If the Duet <-> Ormerod interface is generic enough (the display logic living entirely in the display, and just a gcode or similar interface) there is room for several different display versions sharing a lot of the same development effort.

The on board SD card on the Duet uses the HSMCI interface (SD 2.0) to support SDHC card at significantly higher speed and capacity than SPI. SPI is completely adequate for reading GCode for printing though.

Cheers

Tony

---

DuetWifi.: advanced 3d printing electronics

I guess only time it would make a difference is when you do web-uploads of gcode files. Everything else should be really low bandwidth.

Quote
jstck
I guess only time it would make a difference is when you do web-uploads of gcode files. Everything else should be really low bandwidth.

Yes - and that would make more sense to store on the "on board" SD card

---

DuetWifi.: advanced 3d printing electronics