Closed Tannoo closed 7 years ago
I was going to have very similar logic to yours. But I was going to make it so there were not magical hard coded constants in the mix.
That's what I was originally going for, but that was giving me migraines. This is exactly what I was hoping you could help with.
OK... Let me get things working nicely on my display. Mostly it is the encoder wheel that is causing trouble. And I'll see if I can collapse that code...
How did you send that message "Okay, I see now." ???
It got emailed to me, but it isn't here???
On the commit page: https://github.com/Tannoo/Marlin/commit/70affd36484c3f538988800887c1b34edc724d94
Oh! OK! You learn something new every day! I've seen that before where I get an email but there is no associated issue or pull request. I couldn't figure out how people were able to send me an email because GitHub hides the email addresses of everybody.
Yup. I was also trying to figure out where you made the commit. With the link you sent me, there was a link for your commit's title, but I couldn't find the branch to download. Git desktop also didn't show anything new.
I have a few more encoder wheel changes merged into your branch. Tomorrow I'll play with it some more and see if I can figure out why the interactive editing isn't working from the LCD Mesh Map on my machine.
I am unsure why you have encoder issues. I don't.
It was because you have a different Graphics LCD than I do. In Conditionals_lcd.cpp there are these lines:
// Set encoder detents for well-known controllers
#if ENABLED(miniVIKI) || ENABLED(VIKI2) || ENABLED(ELB_FULL_GRAPHIC_CONTROLLER) || ENABLED(OLED_PANEL_TINYBOY2) \
|| ENABLED(BQ_LCD_SMART_CONTROLLER) || ENABLED(LCD_I2C_PANELOLU2) || ENABLED(REPRAP_DISCOUNT_SMART_CONTROLLER)
#ifndef ENCODER_PULSES_PER_STEP
#define ENCODER_PULSES_PER_STEP 4
#endif
#ifndef ENCODER_STEPS_PER_MENU_ITEM
#define ENCODER_STEPS_PER_MENU_ITEM 1
#endif
#endif
It is just something that needed to be tried on several machines...
Maps look okay on yours?
I thought you had a 20x4 display.
I still need to get one of those again. I ordered 2 of them and got jacked.... They sent me a full graphic and then sent a 20x4 that was broken. So, I gave up for a little while on that.
Maps look okay on yours?
I only tried it on 10 x 10 so far...
I thought you had a 20x4 display.
The machine I use for development is a 20x4.
I have one very nice machine with a Graphics controller. I don't usually do development on it. Mostly because it is usually busy but also because I don't want to do things that risk doing a nozzle crash.
But it was not doing anything today and I was using it for this.
Also, for the 20x4, I don't think a radar map would work, but, it could show (X, Y) coordinates and the z_value at the given location. And still click to edit that point.
Similar to the bottom line of my map screen.
Also, for the 20x4, I don't think a radar map would work, but, it could show (X, Y) coordinates and the z_value at the given location. And still click to edit that point.
There are a number of options. One would be to define custom characters and print those. But it would be easier to just move the nozzle to correspond to the location.
So, far, I don't have it moving anything until you click to edit, then it homes and moves to the selected point and starts from there.
But, that could be a neat option.
Yeah... The bad thing about it is it takes so much time. If you over shoot on the encoder wheel, it will take time to get there, and then time to back track. And... as you drop down to a new row, it has to retrace to the beginning of the next line.
It might not be as bad as I'm worried about. It is probably worth trying and seeing how it looks and feels.
That's exactly why I said option. Lol
Maybe a 1 or 2 sec delay before moving.
Sorry... editing posts on the phone is a pita.
1 or 2 sec delay, then move to the position indicated at that time. No buffer.
Yeah.... And with some clever coding... We could have it do non-blocking moves. It might be it can be done in a way that the nozzle trying to get to where the dot is, isn't annoying....
Fyi, I really do appreciate your help on this.
Or... We start moving any time the dot isn't where the nozzle is. But then we do one of two things.
Option 1 is we don't queue up any new moves until the nozzle completes the current move. And where ever the dot currently is, we tell it to move there. That wouldn't be too bad.
Option 2 is if the dot moves to a new location we cancel the current move and start heading to the new dot location. It will be a little schizoid because of the back and fort on the X axis. But it would get to where it is supposed to be very quickly.
With constant movement, the LCD will seem sluggish. Waiting for the dot to stop moving for a sec then move? But, if it is moving, stop movement if the dot changes...wait for the dot to stop moving before moving to the new spot.
With constant movement, the LCD will seem sluggish.
No... We would do non-blocking moves. The nozzle movement and the LCD activity would be independent of each other. Kind of like if a print was going... You can still do things on the LCD Panel. It is a little bit trickier because we need to cancel some moves (if we did Option 2). But end stop movement (or Z-Probeing) does that today. We would have to figure out how to do that. But there is example code we can look at.
Okay.
You know all about the movement stuff. Have at it. ;)
Actually... I've been looking at the custom characters. I think we can do a Postage Stamp map with a dot on the 20x4 LCD Displays... It will take some experimenting. But it can be done.
And the movement stuff will be fun to play with too.
That would be hard to see for some people, but ok.
The 20x4 characters are 5x8 pixels. If the map (not including the border lines) was 6 characters wide in size and 4 high, that would leave a pixel between each dot location. And then you combine in the movement of the nozzle as the dial is turned, people will be able to figure out what they are editing.
It maybe that just the nozzle movement is enough and we don't need to mess with trying to use custom characters on the 20x4 displays. On the 20x4 displays we still get to display the (X,Y) coordinate and indexes. So... Yeah... Maybe that doesn't make sense to do??? But I think I can get 60 or 70 bytes of RAM back by making some simple changes to the custom characters. That doesn't help this problem but it is a good thing to do.
Probably figuring out how to get the nozzle to track the edit location nicely is more important right now.
I was thinking that there's not enough room for a map on the 20x4's.
So.. on those, will this be enough:
enqueue_and_echo_commands_P("M117 " PSTR("(" x_plot ", " y_plot ") " pgm_read_float(ubl.z_values[x_plot][y_plot]));
Or something like that?
I wouldn't do it that way. There is no need to enqueue commands to write data to the LCD Panel. The LCD library lets you say where to start the write (column and row), and you just give it the data you want there.
Yes, I was just thinking to use the M117 due to the new scrolling on the status screen for the 20x4's.
Okay, I just had the chance to test the new additions you applied.
All is good on my end. Even click to edit and Click and hold to quit.
The click and hold is tricky...because there is a VERY short delay (if any) to release the button once the edit has been stopped. If you hold it too long, it goes back to the map. If you let off "just in time", it's stops and all is good staying at the status screen.
Actually....not any more. I held it longer and it stopped with no returning.
Okay I'm going to update and squash the branch... done.
Tonight's lesson is: "No good deed goes unpunished."
BTW... this is where I got that "multiMap" function: http://playground.arduino.cc/Main/MultiMap
I moved it to utility.cpp
. Is there a better file to put this in?
Menu editing screen having refresh issues again and also shows that sometimes it doesn't leave the editing mode: https://drive.google.com/open?id=0B560i8PeUNEraWdUYjlrVjJqQ2s
Putting the lcdDrawUpdate = LCDVIEW_CALL_REDRAW_NEXT;
back in, helps with the edit screen. It's never blank or just the bottom line of the numbers.
float lcd_mesh_edit() {
lcd_goto_screen(_lcd_mesh_edit_NOP);
lcdDrawUpdate = LCDVIEW_CALL_REDRAW_NEXT;
_lcd_mesh_fine_tune(PSTR("Mesh Editor"));
return mesh_edit_value;
I found that trying to exit while it's moving, gives issues....wait until it's not moving and it will exit fine.
I shifted stuff around. And it all still works.
I moved most of the math stuff into ultralcd.cpp
.
I have company so that is going to limit how much time I can spend playing with stuff today and tomorrow. But I'll start trying different things to get the Postage Stamp to move the nozzle in a reasonable way.
I'll probably just do something very simple (and not nice) first... And then start making changes depending on how annoying this or that is.
Same here and I have it moving already but not with blocking moves. I'm trying that next. I was just hammering out the details of homing before the map is displayed. I have that part done now and can commit the changes so you can see what's there now.
I am headed to bed for the day.
I have it moving already but not with blocking moves.
Did you say that wrong? Making it move with blocking moves is easier. Making it move with non-blocking moves is harder.
Please keep it the branch up to date (but in a working state). That way if I have an hour, I can sync... and where we are at and maybe add something or another.
I am doing that just now. My IDE just locked up... mid-upload... So, my printer was stuck at a blank screen and I had to restart my 'puter. Got it and uploaded again.
I was trying do_blocking_move_to_xy
and that didn't work... maybe it was just my implementation of it.
I set it back were it worked and I'm going to update the branch with what I have.
FYI: It homes and displays Homing XYZ
and then goes to the map when homing is done.
---
ALSO FYI: I need to stop the stepper timeout OR go back to status screen if it does timeout. Because it gets locked up on the map and nothing happens without resetting the printer.
Okay. It's sync'ed. I'm off to bed.
That movement for the LCD Mesh Map is nice. It works very well. I wonder, would it make sense to Zig-Zag the nozzle when it switches to the next row? Instead of going back to X=0 when the Y changes, maybe the X should stay in the same location (kind of like the old Grid Based Leveling did with the probe) ? That logic is more complicated so maybe it doesn't make sense to do that.
The motion feels nice. I'm not sure we are going to have to do much more with it.
I wonder if that exit bug I'm seeing is because I don't know how to use the LCD Mesh Map? Shouldn't a Press & Hold get me out of the LCD Mesh Map? Well... What ever is causing it... I'll find it when I get a chance to dig in a little bit.
PS. How many times did you crash your nozzle trying to get the motion working? I'm pretty sure I would have had a few nozzle crashes!!!
@Roxy-3D, this is the 'new and improved' version... ready for improvement.
https://github.com/Tannoo/Marlin/tree/UBL_Mesh_Plotting