Closed Tannoo closed 7 years ago
New logo:
New button icons
Wow... That looks nice...
I thought so. The logo needs some cleanup, though.
So, now that I have got customizing the images correct and working... on to trying to create more menus.
I applied the M408
JSON responces PR (6970) to my Marlin and added a screen number for MOST screens in Marlin. I'm hoping to get the MKS to change based on the Marlin screen selected by another LCD. Basically, to stay 'on track' with what's currently happening.
But, I've got to figure out how to create other screens on the MKS.
So far, 62 possible screens.... I see a LOT of work in my future. LOL
I switch my printer back to the glcd and the ubl map is partly broken. I brought back a small part of previous code to make it work for me.
Take a look and see if you can fix what was broken. I will post the code section a little later, if you don't have time to look for yourself.
It's the section that plots all the grid points in the box.
Which branch should I be looking at? Can we just compare the code with the previously working stuff to find the error?
Yes, I did that.
Here's the code in question:
// Display Mesh Point Locations
uint8_t i, j;
u8g.setColorIndex(1);
for (i = 0; i < GRID_MAX_POINTS_X; i++) {
for (j = 0; j < GRID_MAX_POINTS_Y; j++) {
u8g.drawBox(x_offset+i * pixels_per_X_mesh_pnt + pixels_per_X_mesh_pnt / 2,
y_offset+j * pixels_per_Y_mesh_pnt + pixels_per_Y_mesh_pnt / 2, 1, 1);
}
}
// const uint8_t sx = x_offset + pixels_per_X_mesh_pnt / 2;
// uint8_t y = y_offset + pixels_per_Y_mesh_pnt / 2;
// for (uint8_t j = 0; j < GRID_MAX_POINTS_Y; j++, y += pixels_per_Y_mesh_pnt)
// if (PAGE_CONTAINS(y, y))
// for (uint8_t i = 0, x = sx; i < GRID_MAX_POINTS_X; i++, x += pixels_per_X_mesh_pnt)
// u8g.drawBox(sx, y, 1, 1);
The commented parts are in the current code base (bugfix-1.1.x). And all it does is put the mesh dots on the left column...no more.
The uncommented, is the previous code that works (On my printer now).
I am unsure how to correct the new code to work as before. I tried a few different things.
There's no real need to correct it now....the 32-bit stuff is more pressing.
I'm thinking it's in this line:
for (uint8_t i = 0, x = sx; i < GRID_MAX_POINTS_X; i++, x += pixels_per_X_mesh_pnt)
.
I don't know what that line is going to do. The reason is I don't know the order of evaluation of that stuff. I don't like those complicated types of code. It is too hard to see what is happening. It is also possible the PAGE_CONTAINS() macro isn't even allowing the loop to run... It might be good to put those uncommented loops inside PAGE_CONTAINS()'s control to make sure the macro isn't errantly stopping the mesh points from being plotted.
ok.. I'll try that. BTW, I am switching to dayshift for 6 weeks.
There are a couple of small bugs in the Graphical LCD code on the 32-bit Re-ARM board. I put your name very high on the list of people that should get Re-ARM boards. And p3p has changed the default configuration of the Re-ARM branch to build with UBL turned on. The LCD bug (with a selected menu item having the lines around it drawn wrong) probably doesn't need the board attached to a printer to get it fixed. But the rest of the UBL LCD Menu stuff probably will need the board attached to a printer.
I don't know that this idea is practical. But if you have a RAMPS based system, you might be able to just unplug one processor board and plug in the other. That way, your printer wouldn't be non-functional when you actually want to use it to print something. (In other words... The RAMPS board never gets disconnected from the printer. It is the processor board that gets disconnected from the RAMPS board.)
Is the 32-bit code printable atm?
I'm not sure... But it is close. The thing is, if you care about what you are trying to print, you probably don't want to use the 32-bit code yet. But you can tell just from the LCD panel, it is close.
Ok. cool.
This was near the top of the DOGM file.
// For selective rendering within a Y range
#define PAGE_UNDER(yb) (u8g.getU8g()->current_page.y0 <= (yb))
#define PAGE_CONTAINS(ya, yb) (PAGE_UNDER(yb) && u8g.getU8g()->current_page.y1 >= (ya))
PAGE_CONTAINS
is littered throughout the DOGM file.
I am soooo tired. I worked last night and am staying up all day to switch. I have to be at work WED morning.
OK! Have a good night's sleep!
I can't sleep yet.... I have to stay up. At least 4 more hrs.
So did putting the simple loop code inside of a
if (PAGE_CONTAINS(0,y_offset+(GRID_MAX_POINTS-1)*pixels_per_Y_mesh_pnt+pixels_per_Y_mesh_pnt/2 )) {
// Display Mesh Point Locations
uint8_t i, j;
u8g.setColorIndex(1);
for (i = 0; i < GRID_MAX_POINTS_X; i++) {
for (j = 0; j < GRID_MAX_POINTS_Y; j++) {
u8g.drawBox(x_offset+i * pixels_per_X_mesh_pnt + pixels_per_X_mesh_pnt / 2,
y_offset+j * pixels_per_Y_mesh_pnt + pixels_per_Y_mesh_pnt / 2, 1, 1);
}
}
}
work? Because, if it did... It is not the PAGE_CONTAINS() that is causing problem. It is those complicated for() loops.
This:
// Display Mesh Point Locations
uint8_t y = y_offset + pixels_per_Y_mesh_pnt / 2;
if (PAGE_CONTAINS(y, y)) {
uint8_t i, j;
u8g.setColorIndex(1);
for (i = 0; i < GRID_MAX_POINTS_X; i++) {
for (j = 0; j < GRID_MAX_POINTS_Y; j++) {
u8g.drawBox(x_offset+i * pixels_per_X_mesh_pnt + pixels_per_X_mesh_pnt / 2,
y_offset+j * pixels_per_Y_mesh_pnt + pixels_per_Y_mesh_pnt / 2, 1, 1);
}
}
}
Now has the mesh points plotted only along the top row.... nothing down any column.
Probably because you need something more like:
uint8_t y = y_offset + (pixels_per_Y_mesh_pnt*(GRID_MAX_POINTS-1)) + pixels_per_Y_mesh_pnt / 2;
if (PAGE_CONTAINS(0,y) {
}
The second parameter to PAGE_CONTAINS() is trying to see if the number is less than the max line on the page.
Alright....here's what made the new code work:
u8g.setColorIndex(1);
const uint8_t sx = x_offset + pixels_per_X_mesh_pnt / 2;
uint8_t y = y_offset + pixels_per_Y_mesh_pnt / 2;
for (uint8_t j = 0; j < GRID_MAX_POINTS_Y; j++, y += pixels_per_Y_mesh_pnt)
if (PAGE_CONTAINS(y, y))
for (uint8_t i = 0, x = sx; i < GRID_MAX_POINTS_X; i++, x += pixels_per_X_mesh_pnt)
u8g.drawBox(x, y, 1, 1); <============= NEEDS TO PLOT X NOT SX!
Now all mesh points are plotted as it should be.
These simple bugs can cause hours of head aches....
Yes... I know. And both are a pain.
You can change it on the 32-bit side.
ultralcd_impl_DOGM.h
Line 1004:
u8g.drawBox(x, y, 1, 1);
I submitted PR 7310.
Back to the TFT... I got the companion wifi adapter:
Setup my 5v regulator for the display:
Plugged it in, configured it in the display's config file, moved the config file to the display's SD and restarted the display. Went to the wifi info and waited for connection. No issues.
Now, I installed and connected to it from my Android phone. Looks and works like Pronterface:
This makes a second point of entry to my printer.. lol (Octopi being the first)
I have not tried to print from SD from the screen or the app. (supported by both)
The phone app works for everything on that screen, although, I cannot test the second extruder option.
The PRINT
arrow take you to the SD file selection screen.
The regulator is getting awfully hot, even with the heat sink. I need a bigger regulator. I have not measured the current usage, but the display and the wifi unit are still running after 5 hrs of 83 deg ambient temp. I suspect it is adequate. I would like a little more 'wiggle' room though.
That does look like a nice interface to the printer!
This is another guy's project. I am looking to help with this. I got my st-links in finally to get this project installed.
Now, it's on to get the jist of this firmware.
It doesn't talk to Marlin yet.
I am ditching that display for now. I can't create new screens with that firmware. There is another project that I will have to get more familiar with to do that.
I've moved on to another display that is fully configurable and can write from scratch fairly easy.
@Roxy-3D, I got that LCD here on Ebay.