Minimal GUI request

[stecor7001]

I tried Teacup, and while I can say it was not as easy as e.g. Marlin, I now have a teacup-enabled printer. I like the firmware is quite efficient, however I think that having the printer tethered to a PC to use it might not be the best... At least, for me, it's quite a hassle.

I was wondering about a GUI - nothing fancy but still a menu-based gui which could work with eithera 4x20 char display or a simple LCD with the basic functions e.g. Home screen

• temperatures - target and actual
• print status
• z position (current)
• filament used thus far (this print)

SD card screen

• list/select file
• print selected -cancel print
• ideally % complete based on total commands in selected sd file

Control screen

• home all -move axis
• disable steppers
• set temp extruder/bed
• set fan speed

Selection via rotary encoder

I browsed through the various lcd branches and could not find a finalized menu system with something like the above. If it exists, please kindly point me to it.

Personally, this is the major lacking feature in the firmware.

Another point I wanted to raise is that, maybe you could consider adding features - i.e. Improve usability, add more configuration params - when the build targets a less constrained architecture. For instance, I had to look through code to figure that, if homing is to be to xmax, then no xmin endstop should be defined for the board... This is not very logical, since physically the board comes equipped with 6endstops, however only 3 are connected... A parameter (or even checkbox - endstop installed) would be more obvious to average users.

Thank you.

[Traumflug]

I think much of the confusion is that Marlin is kind of a standard. People simply expect this way to be the "right" way. Writing documentation doesn't help much, so we'd have to make Teacup more complicated to match expectations.

That said, there are certainly opportunities to improve the Configtool GUI. There one can add more complex calculations without disturbing printer runtime performance. Checkboxes and fields there don't have to have a 1:1 relationship to config file entries. For example, one could remove the endstop pin definition if the corresponding X_MIN field is empty. Or group that pin definition together with the X_MIN entry field.

Regarding the firmware GUI: infrastructure for an SD card and these character displays is there. Rotary encoder not, no menu either. Feel invited to hack away on it. For regular maintenance there are schedulers in clock.c, stuff like keyboard polling can go into dda_clock() in dda.c. Not lengthy tasks in the latter, please, just test the key and set a flag for handling it later. Code triggered via clock.c functions can be lengthy, it can't disturb stepper movements there.

If you want to have write access to the repo, just say so. Branches for each task are much better than forks and pull requests.

[stecor7001]

Thanks for a quick response.

Related to the configtool, I agree it could stand improvements, however it's convenient as it is. On removing the pin defs, sure it can be done (I commented it in the boadr config instead) - it's just that it is not obvious to a user... That's all i meant.

Related to the menu/encoder stuff, I see a few tried before. I think there are at least 5 variants of lcd/menu - all of them old, except maybe for wurthnase's one I guess...

Could you provide some pointers/recommendations on what to do? I am wondering as to why neither variant was included in the master branch... Is it that all teacup users see no need in having an independent printer? Just curious here.

Anyway, what I might end up with were I to build some code would be either a 4x20 display or a 320x240 ili9341 + rotary encoder hooked up to a due and a modified ramps. My other setup is a Rumba + RRD display controller, but this one I am not sure I would change since i need it to print things :)

thanks

[stecor7001]

... Related to encoder reading, I was thinking about using either the clock() or clock10ms() functions under clock.c, since this is kind of "low priority" code, and ancoder reading should not compete with acceleration or move calculation. The encoder should be responsive when setting up a print, after that it's usually not touched.

Thanks for your insight

[Wurstnase]

I have some code somewhere for an example of a menu. I'm using this at work already. This is pretty easy to extend with new menus and functions. When I find it, I can upload an example.

Also there I'm using just two buttons to go through. Short key press for scrolling up and down. Long key press to change the menu. It's close to what I've uploaded before. But the new code is much cleaner.

[stecor7001]

Thanks, that would be appreciated.

I already looked at Repetier's menu, and was thinking about shamelesly snatching menus from either R or M, trim them down and use them.

Two other things:

1. The master branch currently relies on the display r/w pin, and even checks if the display is busy. RRD does not even connect r/w and in my experience, once the display is init, with the exception of clear_display, there is no reason for the check. Hence, I'd like to do away with the r/w pin.

2. A few updates are needed to handle more than 2x16 - one of them is cursor position whinch only work for the first and second rows as it is... Also, I am not sure I understand why the change in strategy for displaybus...

And finally, driving a char-based display is so significantly different compared to a graph lcd, I really wonder if it's worth trying to keep the ui logic neutral - seems to add too much complexity.

Another thing - did anyone look into ESP8266 as a web-based frontend? There is a beta working for Marlin/Repetier. Could be done if a second serial port is available. That would be a cool interface while adding minimal overhead :)

[Wurstnase]

The menu I made is a simple state machine. Easy to extend with text and functions. Not the macro-mess from Marlin.

[jgrjgr]

re: esp8266 web based front end this is a good idea and the documentation and example code on it is very good and a simple web should be doable in a couple of hours with a basic understanding of html and thanks to ease of the libraries they have built for it, there is a telnet to serial type of example code that could be used straight away as is to talk to teacup through a telnet session as well

hardware wise all you need level converter , personally I've been using the wemos d1 minis which can be had for $3 - $5 and I've been using them for everything , i do have plans for a 3d printer web based gui but it'll be from a more universal angle so it could be plugged into marlin or teacup or (puts on fireproof suit) smoothie.. but i have an engine efi project to get through first

[phord]

I bought a RRD board to use with my last printer build. I used Marlin for the build initially but I had several problems with it, probably due mostly to my unfamiliarity with it. Having the LCD control was nice, I guess, but also a bit sporadic and sometimes broken.

When I switched over to Teacup my controller problems ~vanished~ were replaced with different problems; but I could fix those easily enough, and I didn't miss the LCD. I was going to try to write an interface for Teacup for it, but the pinouts are not clearly defined anywhere. The quick solution would be to derive the controls from the Marlin code; but looking at that made me kind of sad.

Once I hooked up my OctoPrint controller (running on a PiNE64, this time), the work on writing the LCD interface was only for the challenge and not any use for myself. I had other things to do, though, so the challenge was not motivating enough. :-\ The RRD went back in a box. If anyone wants it, I can send it. You'll need something like RAMPS ($5) to interface it.

I got a touchscreen controller for the RasPi, too. If I remember right, it was cheaper than the RRD; $35 instead of $45. I didn't find it to be very useful for me, though, and the graphics are a little slow to update. Back in the box.

[stecor7001]

Funny you say the pinout is not available - I could find it in the Reprap wiki (latest schematic or so).

I see your point re Octoprint, this is why I mentioned from the start - minimal gui. Just the basics: home the machine, jog axes (for bed levelling), heat it up and launch/cancel a job.

The rest can be handled externally, but makes sense to have this access level on board.At least Imho :)

On the esp8266 front, there is progress on the esp3d project by Luc. Personally, esp8266+ a basic gui is just the ticket for me - can use wifi for 3eur or so, use my pc to slice things up... for me, slicing is part of designing a part, so not too helpful if raspbian does it.

To each his own I guess... I will try to get something working and chime back in. Looks like interest in an integrated gui is limited though.

Wurstnase, if you would like us to take a stab at a menu please let me know. Was looking at R's approach last nite and it looks interesting. I take it M's sucks by what you said.

Thanks all

[stecor7001]

Just a quick update on my side:

• I started making changes to the code, based on the current experimental branch, and it seems to work - at least, my 4x20 RRD display is now alive. Here are a few things I noticed:

1. The original code requires additional delays - e.g. 16 as opposed to 15 ms for HD44780 initialization AND a 2ms delay after LCD CLR is issued.
2. As inferred above, LCD CLR is an "expensive" command, thus can be restricted to screen changed. With minimal effort, we can ensure we over-write existing display contents without a clear

Structure - as mentioned previously <> I am not fond of the displaybus approach. Also, it seemed like display_HD44780.c was included in display.c as they were cross-referencing functions. I took the liberty of changing the structure a bit, as follows:

a. HD44780.[ch] is the "low-level" device driver file b. display.[ch] is the abstracted interface. c. displaybus not used any longer; physical display abstraction can be done via conditionals in display.c/h

Other minor things: reduced overhead for Display-Set-Cursor from 3 bytes to 2 (LCD memory address fits in a 1-byte value for text displays, and graph ones are another matter entirely). Added one function (for now) to report the TGT heater temps (similar to get_temp()) so the screen displays the actual vs tgt temps.

I needed to setup DIO7 as a fan output, the Configtool does not allow me to, however good ole config edits allow it very nicely thank you.

I just wanted to let you know that this is being worked on, not abandoned (yet)...

IMHO, graph displays should be handled... graphically :) thus, icons should be used instead of text, and menus/submenus could also be graphical... thus, I think there is little point in having all-text menus in a graphical UI setup.

**** I have an (unrelated) question, and rather than opening another post, I am dumping it here:

• printed part surface quality - while straight lines are definitely better than e.g. Marlin's, corners AND layer changes are not. I am using the default acceleration profile, and there are blobs collecting at corners and on seams during layer change. I wasn't using "retract on layer change" with M, but enabled it now... it helps, but only moderately - any pointers? Should I use another acceleration profile?

It seems to me like M and R are not pausing the X&Y movement during Z adjustment. This may make sense if the next layer start point is the same as the previous layer end point. Thus, less blobbing. I believe Teacup awaits Z move completion, then restarts X&Y movements. If this is the case could Z moved be done in non-blocking mode as long as the Z change does not require an X&Y repositioning?

Thank you!

[triffid]

Blobs at corners are often caused by too little acceleration - the nozzle flow rate lags behind the extruder and thus will over-extrude when entering a deceleration and under-extrude during acceleration. Minimizing the size of the decel/accel near corners greatly reduces the visible results of this effect, but also places higher mechanical forces on your machine and thus you have to choose a balance between required stepper torque and corner quality.

As for motion combination, that's entirely dictated by the gcode. If the incoming gcode says stop XY, move Z, move XY, that's what teacup will do. If the incoming gcode says move XYZ all at once, again that's what teacup will do.

On 20 March 2017 at 17:04, stecor7001 notifications@github.com wrote:

Just a quick update on my side:

• I started making changes to the code, based on the current experimental branch, and it seems to work - at least, my 4x20 RRD display is now alive. Here are a few things I noticed:

  1. The original code requires additional delays - e.g. 16 as opposed to 15 ms for HD44780 initialization AND a 2ms delay after LCD CLR is issued.
  2. As inferred above, LCD CLR is an "expensive" command, thus can be restricted to screen changed. With minimal effort, we can ensure we over-write existing display contents without a clear

Structure - as mentioned previously <> I am not fond of the displaybus approach. Also, it seemed like display_HD44780.c was included in display.c as they were cross-referencing functions. I took the liberty of changing the structure a bit, as follows:

a. HD44780.[ch] is the "low-level" device driver file b. display.[ch] is the abstracted interface. c. displaybus not used any longer; physical display abstraction can be done via conditionals in display.c/h

Other minor things: reduced overhead for Display-Set-Cursor from 3 bytes to 2 (LCD memory address fits in a 1-byte value for text displays, and graph ones are another matter entirely). Added one function (for now) to report the TGT heater temps (similar to get_temp()) so the screen displays the actual vs tgt temps.

I needed to setup DIO7 as a fan output, the Configtool does not allow me to, however good ole config edits allow it very nicely thank you.

I just wanted to let you know that this is being worked on, not abandoned (yet)...

IMHO, graph displays should be handled... graphically :) thus, icons should be used instead of text, and menus/submenus could also be graphical... thus, I think there is little point in having all-text menus in a graphical UI setup.

**** I have an (unrelated) question, and rather than opening another post, I am dumping it here:

• printed part surface quality - while straight lines are definitely better than e.g. Marlin's, corners AND layer changes are not. I am using the default acceleration profile, and there are blobs collecting at corners and on seams during layer change. I wasn't using "retract on layer change" with M, but enabled it now... it helps, but only moderately - any pointers? Should I use another acceleration profile?

It seems to me like M and R are not pausing the X&Y movement during Z adjustment. This may make sense if the next layer start point is the same as the previous layer end point. Thus, less blobbing. I believe Teacup awaits Z move completion, then restarts X&Y movements. If this is the case could Z moved be done in non-blocking mode as long as the Z change does not require an X&Y repositioning?

Thank you!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Traumflug/Teacup_Firmware/issues/266#issuecomment-287705339, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKBGpFmOrwV0obV-AYm9VLI0__hlg5tks5rnkEfgaJpZM4Mfg_g .

[stecor7001]

Thanks Triffid! I gathered as much, so was wondering if the lack of acceleration is caused by the different accel profile or it is something else. For comparison purposes, I am running Teacup as well as M & R with the same accel and feedrates... not sure about jerk units though - using the default Teacup jerk vs 20.0 in both R & M.

Another issue I ran into is that Teacup allows full moves when not homed yet... this is a bummer, my X-carriage crashed into the endstop (the machine was just booted and mis-clicked). Is there a way to prevent moves before homing? Or maybe the first attempted move yields an autohome first? Upon boot, the machine thinks it's at 0,0,0 which is definitely incorrect in my case.

Thanks!

[stecor7001]

Hello Traumflug, All,

Just to let you know I have a working (albeit pretty beta) menu working with most of the initially requested functionality completed. The only item remaining is to do the move[XYZE] actions, which is no biggie. Menu and SD management were the most time consuming items.

You mentioned once that you would rather we branch out Teacup than Fork, so if that still stands, kindly allow me access (you could create a branch - RepRapDiscount 20x4 controller or so for me).

Please let me know if you would like details related to the changes. There are still things that need work, mainly:

1. I had to take out the SSD1306 display implementation (mainly when removing display_bus). We can put it back in (I would go with conditionals in display.[ch]), but would be worth checking this works at the same time. As I have no SSD1306 display, this is pretty hard to do though...
2. I have not fully implemented conditional includes for dealing with the case when a display is selected and no entry method exists. Also, if no display is defined, things might get flakey, but should not be too hard to deal with...
3. This may be a bit harder - the SD implementation is geared towards Serial comm. Obviously, this would not do for menu interaction, so I had to duplicate some SD functionality in lcd_menu.c. Bummer is that there are some static vars required by pff, which essentially get defined twice. If you would like to discuss this, I'd be happy.
4. Lots of other things - does not work with anything else than a 4x20 display (actually, it could work, but screens are designed for 4x20). Will not use any other input method than rotary encoder, however should be easy to add a 5-way switch array instead of a rotary encoder. For now at least, I do not think I would work on any other screen layout or input method. I would rather port this to ARM first.
5. Adds about 5k Flash, and not a lot of RAM extra usage. 5K Flash is not a big deal (I think no-one uses less than a 644 nowadays) and most of the extra RAM is caused by duplicating the SD static FATFS sdfile;
   static FRESULT result;
6. Added a few parameters to the board config files (rotary encoder stuff mostly) and probably the configtool needs updating.

So... please let me know if there is any interest on your side, Thanks

[Traumflug]

You mentioned once that you would rather we branch out Teacup than Fork, so if that still stands, kindly allow me access

Welcome to Teacup development! The rules are simple: create as many branches as you feel need for, but don't touch branches of others (for now). Regarding the general strategy, see issue #81.

I think no-one uses less than a 644 nowadays

Quite a number of Teacup users run an Arduino Mini based controller, which happens to be powered by an ATmega328.

removing display_bus ... does not work with anything else than a 4x20 display

Hmm. The current infrastructure is carefully crafted to be extensible as well as fast and not disturbing the printing process. Printing from SD card works, file listings work, 2x40 LCD displays work, so I wonder what major changes are needed for extending that by an encoder and two additional display lines.

It'll be interesting to look at your code.

[Wurstnase]

@stecor7001 Please don't push anything to other branches. Especially master and experimental!

When you have new features make a new branch. On your local desktop:

git checkout -b my_new_feature
...do changes here...
git add .
git commit -m"my new feature"
git push -u origin my_new_feature

[stecor7001]

Thank you - a new branch is now created.

Please take a look - the new branch is called rep_rap_discount_lcd_rot_enc; It compiles for my setup. I did add some "garbage" though - two config files (one printer and one board) - the board one does contain the new params.

If you have the hardware handy, please give it a whirl. It is based on current "experimental".

Let me know what you think, please...

@Wurstnase - I am kind of new to git, and using the visual tools (which seem to work just fine though). Any pointers are welcome though!

[stecor7001]

Here are two pics on what the screen looks like... excuse the "temperature"... I will get around to connecting a 75KOhm resistor to the thermistor inputs...

[stecor7001]

And what a menu looks like...

[Wurstnase]

Stop uploading stuff to master. When you use a tool besides git, please stop using it.

[Traumflug]

I wish we could install something like Gitolite (distinct user privileges for distinct branches). As far as I can see, no option on Github, though.

@Wurstnase, looking at the current Teacup repo, you fixed it already, right?

Regarding the new code: yes, looks nice. A few bits:

• I see no reason to duplicate SD card reading code. It should be possible to use the same functions as the ones used for SD-card related G-code.
• Same for display bus. It might be easier to copy&paste stuff from elsewhere, but there's a reason why Teacup did it the way it currently does. For example, if a user happens to have such a HD44780 display connected not directly, but via I2C.
• Looks like squashing (git rebase -i, then using 'squash') all the commits together is a good idea, then reviewing one functionality at a time, making a distinct commit for each of them.
• Personal configuration files shouldn't go into the public repo. A generic one for a specific printer is fine, though.
• Please try to match existing code formatting, like no tabs, indentation by two spaces, space between if and (, and so on. :-)

[stecor7001]

Hello All,

Apologies for the trouble caused. For what it's worth, I used the GITHub Windows utilities. As far as I know, I did select the proper branch when synching. Whether there is a fluke related to IE or (more likely) it is my lack of experience with GIT, I don't know, but what I ask is that you pull my access to the repository. Should I provide any further code updates, I will do it by attaching files to issue logs or some such. Thanks for your resolving it and sorry for the inconvenience.

I realize that I might be seen as coming in strong, criticizing things you spent countless hours on. Let me assure you, gentlemen, this is definitely not the purpose of this message. What I wish is to report back my experience, and let you choose what you do next with the info provided

For me, the main reason to consider Teacup is code efficiency, class-less approach and shying from float usage.
User perspective here: I read on the Wiki that Teacup supports LCDs, and I thought fine, it's what I need - a nimble, simple firmware that works better. The reality was somewhat different (I detailed it over in the beginning of this thread); again, these are facts, not meant to offend - they are my experience, should it help in any way - LCD support, as defined now in Master or experimental branches, is NOT working for 3d Printer LCD panels, because:

1. LCD Read checks are implemented. There is no panel I am aware of that implements LCD read-back, and further checking in Marlin reveals that the developers there think so as well. Thus, one either must re-wire existing panels to bring out a R/W pin connection, or the code needs an overhaul
2. Delays not implemented per datasheet - this may be a consequence of (1) above, but when LCD addressing is Write-only mode, delays are critical. Thus, my first attempt to just remove the need for LCD read-backs failed.
3. LCD interface as it currently stands is limited to 2 rows only.

Even once the LCD display is started, it is mostly a very basic status display device; no entry method exists

Menus (maybe a consequence of lack of user entry interface) are not implemented

SD card support - it only exists as a mix between GUI and M-Code interaction

In my opinion the code is very well written, since (as a case-in-point) I was able to deduce what was missing to get an LCD up and running. This is testament to all the hard work that went into building and maintaining this project.

That said, I (again, as a user) think that without a series of improvements to the UI, the package is lacking compared to competing offerings. What I did was to attempt to help by doing some of the work related to a UI. As Traumflug mentioned elsewhere, he is very familiar with code structures and it is easy for him to determine how changes are best implemented. My intent here is to add in functionality which (IMO) is a basic must and also give back when I take. If you see no value with the code, pls disregard. If you want to include some of it in a future release, feel free to do so. This is my contribution for the work you made and I use(d).

Wishing you the best, Stefan.

P.S. @Traumflug : related to

•I see no reason to duplicate SD card reading code. It should be possible to use the same functions as the ones used for SD-card related G-code.

Please take a look at e.g. sd_init and see that the function returns void. Status reporting is hard-coded to serial. Same for sd_list which dumps strings to serial. I fail to see how the functions can be re-used. Also, as a personal opinion, the serial line should be disregarded while un-tethered, to improve performance. Only STOP commands or so should be listened to in my opinion. These are architecture decisions, and you're the one that should make them, not a (new) contributor.

•Same for display bus. It might be easier to copy&paste stuff from elsewhere, but there's a reason why Teacup did it the way it currently does. For example, if a user happens to have such a HD44780 display connected not directly, but via I2C.

Display bus is, in my opinion, not very useful at this time. Should you indeed support multiple displays, it may be useful, however please ponder on the following:

1. 4-bit (or ummhh 8-bit, if someone wants it) display bus for an HD44780 would be a dedicated connection. Fast, true, but single-purposed, thus can be optimized for the purpose.
2. I2C is a shared bus, and it makes sense to re-use I2C code for other bus participants. Also, I2C is abhorrently slow, thus delays needed for 4-bit bus would not be needed with I2C. SPI might be a better choice for a display imo. Also, there is more overhead with I2C when performing intensive operations such as display updates. I2C should be fine for sensor reads, but is it the way for a display? I wonder...
3. SPI (currently unsupported) might make a better bus alternative for a display bus than I2C, even more so when DMA is available... but then, we're talking ARM, not AVR.

Again, these are arch decisions that are best sat with you.

•Looks like squashing ( git rebase -i , then using 'squash') all the commits together is a good idea, then reviewing one functionality at a time, making a distinct commit for each of them.

As far as I am concerned, this is all one feature. The feature is a GUI, and it needed multiple bricks in :)

BTW - I could use some help related to axis motion, if you wish to suggest an approach. As mentioned, I think it's silly that Teacup happily moves wherever without homing first. Any pointers on what to change would be welcome.

•Personal configuration files shouldn't go into the public repo. A generic one for a specific printer is fine, though.

Purpose for the BOARD file is to showcase the additional params related to Rotary Encoder and LCD updated format. Added the PRINTER file because it is a standard printer, so may help anyone with a Sharebot NG 1-EX

•Please try to match existing code formatting, like no tabs, indentation by two spaces, space between if and ( , and so on. :-)

Well, thanks for the pointer. Using PN, and the original code displays all over the place (e.g. clock.c which is pretty mis-alligned on my screen). Are you using Eclipse?

Again, thanks for your time and help through this. Should I have further code updates, I'll attach here.

Bye for now.

[Traumflug]

Apologies for the trouble caused.

No problem. Git has proven once more that even unexperienced users can't mess it up ... because each other user has a (working) copy, too. Unfortunately, Github tries hard to make the Git experience as messy as possible and there's not much we can do about this. Github is simply too popular. Also, commenting features are quite good.

Should I provide any further code updates, I will do it by attaching files to issue logs or some such.

Github doesn't allow to upload patches, unfortunately. One can append files here, but patches get rejected.

Git is quite powerful. Much more powerful than other source code management systems. This comes at a price -- a rather steep learning curve. Command line 'git' and 'gitk' are the tools to work properly with Git. I'd recommend to exercise one of the many tutorials and watch what's going on using gitk --all. Both tools are in the package Git for Windows.

For me, the main reason to consider Teacup is code efficiency

This is the result of reviewing every piece of code again and again. Much more work than just getting a particular controller into a "works for me" state :-)

LCD Read checks are implemented. There is no panel I am aware of that implements LCD read-back

I have a cheapo 16x2, HD44780 based display here and the R/W pin is accessible. That display does work, showing a regularly updated status screen. This gives me some confidence that the implementation can't be that wrong :-) Did you try this as-is?

If your R/W pin is not accessible, well, then we need something with delays. Along these lines:

#ifndef DISPLAY_RW_PIN
  delay_ms(50);
#endif

Menus (maybe a consequence of lack of user entry interface) are not implemented

That's correct and also the reason why your code is very welcome. Others tried on this task, too, the result is what we have now. There is more code in one or another branch, but not brought into a proper shape, yet.

LCD interface as it currently stands is limited to 2 rows only.

Also correct and extending that to 4 rows should be as simple as adding a third definition in display.h, around line 30. And to do something useful with this new room without breaking things for smaller displays. Like (written without testing):

void display_clock(void) {

  display_clear();

  update_current_position();
  sendf_P(display_writechar, PSTR("X:%lq Y:%lq"),
          current_position.axis[X], current_position.axis[Y]);

  #ifdef HEATER_EXTRUDER
    display_set_cursor(1, 0);
    ...
  #endif
  #ifdef HEATER_BED
    display_set_cursor(1, DISPLAY_SYMBOLS_PER_LINE / 2);
    ...
  #endif

  #if DISPLAY_LINES >= 3
    // display something on line 3
  #endif

  #if DISPLAY_LINES >= 4
    // display something on line 4
  #endif
}

SD card support - it only exists as a mix between GUI and M-Code interaction

Each of these interactions is implemented in a single function, so it should be possible to call that function from menu code, too. Just the way gcode_process.c does. If there's something missing, like a proper return value, add it (instead of re-implementing the whole thing)!

I2C is a shared bus, and it makes sense to re-use I2C code for other bus participants.

I hope it's implemented this way! For now there's one device using this bus, it should be reasonable effort to extend this to more than one, even running at the same time.

SPI might be a better choice for a display imo.

That's not Teacup's decision. Teacup can hopefully support all of them.

SPI (currently unsupported)

SPI is certainly supported. SD card code uses it, also some of the temperature sensors. Using it for a display is a matter of getting such hardware and 'wiring' it up by #ifdef's.

OK, I agree that it's sometimes a bit hard to think in terms of "should work for every controller", because on each user's desk is only one controller. Sometimes one has to guess a bit on how other controllers work. Still it's much better to do such guesses than writing completely separate code for each of them. Writing code matching only one controller is faster in the beginning, but becomes a maintenance nightmare later on.

I think it's silly that Teacup happily moves wherever without homing first

Many people don't "home" at all :-) Traditionally, executing commands in an appropriate order is a G-code senders' task. With a display for standalone operations, it'd be a task for the menu interaction code.

Now, happy coding :-)

[jgrjgr]

can i suggest simply out of experience that since a lot of lcds that have been made for 3d printer boards aren't using the r/w pin that it's a good idea to have the firmware periodically reinitialise the lcd screen, even if it's on inserting a sdcard, my main reason for this is most of the wiring for the lcds especially the rumba boards and smart lcd tends to be on the limit of length and is totally unshielded , previously i would get garbage on my screen so i modified marlin at the time to reinit the lcd when the sdcard was intserted or the button was pushed

[Wurstnase]

Apologies for the trouble caused. For what it's worth, I used the GITHub Windows utilities. As far as I know, I did select the proper branch when synching.

Don't really worry about this. I've overwritten the master-branch in my first days. Github Windows isn't very good for other repositories. But Github for Windows has also a shell. You should use this instead of the graphical interface. In the beginning it's not that easy, but you can control everything much easier.

The first commands you need is: git status: see where you are and which files changed since last commit git add filename: add files for a commit, a dot will add any files in that folder and subfolders git commit: make a new commit for the added files git checkout branch: change to a branch. master, experimental, any other branch git branch: will create a new branch from that where you are git push origin my_branch: upload your branch git push -u origin my_new_branch: upload your new branch

I guess this are the most important commands for the first time.

[triffid]

Heh I use git checkout -b branchname for creating branches, and I make a lot of use of git add -p (select individual hunks from a file to add) - great for separating relevant changes from debug code when I'm building a commit set without having to clean everything up before each commit.

I use qgit4 for viewing, but I've never encountered a gui git client that was actually usably good at repository management.

Seems like everyone has their own way of using git :)

On 30 March 2017 at 03:49, Nico Tonnhofer notifications@github.com wrote:

Apologies for the trouble caused. For what it's worth, I used the GITHub Windows utilities. As far as I know, I did select the proper branch when synching.

Don't really worry about this. I've overwritten the master-branch in my first days. Github Windows isn't very good for other repositories. But Github for Windows has also a shell. You should use this instead of the graphical interface. In the beginning it's not that easy, but you can control everything much easier.

The first commands you need is: git status: see where you are and which files changed since last commit git add filename: add files for a commit, a dot will add any files in that folder and subfolders git commit: make a new commit for the added files git checkout branch: change to a branch. master, experimental, any other branch git branch: will create a new branch from that where you are git push origin my_branch: upload your branch git push -u origin my_new_branch: upload your new branch

I guess this are the most important commands for the first time.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Traumflug/Teacup_Firmware/issues/266#issuecomment-290204808, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKBGstRTAmEylRuaJSEEm3ro0wZu-L4ks5rqrXcgaJpZM4Mfg_g .

[Wurstnase]

git add -p looks pretty nice. Thanks for that hint, @triffid.

[stecor7001]

Hello All,

Thanks for the encouragement related to GIT. Seems like console is the way to go. It seemed seamless using the "file explorer"... people should give the git guys some feedback :)

@jgrjgr

... out of experience that since a lot of lcds that have been made for 3d printer boards aren't using the r/w pin ...

Yep, this is true - while R/W exists on the display, no one cares to connect it to anything else but GND; I am not aware of even ONE panel that does it; of course when one builds their own, anything goes! If anyone cares, the reasons are historical; HD44780 is hardly new tech, and since the old days, it proved to work reliably when the datasheet is abided to. I never had issues with lcd corruption with the driver included, and I let it run multi-hr prints. If I may suggest I would look at:

• weak contacts in the connectors/ribbon IDC connectors
• shielding the cables

...firmware periodically reinitialise the lcd screen, even if it's on inserting a sdcard, my main reason for this is most of the wiring for the lcds especially the rumba boards and smart lcd tends to be on the limit of length and is totally unshielded ,

I use a RUMBA as well; rock solid, however my cables are shielded by the case (it's stainless), and you're right - they are quite long at 65cm or so. Never re-init the LCD and never needed it either. Also, there is a nifty feature on the SD card - a contact which signals card state (in or missing). This is cool to use as a status message (I will update the status sometime in the firmware).

@Traumflug

If your R/W pin is not accessible, well, then we need something with delays. Along these lines:

Yep; precisely what I did in the new driver file, and of course you meant delay_us(50) not ms. Actually, delay_us(40) is sufficient (and by the book).

... extending that to 4 rows should be as simple as adding a third definition in display.h, around line 30. And to do something useful with this new room without breaking things for smaller displays. Like (written without testing):

Please take a look at display_set_cursor - it is hardwired to 2 lines. Further, this is the point I tried to make - rather than hardcoding what goes where in the display module, would it not be better to have an interactive screen? This is what the PROGMEM defs in lcd_menu_define.h do. They specify a number of screen layouts, and there are associated update functions which fill in the variable contents of the screen with actual values.

What I am trying to say is - you have a workable interface, written by (yours truly) - a non-expert in Teacup; the changes are not large ~1000 lines or so. Quite lean, and this is NOT based on Marlin or R code, either. And quite efficient too, IMO. Proven to work, at least on a defined setup. What you could do is take a look, see if it fits in your roadplan and take it from there. Should you wish to discuss I would be happy to do so. For me, it fits the bill and I don't think the overhead is unwarranted. FWIW, I am making Teacup deaf to serial on my machine while SD Printing... that's gotta be worth some CPU cycles.

Again, if you wish us to have verbal contact, we can arrange a Skype call or something. I realize looking at someone else's code may be less than one's favorite pass-time so if interested, we can exchange contact info via email.

Wishing you ALL a great day! S

[Wurstnase]

What you could do is take a look, see if it fits in your roadplan and take it from there. Should you wish to discuss I would be happy to do so.

There is no "roadplan" for Teacup. We are a pretty small developer team.

What I've mean is, if you have a feature, which could be implemented some time, program it. Read the current code, take your time and discuss it here. I start two years ago with the port of the STM32 µC. And the code is just 1 week in the experimental fork. Some code needs more time, some less.

But it's on you to make a proper code. Help us to improve it. Take the experience from us and bring your new code to a state where everyone can use it.

[jgrjgr]

@stecor7001 , i couldn't agree more on the topic on shielding the cable however this isn't always done by the end user and there is from time to time rumba boards even from reprapdiscount which have made it through the quality control process which otherwise shouldn't have and i've had to diagnose and repair them and most of the time it comes down to a dry solder joint or missing solder on a pad, for our situation where we have the capability and experience in this sort of thing that is ok, however for the end user i do strongly suggest that even if it's just on the sdcard insert event the lcd gets re-initialised if nothing else out of sheer principal due to the common lack of r/w line connection , the code is already getting compiled in anyway so it's not going to slow down anything and would only take up a negligible amount of program space...

[triffid]

On 30 March 2017 at 14:32, stecor7001 notifications@github.com wrote:

Thanks for the encouragement related to GIT. Seems like console is the way to go. It seemed seamless using the "file explorer"... people should give the git guys some feedback :)

graphical git is a 'seamless' way to make a confusing mess ;D

[Traumflug]

@stecor7001

Please take a look at display_set_cursor - it is hardwired to 2 lines.

I see this code:

void display_set_cursor(uint8_t line, uint8_t column) {
  display_writechar((uint8_t)low_code_set_cursor);
  display_writechar((uint8_t)line);
  display_writechar((uint8_t)column);
}

I don't see any hardwiring here. If this code happens to work for two lines only, perhaps because 4 lines need more than these three bytes sent, please add them. Ideally wrapped with #if DISPLAY_LINES > 2 ... #endif

[stecor7001]

Hello Traumflug - please see below what I meant. The issue is that it just switches to addresses 0 (row 0) or 0x40. It misses 14 and 54...

Again, this is stuff that's taken care of in the code I wrote.

Hth, Stefan

set_cursor: /* Set the cursor to the given position. This is a three-byte control command, so we fetch additional bytes from the queue and cross fingers they're actually there. / command = 0x80; // "Set DDRAM Address" base command.

    /**
      Add address of line.
      As we have two lines only, this can be "calculated" without
      a multiplication.
    */
    buf_pop(display, data);
    if (data) {
      command += 0x40;
    }

    // Add column address.
    buf_pop(display, data);
    command += data;

    displaybus_write(command, parallel_4bit_instruction);
    break;

[stecor7001]

@jgrjgr Thanks for your points; actually, re-initialising the LCD is very costly in terms of time - takes upwards of 3ms + cls. Marlin does have some code which attempts a recovery, but needs compiling in. I believe they say it's pretty uncertain it'll work.

Stefan