[meta][Q] Where to ask questions about fw for documentation updates #8491
Comments
Yes. Using the 'Issues' list for this is fine. And the active developers pretty much review the most recent issues every day. (That doesn't mean they read every issue. If something is outside of their area of expertise or interest... They may move on to other issues where they can contribute.)
Also... Another obvious area for documentation is UBL can now be used without a Z-Probe even being on the machine. But once again, the normal setup and initialization process is a little more cumbersome. Basically... The user should do a
Yes... That can be done by
This is the right place. And you can do a Pull Request against the documentation repositories to get them updated. |
|
This is great, thank you! To clarify the LCD situation, it's not that I don't have a display but that the display on my machine is one of the 'smart' TFT touch panels. In Configuration.h it defines as if it were a reprapworld_discount_full_graphics display, but as far as I can tell the panel itself doesn't support emulating an encoder, SD communication with the host, or even displaying messages. Makes me seriously think of switching to one of the 'dumb' graphical LCDs. Since the existing document is structured pretty well, I will probably start by adding a section describing how the process is modified for use without an LCD controller. Likewise for your suggestion about adding information on UBL without a probe... and maybe a link from the mesh bed leveling page which this effectively supersedes?
This is excellent news. It seems to me like one of the most obvious benefits of UBL over bilinear leveling, and I think it should be highlighted in the UBL documentation. I'll also add more detail and/or a usage example on the UBL
What do you mean by the last sentence? Does the mesh in storage get modified by the I'll follow up here with specific questions from the doc pages that I can't answer myself as I start to put a PR together. Right now I'm getting the buildroot/Jekyll env setup so I can preview changes locally. |
When UBL was written, the assumption was any LCD Panel would have the equivalent of an 'Encoder Wheel' to click. It would be almost trivial to find an 'equivalent' if it doesn't have that. We could add an option to manually trigger the X-Endstop to be the same as an Encoder Wheel click while UBL has control of the LCD Panel. But almost for sure that is not necessary. In order to navigate the LCD Menus, you have to have something that gets clicked to select a line item. What ever that is.... UBL will use that to trigger the action.
Bob did a good job!
That will help a lot of people. Most people have an LCD Panel. But a lot of old machines don't have a Z-Probe. Either way, it would let a lot of people 'catch up' to where the 3D-Printing technology is at.
The Z-Height corrections are done ifndifferent places and using different methodology for UBL and Bi-Linear. But if you have a mesh that accurately describes your print surface, both of them will produce almost the same correction numbers. Bi-Linear is small. It only adds 5 KB of program space when you turn it one. UBL's purpose in life is to allow the best features of all the previous bed leveling schemes to be used together and combined. It is likely to eat 50 KB of program space when you turn it on. The important thing is people understand when to turn on one or the other. It depends on what they need.
No... The mesh 'in memory' gets modified. To see how the G29 J affected the mesh, it is useful to subtract off the starting mesh. The starting mesh was obtained with a G29 L1. Then the G29 J caused the mesh in memory to get tilted. By subtracting the original mesh with a G29 K1 we get to see the changes with a T option. But that 'difference' is not useful to the printer. The Z-Offset component of the original mesh will be lost at that point. The user can store a number of different mesh's in EEPROM. But the UBL system operates off of the mesh that is in RAM memory. And there is only one of those because of the size. (A 15 x 15 grid with each floating point number eating 4 bytes adds up to a big chunk of memory.)
Great! I'll respond with what ever detail you need to make the documentation 'right'. |
This is actually the problem. The TFT28 and friends #define as a 'full graphic LCD' type, but they contain an onboard micro that handles all of the UI stuff and, as far as I can tell, just communicate with the controller via gcode over the UART. I don't think they actually perform any display or interaction functionality at all from Marlin's perspective (nor properly expose the SD interface). Knowing this it seems like they're a big step backwards in terms of function, for the sake of visual impact, but they seem to be showing up on more factory-built printers because of the visual impact. And admittedly a decent touch UI. I'm likely to replace mine with an actual display, but this may become more of a problem with mid-price east Asian machines going forward.
Indeed!
Understood - and I noticed the large change in program memory requirements - but 2560s at least seem to have progmem to spare. Maybe bilinear is enough for my needs, but I like the idea of being able to probe a dense mesh infrequently and then measure the 3-point offset at the beginning of each print. A nice compromise between probing every print and start-up time. With that said, I will keep your points here in mind as I add to the documentation and try to avoid anything that would make it sound like pure bilinear is obsolete.
I think I understand now.
Thank you for taking the time to answer my questions and help me understand this better! I've got a fork of the docs repo and I'm making first-pass changes now; I'll probably have a draft done tomorrow once I have UBL in my build so I can verify as much as possible first-hand. Since this is my first contribution I'll likely submit a PR early so people can get eyes on it and give me feedback. I'll post a link here when I do, as well as any further questions that come up as I edit. |
The RAM copy of the mesh is sort of like the 'Accumulator' on a micro-processor. That is where all the action takes place. But the values are loaded or generated with other operations. And if the value is needed later, it should be saved. The G29 K was pretty much a debug command so I could see what various things were doing to the mesh. It is fairly rare that a user would need it. But to see how a 3-Point leveling is affecting the mesh, it is useful. In fact... You should be able to do a G29 P0 to zero fill the mesh, and do a 3-point leveling on that. You will get very similar numbers to what happens if you do a G29 L1, G29 J, G29 K. The bulk of the difference will be because each probe point is corrected with the mesh's value at the probe location. And you won't have any correction if you zero fill the mesh. |
@Tannoo Can you shed some light on this? How can a 'smart' TFT even function with Marlin if it can't do an 'Encoder Wheel' click? Does it still inject commands into the command queue ? We might be able to use that ability to know if the user needs to abort a command. |
|
Well, when I was using mine, I used it in conjunction with the RRFG for that very reason. If the tft touch is by itself, then currently, no display should be defined. As I don't think there is sufficient support for it. An encoder can be somewhat emulated on the display. |
What would that require? Does the TFT display have any extra signal wires that can toggle and be brought out to the Atmega boards? What kind of signal can it generate when it is 'somewhat emulating' an Encoder Wheel ? |
|
Not that I have found, but I did not probe or look up the controller for it. The firmware for these displays are proprietary. Currently, they only connect via serial connection and spit out gcodes. |
Can they spit out a GCode when the screen is single tapped and double tapped? Because if so, we might be able to expand the 'Emergency Parser' to be looking for 'Click' activity on the TFT Displays. |
|
Currently is only single-tap. The firmware for these are closed scource and is 32-bit. |
|
Actually... The current Double Click stuff isn't done by the LCD Panel. There is that timer that watches for two quick clicks when control is transferred from the LCD Status routine to some where else. If we can get a single click (or tap) from it... We can probably make it work. |
|
@Roxy-3D Thanks for the further explanation of As for the display (should this be a separate issue for discussion?)
RRFG == reprap full graphics? (were you using that for the encoder/SD bits?) I agree that probably no display should be defined, as there's no reason to bloat the build when the 'display' doesn't act like one. Unfortunately the MKS support documentation says to set it up as reprap_discount_full_graphics...
The MKS firmware (like so much of their work) is proprietary and not very well documented. However, someone has made some progress on an alternate firmware for these panels here: https://github.com/robotsrulz/MKS-TFT I haven't had a chance to test it, don't know if it better emulates a real display, and I don't think the author is actively working on it anymore... but it might give some insight to a more knowledgeable embedded developer about the state of the hardware and what might be possible. |
|
He was waiting on #6970. That got closed due to waiting so long to merge that it was seriously outdated. |
|
Double-clicking currently spits out the gcode twice. If you can filter or watch for that, it could work. |
|
The biggest thing I had with the original firmware, I couldn't create more screens to have more options. Limited to 7 custom buttons. I don't believe that is enough to replace the RRD or the RRFG. |
|
Akajes's work was moving the right direction. Needs feedback from Marlin (temps, positions, etc..) via serial commands... hence the M408 approach. |
If the gcode that gets sent says "The screen got tapped..." We should be able to keep track of the time stamps and see if the two gcodes are close enough together in time to be considered a Double Tap. |
|
@Tannoo @Roxy-3D Are you folks OK with me creating a separate issue for the TFT stuff - maybe a [FR] for better MKS TFT support - and referencing this discussion there? I feel like this deserves to be its own issue, and it's one that will continue to exist well after I've finished asking questions specific to updating the UBL docs. If so, is there any cool way to stitch part of this discussion into the new FR? Edit: it seems like the right answer for now is 'get a proper LCD' xD |
|
Plenty of FR asking for this so not sure what another would gain but yet another FR to close ;) If you figure out how to write a custom FW for the TFT, then I’m sure a lot of people would jump in to help fix any missing functionality, but as it is now, no one with the skills necessary to reverse engineer the HW has really been interested. |
|
We can quit posting about MKS TFT here... That is fine... |
No it's fine, if the issue has already been the subject of FRs that have been closed. Maybe someday I'll have time to hack robotsrulz work for Marlin support, but it probably won't be soon. I find the issue of how to hack in support quite interesting, although it seems that any Marlin-only solution is going to be crippled by the apparent inability to actually display anything on the TFT. |
|
OK, a couple of UBL related questions:
Is this accurate? Or can UBL be set up entirely with an LCD controller now, if one is connected? The 'quick start' gcode sequence in the docs includes the following snippet: G29 P1 ; Do automated probing of the bed.
G29 P2 B T ; Manual probing of locations USUALLY NOT NEEDED!!!!
G29 P3 T ; Repeat until all mesh points are filled in.
Is this the only way to set fade height for UBL, or will it also respect And from above, in this conversation, when @Roxy-3D was describing how to modify the processes for operation without an LCD the main gcode difference was stated as this:
But from the documentation it seems that the |
UBL was developed using a connected host. But it can now be setup entirely with an LCD Panel.
If a 'C'onstant value is not being used to fill unpopulated mesh locations, then an extrapolation is done using neighboring mesh points. The algorithm used is different between Cartesian and Delta printers. The Delta printers do this currently: // P3.1 use least squares fit to fill missing mesh values
// P3.10 zero weighting for distance, all grid points equal, best fit tilted plane
// P3.11 10X weighting for nearest grid points versus farthest grid points
// P3.12 100X distance weighting
// P3.13 1000X distance weighting, approaches simple average of nearest point
Yes. 'T' just says the user desires to see the topology map of the mesh. On some commands that are iterative, (for example G29 P4 R) the 'T' will force a map to be generated for each iteration of the command.
If a 'C' parameter is specified, it will be used. If the 'C' parameter is omitted, a 'smart fill' will be performed.
If the mesh point is not defined, no correction will be applied. Note that any missing mesh point can affect 4 mesh cells. It is possible to operate without the entire mesh filled in. But it causes a lot of confusion when people do that. The G29 P3 gets the unfilled mesh points to 'reasonable' values. And from that point, people can perform a G26 and G29 P4 cycle to get things better and better.
UBL does not do that. If UBL doesn't know the value of a mesh point while printing, it does not attempt to provide any correction. The mesh should cover the area you are printing. And the G29 P3 (with no parameters) is pretty smart. The values it fills in unpopulated mesh points with are 'reasonable'. It is difficult to come up with a scenario where it doesn't make sense to fill in the mesh.
It also respects M420 Z. And its support in M420 also allows the user to specify a Mesh number to load with an 'L' parameter. A similar situation exists for M421, the mesh point editor. The interactive G29 P4 mesh editor is nicer. It is much easier to use it to get a finely tuned mesh. But M421 works just fine to edit the mesh if you don't have an LCD Panel.
Yes. G29 P2 (manual probing) is not available without an LCD Panel. And in general... G29 P2 probing isn't that useful when building a mesh. I thought it would be the 2nd step after a G29 P1. But the G29 P3 is smart enough now, the G29 P2 is not really needed any more. Unless of course, you don't have a Z-Probe on the machine. In that case, the user should at least probe the center of the bed, and the corners. And maybe some 1/2 way points between those locations. And then use G29 P3 C's to fill in reasonable starting values to use for the G26 / G29 P4 cycle. |
|
Thank you, that covers pretty much everything I needed to finish up edits on the UBL docs. See PR here: MarlinFirmware/MarlinDocumentation#106 There are a couple (two?) of items tagged with [CHECK... that could use verification by one of the contributors. There is also still a line in configuration section that reads:
I don't have any experience with deltas (yet) and it's in the published version, but I'll happily fix it if someone can point me in the right direction. |
|
One question I just noticed in playing more with this... I modified #define MESH_MAX_X (X_MAX_POS + (X_PROBE_OFFSET_FROM_EXTRUDER - 2)) Which works out to 173 or so. I just noticed that when I do Should I be leaving the defaults for MESH_MAX_X alone, and relying on UBL to realize that the probe won't be able to reach MESH_MAX_X without moving the head out of bounds? If so that's probably something I need to edit in my PR since I obviously didn't quite understand it correctly. |
Yes. What ever side of the nozzle (left or right and front or back) will result in a row of unpopulated mesh points. MESH_MAX_? defines where the nozzle can go. Not the probe. |
|
I see... UBL is smarter than I am 👍 |
|
We've got discussion going on the PR now, and this issue is referenced there, so I'm inclined to close this issue unless anyone objects. |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
This is really a meta question, so forgive me if it's in the wrong issue tracker.
I'm interested in contributing, and I think the documentation is a logical place to start since I really don't have the free time to get up to speed on the code tree right now to jump into coding contributions. That, and I actually enjoy writing documentation.
What I want to know is where is the appropriate place to ask questions about the current state of the firmware that will get authoritative answers - ideally from the active devs - since the purpose of these questions is to help with updating the project documentation.
As an example, the current UBL feature page is still based on 1.1.2, and I imagine a number of things have changed since then. Some of my questions can be answered easily enough by browsing project history and code, some are probably simplest to just ask (e.g. - what is the state of using UBL w/o a conforming LCD controller; does the design of UBL make it possible to probe a high-resolution mesh, and then transform that mesh with 3-point probing of the bed surface at the beginning of each print).
Where is the right place to ask these kinds of questions and get answers that accurately reflect the state of the firmware for documentation purposes?
The text was updated successfully, but these errors were encountered: