Tannoo / Marlin

Optimized firmware for RepRap 3D printers based on the Arduino platform.
http://www.marlinfw.org/
GNU General Public License v3.0
1 stars 0 forks source link

UBL LCD Matrix Plotting #4

Closed Tannoo closed 7 years ago

Tannoo commented 7 years ago

@Roxy-3D, this is the 'new and improved' version... ready for improvement.

https://github.com/Tannoo/Marlin/tree/UBL_Mesh_Plotting

Tannoo commented 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.

Roxy-3D commented 7 years ago

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...

Roxy-3D commented 7 years ago

How did you send that message "Okay, I see now." ???

It got emailed to me, but it isn't here???

Tannoo commented 7 years ago

On the commit page: https://github.com/Tannoo/Marlin/commit/70affd36484c3f538988800887c1b34edc724d94

Roxy-3D commented 7 years ago

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.

Tannoo commented 7 years ago

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.

Roxy-3D commented 7 years ago

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.

Tannoo commented 7 years ago

I am unsure why you have encoder issues. I don't.

Roxy-3D commented 7 years ago

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...

Tannoo commented 7 years ago

Maps look okay on yours?

Tannoo commented 7 years ago

I thought you had a 20x4 display.

Tannoo commented 7 years ago

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.

Roxy-3D commented 7 years ago

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.

Tannoo commented 7 years ago

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.

Tannoo commented 7 years ago

Similar to the bottom line of my map screen.

Roxy-3D commented 7 years ago

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.

Tannoo commented 7 years ago

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.

Tannoo commented 7 years ago

But, that could be a neat option.

Roxy-3D commented 7 years ago

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.

Tannoo commented 7 years ago

That's exactly why I said option. Lol

Tannoo commented 7 years ago

Maybe a 1 or 2 sec delay before moving.

Tannoo commented 7 years ago

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.

Roxy-3D commented 7 years ago

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....

Tannoo commented 7 years ago

Fyi, I really do appreciate your help on this.

Roxy-3D commented 7 years ago

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.

Tannoo commented 7 years ago

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.

Roxy-3D commented 7 years ago

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.

Tannoo commented 7 years ago

Okay.

Tannoo commented 7 years ago

You know all about the movement stuff. Have at it. ;)

Roxy-3D commented 7 years ago

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.

Tannoo commented 7 years ago

That would be hard to see for some people, but ok.

Roxy-3D commented 7 years ago

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.

Tannoo commented 7 years ago

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?

Roxy-3D commented 7 years ago

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.

Tannoo commented 7 years ago

Yes, I was just thinking to use the M117 due to the new scrolling on the status screen for the 20x4's.

Tannoo commented 7 years ago

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.

Tannoo commented 7 years ago

Actually....not any more. I held it longer and it stopped with no returning.

Tannoo commented 7 years ago

Okay I'm going to update and squash the branch... done.

Roxy-3D commented 7 years ago

Tonight's lesson is: "No good deed goes unpunished."

Tannoo commented 7 years ago

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?

Tannoo commented 7 years ago

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

Tannoo commented 7 years ago

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;
Tannoo commented 7 years ago

I found that trying to exit while it's moving, gives issues....wait until it's not moving and it will exit fine.

Tannoo commented 7 years ago

I shifted stuff around. And it all still works.

I moved most of the math stuff into ultralcd.cpp.

Roxy-3D commented 7 years ago

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.

Tannoo commented 7 years ago

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.

Roxy-3D commented 7 years ago

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.

Tannoo commented 7 years ago

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.

Tannoo commented 7 years ago

Okay. It's sync'ed. I'm off to bed.

Roxy-3D commented 7 years ago

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!!!