Anyone interested in an LCD control panel for the Ormerod?

Quote
dc42
Thanks Paul, it's looking good!

If any programmers reading this feel like contributing towards getting this project finished, there is a script that you might like to write. I suspect that it would be very easy to do in awk, but I haven't used awk for several years and I have forgotten how to use it. It could also be done in Python, Java or just about anything else. It's concerned with reducing the amount of space needed to store fonts.

The C++ source file for the font I am currently using is at [github.com]. The file is generated by GLCD Font Creator, and I insert the header bytes manually. After the header, each row corresponds to a character, and comprises a 1 byte count followed by a fixed number of bytes. What I am looking to do is to remove unnecessary bytes from the end of each row such that if the byte count in a row is N, the number of additional bytes in each row is N * C. The value C is the number of bytes per column, which for this font is 2 but will be higher (e.g. 3 or 4) for larger fonts - it's actually H/8 rounded up, where H is the height of the font in pixels. The bytes being removed will always be zero, however some characters will still have some trailing zero bytes (if that were not the case, I would write a simple sed script instead). The comment at the end of each row should be preserved, because I sometimes hand-edit fonts to improve readability.

Any takers?

I'll give it a go, but it'll be rough C++...
unless anyone else has done it?

When do you need it?

regards
Andy

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

Thanks Andy, it isn't urgent because I'm still working with the small font and there is enough spare memory for now. In 2 weeks from now, I might need it.

---

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 Dave,
I'll create a simple program to compress your fonts.
I'll PM you to confirm understanding.

[Edit] Never mind...I must remember to refresh the forum page before posting
DaveS

Edited 2 time(s). Last edit at 10/09/2014 04:36AM by gnarly.

Quote
dc42
That's a nice looking screen, but when you add the cost of the Pi and probably a small network switch (so that you can connect the Duet to a PC as well), it's a £100 solution rather than the £50 solution I was aiming for.

I think I will stick with my original plan. If you or someone else would like to pursue the RPi + web interface option, then it occurs to me that the same web interface might be suitable for mobile devices.

The idea here at the moment here is to connect the Pi via USB or Network connection. Prob. USB as Pronterface is via the USB, and it's Python Based which is on the Pi. So the only question really is will Pronterface fit on the small screen or does it need trimming down.

The other week I tried connecting both the USB and the Network link at the same time. Both worked at the same time.
As for cost I already had the Pi that I play with from time to time. But if someone wanted to buy one they are £27 (inc P&P) and are prob cheaper than that, especially second hand. The screen is £40, so £67 or lower total, plus the printed case. There are a few advantages, in that the software can be edited on the machine (or off it) just by plugging in a keyboard, and either using the small screen, or a larger screen.
The software is stored on SD card, so if you wanted to use the unit for something else then you just swap SD cards.
Also all the basic brickwork is in place... Pronterface or Network, just plug in. The screen is already basically made, just requires a connector soldering on, and the drivers added to the Pi system (They supply a version of at least one OS that is already done, so the screen is nearly Plug and Play). Only problem (for me) is getting my head around Unix again (which I haven't played with in ages), and playing with Python, which seems very similar to some of the other languages I've played with over the years... Just got to dust off the Grey cells (hopefully), but I know a man who can, if all else fails.....

---

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
dc42
Thanks Andy, it isn't urgent because I'm still working with the small font and there is enough spare memory for now. In 2 weeks from now, I might need it.

Hi DC,
basic source as I understand it... If its correct I'll be happy to round it out
EDIT: Fixed need for C++11 and lack of terminating semicolon on array (log at end source)
main.cpp (V2)

sample output from https://github.com/dc42/utft/blob/master/glcd16x16.cpp
glcd16x16_out.cpp (V2)


regards
Andy

Edited 2 time(s). Last edit at 10/09/2014 06:47AM by kwikius.

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

Another option for those wanting more functionality is the Active8. Active3d (Justin Carpenter was exhibiting at the reprap community hub at the TCT show) have released the info on youmagine: [www.youmagine.com]

This looked great at TCT although I did not get a chance to play with it much.

Cheers

Tony

---

DuetWifi.: advanced 3d printing electronics

Quote
dmould

Quote
kwikius

Quote
dmould
[...]
The choice of CPU is predicated to a large extent on what architecture/programming tools you are familiar with and not only the capabilities of the CPU. I'd probably go for a Cypress CY7C67300 - perhaps with external Flash and/or static RAM as a solution for this application, but it would certainly not be worth the learning curve if I wasn't already familiar with it, and I'm sure there are better choices if I was willing to learn a new CPU. The cost of the CPU and support components is in any case probably largely swamped by the PCB, assembly and LCD costs.

Dave

Just to add that if once you learn one ARM mcu architecture then you are well on the way to learning a large number and not limited to 1 manufacturer or ic series.

regards
Andy

Similar could be said of MIPS, PIC or 8080 architecture (though the latter has become mutated beyond reason!).
Dave

Well I dont consider Microchip PIC in that debate since its a single manufacturer. I used to love 8 bit PICS but started getting tired of wasting months writing asembler and you couldnt use gcc. Even now they provide a crippled version. How dare they! Thats where AVR scored bigtime.. what a relief to move to AVR ! and get things done.

But time goes on and now 32 bit microcontrollers are becoming more user friendly. And I guess AVR got caught up with Arduino. And my point is why go with an 8 bit processor with small rom and ram when you can get a processor with hardware floating point large ram and many more periphearls for the same money.

ARM v MIPS. I think MIPs has had a hard time! In terms of quantity of MIPS v ARM ic's out there and manufacturers using ARM ... no contest!

Quote
dmould
Which is true as far as the main body of the firmware is concerned, but every ARM based SOC seems to have a different method for uploading the initial code, setting up its clocks, initialising external DRAM and driving its on-chip devices, so there are still significant things to learn. Many ARM chips have an on-chip Ethernet MAC for example, but rarely are they driven in the same way. USB is better, with many chips adopting the OpenOCI standards (though even there some require addresses to be physical whilst others use virtual, some allow tables in external memory whilst others must have tables in internal RAM). I love the ARM instruction set, it is so elegant and versatile, especially the way that almost every instruction can be given conditionals and shifts, and the programmer can decide whether an operation sets the condition flags or not. Also the way that any register (except the PC) can be used as a stack pointer is also really great, allowing you to set up multiple concurrent stacks with ease. My only small gripe is that there is no easy way to save the condition code register, which makes multi-word arithmetic loops more complex than they need be, and the way that a subtract operation uses the carry flag the wrong way about (i.e. 3-1 sets the carry, 1-3 clears it).

Dave

Well. That is interesting ... but I try to avoid assembler since many years. My projects havent yet used any external rom or ram. I think I only wrote around 3 lines of assembler in last project, which was only to access some special registers. These days my policy is 1. use C++ . 2. find the most powerful microcontroller that I can for the money, rather than try to squeeze stuff in. Then when you find you want to add some unthought of feature, then you can. STM32F4 is great .. hardware floating point. Its nice. fast interrupts with floating point calcs are doable easily. extends what you can do. I agree that ARM architecture isnt as easy as using 8 bit avr on Arduino IDE, but I think ARM is getting the message and that is what mbed is all about. They are abstracting away the low level hardware .. And the hardware you are working on is pretty varied,wide choice and powerful.

Anyway hope DC doesnt think I'm subverting the thread. Just trying to point out alternatives to Arduino

regards
Andy

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

Nice code.

I'm feeling very old now...as I just realized that I first used C++ in the mid 80's!

I was going to suggest an optimisation to index the fonts, but then remembered Knuth
'premature optimisation is the root of all evil'

and I would probably be teaching DC to 'suck eggs'

DaveS

Andy, thanks! I will switch to the larger font now that you have provided that program.

DaveS, I intend to build a small font index on the fly, provided there is enough spare RAM when I have finished everything else.

Here is my latest attempt at screen layout. I'm still using the 16x16 font, but there is room for a slightly larger one, especially if I shorten some of the text.



Ignore the fringes, they are caused by a sampling interaction between the pixels on the camera sensor and the screen pixels.

---

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
Andy, thanks! I will switch to the larger font now that you have provided that program.

No problem. It was a good break from other stuff TBH. BTW found a couple of bugs so now in place replaced the attachment with V2

Now send me your issues

regards
Andy

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

Hi Guys

Just a little motivation from down south....

We SA boys would appreciate the cheaper option, specially looking at the Rand / Pound rate at the moment.

PS: Good on you for doing this... :-)

Madmob

madmob, thanks for that input. I am trying very hard to avoid feature creep in this project. It started out as a control panel similar in concept to the Panelolu, but using a 128x64 graphics display instead of the 20x4 character text display for additional flexibility and display clarity. I was persuaded (quite easily) to upgrade it first to a 320x240 TFT display so that extra information can be displayed (and it happens to support colour and is touch-sensitive), then to a 400x240 display. Some Ormerod users want to go further and use a full-blown computer based on the RPi.

Tonight I reviewed the situation. I think the atmega32u4 processor that I have so far been designing this device around (so as to be compatible with the Arduino Leonardo, to make it easy for users to change the program) is probably adequate for driving the 128x64 monochrome display. However, it is severely constrained in respect of both program memory and I/O pins when driving the higher-resolution TFT displays. The I/O pin limitation is easily worked around (I added an external 8-bit latch). The memory limitation, caused largely by the need for larger fonts, is more of a problem. I'm currently using 83% of the total flash memory and 50% of the RAM, and I still have substantial functionality to add. I can save on flash memory by compressing the font and hacking the Arduino core, but I'm not sure this will be enough.

I see a couple of possibilities:

1. Revert to using the 128x64 monochrome display. The functionality will be more basic, although it will still be able to show more information than the Panelolu with its 20x4character display.

2. Switch to using a more powerful processor. I have identified that ATSAM3S1A as being suitable. It has 64Kb of flash and 16K of RAM, against 32Kb and 2.5K for the atmega32u4 - yet it costs less than the 32u4, so I can still keep within the target price of GBP50. If I need even more memory, I can go to the ATSAM3S2A with double the flash memory and RAM, still at very reasonable cost. The board will no longer be Arduino-compatible, and I will probably use Atmel Studio to develop the firmware. However, it will be still be possible to update the firmware via USB without the need for special hardware. In theory it should be programmable using bossac, but this has not been tested according to the documentation I found.

My inclination is to go with the ATSAM3S1A or ATSAM3S2A. But I'd welcome input from potential users.

---

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
My inclination is to go with the ATSAM3S1A or ATSAM3S2A. But I'd welcome input from potential users.

I would prefer something arduino-compatible, but as long as it can be built and uploaded with command-line tools (outside any fancy IDE's) I could live with it.

EDIT Scratch that I re-read post!Programming firmware requiring a programmer is the only issue. STM32 has built in bootlaoder, can be programmed via serial port stm32flash
or debugger (Win) ST-Link or (linux) texane/stlink
No hardware programmer required

I had a quick look at ATSAM datasheets but cant see whether similar is possible.

For programming gcc and make would be my choice ( After all thats what Arduino uses AFAIR !)

regards
Andy

Edited 1 time(s). Last edit at 10/10/2014 04:46AM by kwikius.

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

One issue to be aware of is that 32 bit processors may not use ROM as efficiently for code as 8 bit. However if its rom data such as Font tables then I guess its not a problem..

regards
Andy

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

Quote
kwikius
One issue to be aware of is that 32 bit processors may not use ROM as efficiently for code as 8 bit. However if its rom data such as Font tables then I guess its not a problem..

regards
Andy

True. However, nearly all the variables I am using need to be at least 16 bits, and on the 8-bit atmega architecture that I have been using, this results in lots of extra machine instructions because two 8-bit registers have to be used. So I am hopeful that 64Kb flash will be sufficient. Also, the bootloader in the ATSAM is in a separate ROM, so it doesn't take up flash. However, I will prototype using the 256K flash memory version (because there is an inexpensive dev board available for it), and when the firmware is largely complete, I will choose whether to use the 64Kb or 128Kb version for manufacture.

---

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
kwikius
One issue to be aware of is that 32 bit processors may not use ROM as efficiently for code as 8 bit. However if its rom data such as Font tables then I guess its not a problem..

regards
Andy

True. However, nearly all the variables I am using need to be at least 16 bits, and on the 8-bit atmega architecture that I have been using, this results in lots of extra machine instructions because two 8-bit registers have to be used. So I am hopeful that 64Kb flash will be sufficient. Also, the bootloader in the ATSAM is in a separate ROM, so it doesn't take up flash. However, I will prototype using the 256K flash memory version (because there is an inexpensive dev board available for it), and when the firmware is largely complete, I will choose whether to use the 64Kb or 128Kb version for manufacture.

Final factor .. I am sure you will/do find programming 32 bit ARM at 64 MHz with advanced timers and peripherals,much more satisfying and enjoyable !

Go for it I say!

regards
Andy

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

Maybe first clarify exactly what functions and information most users want from an integrated controller. To make a print my normal sequence via the web interface is (1) start the bed heating (2) upload the print file if required (3) wait for bed to be close to temperature (4) home all OR (4) Home XY, then home Z by hand (5) select print file and start the print. Sometimes I want to change the filament while waiting for the bed to heat, so I might want to heat the extruder, change the filament and switch off the extruder heater during step (3).

During the print it must be possible to do an emergency stop at any time, and would be useful to be able to pause, move the extruder away, then move the extruder back and resume during a print, and adjust extrusion, speed and temperatures on the fly whilst printing.

File uploading is only possible via an attached PC or by SD card, so we can assume the required print file is already present and skip step (2) as far as controller function.

The information I require displayed depends on the stage I am at. At the start the only thing I am interested in is the bed temperature. For manual Z homing the Z height is useful, and some may also be interested in XY position. During printing I am concerned only with the extruder's set temperature - I can assume it will be achieved within a minute at the most (in fact less than 20 seconds except the final cooldown period). During printing I am interested in estimated time remaining, percentage completed and/or layer number and/or Z height. A reminder of the set bed and extruder temperatures might be good if there is room on the display, otherwise I'm happy to have to toggle to a different screen to see/adjust those. I am never interested in XY position during a print, or filament used. Occasionally it is good to know how much filament left to be used to judge if the reel will need changing - but that can be of another screen page. After the print has completed I may be interested in the time it actually took and the amount of filament used, as well as actual bed and extruder temperatures to know when it is safe to touch without getting burned, and safe to switch off. I think it is generally better to display clearly and boldly only the information likely to be of interest at the particular stage of printing rather than a screen cluttered with 101 different parameters, and put items of only infrequent interest on different pages.

I think a "one touch print" function would be useful (also in the web interface). With this I simply select the file and hit "print". The controller then first sets the bed temperature and waits for it to be reached, then homes all axis and goes to park position, then sets the extruder temperature and finally runs the file when the set temperature has been reached. That way I won't be tied to the printer waiting for the bed to heat before I can home and start the print. I know that that functionality can be achieved in the gcode (I've occasionally done it), but it would be more versatile if I can decide at print time whether I want to perform the preliminary steps manually or let them be carried out automatically as part of the print - especially homing. If I have meticulously set the Z home position by hand because I need it to be more precise, or offset the XY home position to avoid printing on an area of damaged tape or glue on the bed, I don't want the gcode file messing it up by doing an automatic home, so I don't usually put any homing commands in my print files.

Dave


Dave

Dave, that should all be achievable. I am looking to make the display share the same layout as the web interface, so that it is easy for a user to switch between the two. I think Matt's original web interface design, with my modifications for new features (2-head printing, speed and extrusion adjustment etc.) works well, and I see no need to make major changes to it. So the software I am working on uses the same fixed upper pane and tabbed lower pane. Of course, the amount of information displayed will have to be less than in the web interface in some places, because of the smaller display area.

I will add a macro system (and make it available via the web interface too) to facilitate common tasks, such as preparing the printer for printing (homing axes, heating bed etc.). Your one-touch print function sounds useful 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].

Quote
dc42
Dave, that should all be achievable. I am looking to make the display share the same layout as the web interface, so that it is easy for a user to switch between the two. I think Matt's original web interface design, with my modifications for new features (2-head printing, speed and extrusion adjustment etc.) works well, and I see no need to make major changes to it. So the software I am working on uses the same fixed upper pane and tabbed lower pane. Of course, the amount of information displayed will have to be less than in the web interface in some places, because of the smaller display area.

I will add a macro system (and make it available via the web interface too) to facilitate common tasks, such as preparing the printer for printing (homing axes, heating bed etc.). Your one-touch print function sounds useful too.

That would be great, especially if it can queue macros and print files so they execute in order one after the other without further intervention. The macros can then take the place of the start and end code for more versatility. If you plan to work on the web interface, maybe also a trivial refinement to display the filament left to go rather than the filament used (so I have no need to do the subtraction sum when I see that there are only a few turns left on the reel and wonder whether it's going to run out). Unless you can see an advantage in counting up rather than down?

Dave

Hi DC

Thanks for the feedback, from this side I will be backing you as from what I gather, your goals with this is on Target.
The GBP50 price tag feels reasonable on this side, considering the functionality you are including in this.

For the SA guys, we should combine our efforts to soften the shipping impact...
But I am sure we will get something worked out.

Once again, thanks for the effort from this community, much appreciated.

Madmob

Here is my latest attempt at the screen layout.



I have changed to a larger font. The colours could almost certainly be chosen better, but the idea is that the fields with white text on black are touch-selectable, the red on black shows which is the current tab, the red background on the temperature shows that the heater is active, and the yellow background shows that it is on standby. There is more data to be added to the printing tab, e.g. percent complete and estimated time to completion. The Free RAM field will be moved to the Info tab. There are also the stop/pause/reset buttons to be added, which I will probably put at the right hand end of the title line (and do away with the machine name to make room if need be).

Edited 1 time(s). Last edit at 10/10/2014 03:05PM 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].

Nice work David

Looking good DC42

I somewhat hesitate to say this ( but decided to put it out there!) but what springs to my mind is to use the display for a close up view of what is going on at the print head. ie from a video camera. I appreciate this would definitely amount to feature and cost creep, but the QVGA display is perfect for the task I think. A webcam might work but looks like would need USB2 to get a good framerate, though I am no expert on the subject.

Anyway maybe I should put this in a separate thread?

regards
Andy

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

HI DC

Nice job....
I can't wait.

Madmob

---

[Madmob Consulting:] Promoting 3D printing down South

Amazing DC42, excited to get this. Many thanks for all your hard work.

---

Ormerod #007 (shaken but not stirred!)

Quote
Treth
Amazing DC42, excited to get this. Many thanks for all your hard work.

Ditto!

"Every day, in every way, it's getting better and better"

Erik

Would it be possible to have a few extra pin headers or pads on the pcb for "leftover" inputs/output pins on the processor, for future expansions? Just for the possibility of later adding stuff like buttons, swiches, LED:s or buzzers. Ideal would be a pin header for a a few (3 or so) input pins with onboard pullup/pulldown resistors for easily wiring up hard-buttons, and solder pads straight to the processor for as much as will fit on the pcb.

Quote
jstck
Would it be possible to have a few extra pin headers or pads on the pcb for "leftover" inputs/output pins on the processor, for future expansions? Just for the possibility of later adding stuff like buttons, swiches, LED:s or buzzers. Ideal would be a pin header for a a few (3 or so) input pins with onboard pullup/pulldown resistors for easily wiring up hard-buttons, and solder pads straight to the processor for as much as will fit on the pcb.

A buzzer sounds like a good idea. To alert to faults and also to notify that printing is competed

For LEDs and buttons not so sure, since that can be done via touchscreen

regards
Andy

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

Quote
kwikius
Looking good DC42

I somewhat hesitate to say this ( but decided to put it out there!) but what springs to my mind is to use the display for a close up view of what is going on at the print head. ie from a video camera. I appreciate this would definitely amount to feature and cost creep, but the QVGA display is perfect for the task I think. A webcam might work but looks like would need USB2 to get a good framerate, though I am no expert on the subject.

Anyway maybe I should put this in a separate thread?

regards
Andy

That would mean a complete redesign!