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.
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)
What's about to use the Marlin features to display the position on the printer display?
That's true, AUTO_REPORT_POSITION/M154 is only 1 second intervals.
1 Like
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.
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.
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.
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.
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.
@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.
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.
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.
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.
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.
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.
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 ! )
Yes, correct. I guess I explained too much. Figured that it might be helpful to someone who understood Gcode and absolute vs relative space. In the end I want to micro step while building G29 mesh. The UI in OctoPrint has only 0.1 as the smallest move. Was trying to set up smaller moves via Gcode and macros.
Know enough to get in trouble but not enough to know what I am doing wrong.
Seems to me it can't work. Your babysteps will not be taken into account until the current motherboard GCode buffer is flushed. G29 and G28 are loooooonnnnng commands !
Suggestion : you could create a GCode pattern. for example circles or spirals at various places and use real, hardware babystepping commands (encoder) while "printing" (drawing). Doing this with OctoPrint is not a great idea IMHO. You have to do this on the motherboard hardware, bypassing the command buffer. Reason why Marlin has babystepping. Reason why CNC machine tools have electronic handwheels...
I think you can't do what you need without the encoder and a real time "DRO".
One of the reasons why I'm developping this : Could this become a plugin? ; I keep the encoder, and display real time Marlin UI overlay window on the OctoPrint display. The best of the two worlds. But you have to use the classic HID (LCD + encoder) or do some electronics...
A pattern like this one.
Although super interesting, this is way out of my league. I have a mesh working now and, even though it does now have the fine resolution I need, it works better than not having it. I will try a flatter surface like glass next to see if this brings me to a better tolerance for the pens I want to use.
Super grateful for your time and knowledge.
No skills needed, other than ordering PCBs from china, a few cheap components from Amazon eBay Mouser, RS or whatever ! And a display swap in Marlin's Configuration.h. (I'm myself a noob with OctoPrint coding)
I will measure the lag again (did it 1 year ago, but forgot the results ; it's in the order of 50 milliseconds IIRC). It's near to real time, even in a VNC client window.
1 Like