Moving Resolution & DRO

[patofoto]

Hello all. I am finishing the customization on a pen plotter that I have built using a PandaPi to control it and want to use OctoPrint. I have most of the Marlin firmware done but are missing a few functionalities in OctoPrint that want to ask if they are possible or maybe already available via a plugin.
The main reason I want to use Marling and OctoPrint is that I need to use mesh bed leveling so that my pens follow the paper with constant pressure. All I am doing is "printing"(drawing) one layer. Very small deviations on the surface make the pen not write sometimes.
My plotter has no screen and want to control everything via OctoPront. I need to be able to move the Z-axis in 0.025 increments. I have created a Macro panel to help me with the stuff I am missing. My question is if there is a way to change the moving resolution in the buttons available in the control panel in OctoPrint.

This is what I have made with macros:

I am also looking for a way to see the current position of the pen in real time. A DRO. Is there one available as a plugin or something else I am missing?.

I know OctoPrint is mainly used for 3D Printers. I have been using it for years with my Ender3v2. I want this familiarity and ease of use. Any tips or thoughts you might have are greatly appreciated.

[nophead]

I think pen plotters use spring loaded pens so the bed doesn't need to be absolutely level.

You can get a sort of DRO functionality by adding an LCD display under the control of Marlin. I doubt is is practical in OctoPrint because you would need a constant stream of G-code requests of position while trying to send move commands.

[Charlie_Powell]

(slightly off topic but) I hadn't thought that pen plotters could be spring loaded, but that definitely makes sense now that I think about it. Thanks for the information

In answer to @patofoto's question: You could add a set of custom controls to do exactly what you wanted, docs link below.

Real time position is hard, as OctoPrint is not directly controlling motion but adding to the queue of commands to carry out. If you are moving, then pausing, then reading the position then yes it could be accurate because you have waited for the pen to stop moving. As far as I know nothing like this exists already from a plugin.

[patofoto]

@nophead @Charlie_Powell Thank you for your answers. Yes, my pen plotter is spring loaded also but I want to use a Z motor to be able to adjust pressure by design. Think of a brush an using pressure to get a thicker or thinner line. I understand now about OctoPrint and real-time. Was unaware of this. Will look into other alternatives for control like CNCjs, ChiliPeppr or UGCS. Really just want the ability to create a mesh and then use it.

[jneilliii]

Recent Marlin does have position auto reporting option that you could enable to get near real time position data back from the printer, but you'd have to intercept that data in a plugin to display IIRC.

[yet-another-average]

Unfortunately, M140 is far from real time ; granularity is 1 second. Being used to DROs, I can say it would be unusable.
A solution would be to hack Marlin so it sends coordinates over some available pins (hardware or software serial or I²C or even SPI), then read these data on the Pi and display them in a plugin.
A couple of wires and some code. Probably an interesting project. The main problem being not making Marlin stutter while doing its things...

[EDIT] M154, NOT M140 !!!! (M140 is for temperature)

[Ewald_Ikemann]

What's about to use the Marlin features to display the position on the printer display?

[jneilliii]

@yet-another-average

Unfortunately, M140

That's true, AUTO_REPORT_POSITION/M154 is only 1 second intervals.

[yet-another-average]

There's a solution to the OP's problem. But it implies some electronics and code. No PCB required, just a BluePill (was 2$ just before the lockdown). It will be usable if the printer motherboard runs headless.
If Marlin is compiled to use a SPI OLED, it sends bitmaps (srennshots) of the Marlin UI over SPI on the EXP1 / EXP2 connectors. These frames are sent fast enough, with a pretty good refresh rate. 128x64 ; full data is 1 kilobyte, sent at 1Mhz.
The coordinates are in a 7 pixels row, at fixed places. This makes translating a 7x128 = 896 bits not too difficult to decode (some logic '&'s between sub-bitmaps and the u8glib font definitions (only 11 characters : 0-9, '.' and '?' IIRC) : the graphics output can be translated to ASCII characters and then displayed in a plugin.

[b-morgan]

I'm assuming that DRO stands for Digital ReadOut. Can you explain why 1 second intervals isn't sufficient? For the real time readouts I've seen, there are quite a few digits that are just a blur while things are moving. The readout is useful when nothing is moving or is being jogged into a precise position and a 1 second delay shouldn't matter for these.

I have an LCD screen on my 3D printer and the only value I use while a print is active is the Z value. X and Y interest me only when the printer is stopped or paused.

[yet-another-average]

I garantee that you cannot position a lathe carriage or a milling machine table with even one millimeter accuracy if you look at the DRO every second. You just can't. Known problem when watching at the tool and the DRO simultaneously, turning your head or your eyes. And cause of "some" failed parts (out of spec) and some chuck or vise incidents, as well as broken cutting tools ! Not all machine tools are CNC, and even CNC's have electronics handwheel for manual positioning and machining.
The OP is not printing. He makes a plotter. He needs to position a pen. If I understand correctly, he wants to be able to manually move the pen, with 0.025 resolution. Moving 1mm means 40 button presses. Two choices : counting the button presses while pressing the button, or 40 seconds just because he has to wait for coordinates to display.

[patofoto]

Such an interesting discussion!!!. I want to thank all for your time and opinions. All this started because I have a PandaPi control board that uses an embedded Raspberry Pi as a controller. I wanted the single-unit size factor and the convenience of OctoPrint for my pen plotter. I do not need the accuracy of a CNC machine or all the bells and whistles that OctoPrint or a 3D printer might want. The PandaPi runs OctoPrint and Marlin from the Raspberry Pi and not from the controller board as most 3D printers do and this has made tweaking and compiling Marlin for it somewhat more difficult than I am used to (using bug-fix versions of Marlin and VSCode). I have been tinkering with the mechanics of the plotter and now of the firmware for over two weeks now. Have it working well and almost have mesh leveling also implemented. I feel that I want to start using it and stop tinkering with it. The DRO and the convenience of OctoPrint, I realize now, are just a convenience and that the console and a few Gcode commands will do everything I need. I also tried installing CNCjs onto the raspberry pi and skipping OctoPrint but failed and having the RPi connect to the board. I am sure that it has to do with the RPi and the PandaPi board not being designed to use CNCjs and my knowledge is too limited to be able to figure it out. The tech support of the PandaPi is not ideal and I need to start using the plotter. In the end, all these machines are for expanding our creativity, not for sucking it. I am stopping trying to figure out how else to perfect my plotter. It works now. I have to start using it. Thank you all.

[b-morgan]

While it appears that the OP is satisfied with the current state of affairs, I wonder if there is a compromise solution for the example you supplied.

For the case where the plotter is being used, display the coordinates using Marlin's autoreport position, M154, once per second.

For the case where you are using buttons to jog into position, display the coordinates returned from M114, once per button press.

[patofoto]

@b-morgan I like your idea of adding M114 to my macro buttons to get the current position in the console. Can I also ask what is the Gcode way of moving an axis incrementally by a specific amount?.

I want a macro that moves the z-axis by 0.025 incrementally every time I click it.Apologies if this is very obvious.

[b-morgan]

I would think that G91 (if necessary), G0 Z0.025 or G0 Z-0.025, G90 (if necessary).

The absolute / relative positioning commands are needed if Marlin is in a different mode when the macro is entered. Unfortunately, I don't believe there is a command to tell you what the current state is.

[patofoto]

Not at home no but had tried moving with G0 Z 0.025 and after the initial move, it stopped moving. Suspected it was an absolute/relative thing. Will investigate more when I get back. Thank you.

[jneilliii]

yeah absolute positioning would do what you are describing. it's fairly common for end gcode scripts for 3d printing to flip that to relative mode, move up some in z, flip back to absolute and move head out of the way. b-morgan is spot on there.

[b-morgan]

Most slicers do absolute X, Y, and Z. Some slicers will do absolute E (M82 and some do relative E (M83). As you can see from the descriptions, changing absolute and relative with G90 and G91 also changes the absolute / relative state of E so you need to be mindful of that state as well.

I'm disappointed in Marlin for not having commands that save and restore the current state but since they don't, we have to understand the states expected by the gcode we execute.

[patofoto]

This is my workflow so far to be able to probe a mesh.

After a home G28 command I get this. I have already probed my bed with 0.1 being the smallest number I have been able to move my Z axis. I am doing a manual probe with G29:

Send: M420 V
Recv: Mesh Bed Level data:
Recv: 6x6 mesh. Z offset: 0.00000
Recv: Measured points:
Recv:         0        1        2        3        4        5
Recv:  0 +0.00000 +0.00000 +0.00000 +0.10000 +0.10000 +0.20000
Recv:  1 +0.00000 +0.00000 +0.10000 +0.10000 +0.20000 +0.30000
Recv:  2 +0.00000 +0.00000 +0.10000 +0.10000 +0.20000 +0.30000
Recv:  3 +0.00000 +0.00000 +0.10000 +0.10000 +0.20000 +0.30000
Recv:  4 +0.00000 +0.00000 +0.00000 +0.10000 +0.10000 +0.30000
Recv:  5 +0.00000 +0.00000 +0.00000 +0.30000 +0.40000 +1.10000
Recv: 
Recv: echo:Bed Leveling ON
Recv: echo:Fade Height 10.00
Recv: ok
Send: G28 X Y Z F1000
Recv: 
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: X:1.00 Y:1.00 Z:1.00 E:0.00 Count X:100 Y:100 Z:100
Recv: ok
Recv: 
Send: M420 S1
Recv: echo:Bed Leveling ON
Recv: echo:Fade Height 10.00
Recv: ok

I then proceed to verify my current position:

Send: M114
Recv: X:1.00 Y:1.00 Z:1.00 E:0.00 Count X:100 Y:100 Z:100
Recv: ok

I then set this as my work zero (unsure if this is necessary):

Send: G92 X0 Y0 Z0
Recv: X:0.00 Y:0.00 Z:0.00 E:0.00 Count X:100 Y:100 Z:100

If I want to read a new mesh I clear my current one first with:

G29 S5
M500

I then start building my mesh with:

G29 S1

After the first point I proceed with each next point until done with:

G29 S2

It is during these G29 S2 probes that I want to be able to move the Z axis by 0.025 + or -.
I have beed doing it with this:

G91
G0 Z 0.025
G90

I got this sequence because when I click on the OctoPrint UI buttons this is what the console informs me its being processed. For some reason if I setup a Macro this way the macro stops working after a few clicks.
When I build a mesh using the UI buttons with a resolution of 0.1 it works perfectly.
The reason I want smaller increments is that I am using very thin tipped pens where the tip stops drawing in some areas. I will also try using a glass surface to see if helps.

[yet-another-average]

Not sure I understand.
For what I understand (more or less), you'd like to do baby stepping while building a G29 mesh, watching the results on the surface ?

(I had to use a plotter long ago in physics lab, and IIRC the thing had pens similar to Rotring pens with tiny tanks, and pushed down by gravity only ; gravity = constant pressure ; of course analog X/Y, not GCodes ! )