PrintEye; simple information panel for Duet boards.

EasyTarget

@zapta said in PrintEye; simple information panel for Duet boards.:

Can you use PanelDue while this is connected?

As it is, no. Not unless you can find another UART/Port for it.

But.. you could wire the RX line only on some sort of splitter cable, this would leave it 'parisitic' on the same serial port as the PanelDue. It would then rely on PaneDue for sending the requests, but should independently recieve and process the responses. (theoretically.. ymmv).

Next step is to add buttons and joystick

I'm more thinking of a CNC pendant, xyz(+a) position and tool info on a single display, jog and probe buttons etc.

zapta

@EasyTarget said in PrintEye; simple information panel for Duet boards.:

I'm more thinking of a CNC pendant, xyz(+a) position and tool info on a single display, jog and probe buttons etc.

I think this idea will have a lot of interest here, per https://forum.duet3d.com/topic/11389/cnc-st

Danal

@EasyTarget said in PrintEye; simple information panel for Duet boards.:

@zapta said in PrintEye; simple information panel for Duet boards.:
You could wire the RX line only on some sort of splitter cable,

It should work with just the TX out of Duet that go to RX on the Panel, have that wire also go to the RX into PrintEye, There should be no need for any active components, diodes, etc. The one output gate on the Duet should drive 5 or more inputs on Panels and PrintEyes and so forth; they are very low impedance.

Going "pendant" is a whole nother kettle of fish. The TX lines from the Pendant and the Panel probably need a diode so they don't backwash into each other. Then, there may need to be some sort of collision detection. Or maybe not; just don't attempt to use Panel commands and Pendant buttons at the same time. Maybe.

zapta

@Danal said in PrintEye; simple information panel for Duet boards.:

There should be no need for any active components, diodes

Yes, this should work. I used something similar for my status led. It just sniffs on traffic from the duet and passively extracts information from the jsons.

The TX lines from the Pendant and the Panel probably need a diode so they don't backwash into each other.

Theoretically you can also you can also run it in proxy mode. Your device has two rx/tx pairs, one for the paneldue and one for the duet, and have smart software that will buffer duet commands and send them to the duet when idle. Or something like that. Requires more thinking.

Danal

@zapta said in PrintEye; simple information panel for Duet boards.:

Theoretically you can also you can also run it in proxy mode. Your device has two rx/tx pairs, one for the paneldue and one for the duet, and have smart software that will buffer duet commands and send them to the duet when idle. Or something like that. Requires more thinking.

The current implementation, on an ATMega328P, has only one UART.

There are LOTS of other chips, and selecting something with 2 UARTS would be easy. Proxy mode would work great with two UARTs. Very straightforward.

EasyTarget

@Danal said in PrintEye; simple information panel for Duet boards.:

current implementation, on an ATMega328P

One of the design goals was to keep it on the 328P since I have a bag of them on my desk. I guess I always assumed that someone with a PanelDue already has a superior display on their machine and would go 'meh' at this.

PS: Having lworked on this a lot, my go to choice for an alternate processor would be something like an ESP8266. So I could connect via wifi and never have to worry about serial cables or limited cpu resources again.

Something like this in fact: https://github.com/Qrome/printer-monitor

I use two of these at home.
It's an octoprint accessory with a better display and functionality,
it helped inspire me, I contributed some code to it.
But I made PrintEye and so never got round to implementing Duet support on it.

Danal

I have implemented a Duet specific, ESP8266 based, monitor. Designed for the little boards that have the ESP, a 1.2 (or was it 0.9??) OLED, and a carrier for a single lithium 18650 style cell. It has a built in charger, micro usb.

It was based on one of the octoprint monitors, possibly even the one mentioned above.

I need to post the code on Github.

If it can't connect to the WiFi network, it flips over into Access Point mode, and you connect to it (with your phone or whatever) and config the SSID and Password.

After that, there is a web page that can be used to set the Name or IP of the printer.

After that, it scrolls through various temperatures and times regarding the print in progress.

It could be VERY easily upgraded to also be a "pendant".

EasyTarget

@Danal
Nice, I like the sound of that, if you do get it to a state where you push it out please let us know

I'm currently playing with ESP32-CAM units; yet another plan(*) involves one of them (using Wifi this time) since there should be enough IO left over for a stepper and endstop, or servo.
Idea is to make a webcam that can self track current Z height, and turn on when needed, auto time-lapse while printing etc.. Think This, but with power coming via the rods+wifi

(*) Note to self: Stop. Finish other stuff first.

Danal

@EasyTarget said in PrintEye; simple information panel for Duet boards.:

(*) Note to self: Stop. Finish other stuff first.

Aaaaaaaaaaaaaaaaaaamen!!

T3P3Tony

@EasyTarget I saw from your signature that you had a plan for PrintEye for when M408 is deprecated and removed?

EasyTarget

@T3P3Tony said in PrintEye; simple information panel for Duet boards.:

@EasyTarget I saw from your signature that you had a plan for PrintEye for when M408 is deprecated and removed?

I do indeed; but was avoiding necro-posting here until I had something to show..

TL;DR

The original PrintEYE code probably could be modified for M409 use; but it would be fiddly; directly targeting the keys needed and avoiding fetching full keysets. It's quite do-able but I want to move on.

The ATmega328 is the limiting factor; it's really low on RAM and once you have displays etc also running the JSON decoding became a 'mare, eventually I had to cobble together a 'inline' json decoder from various libs I found neglected elsewhere. Plus I was crippled in choices of fonts due to ROM space, and had to forget using a framebuffer (ram) and directly draw the screen.
It was good fun and satisfying to do, but not again...

After I finished the original I started on 'PrintESP' with a similar plan, but a WemosD1 mini in the same case. And the code ported to take advantage of all the extra resources.

Did you know that 99% of D1 mini clones cripple the UART with a pulldown resistor? I didnt.. That, cranky SoftSerial implementations and covid stopped progress.

What did happen during Lockdown was that I learned Python.. eventually coming up with 'SBCeye' (unoriginal naming is my superpower):
https://github.com/easytarget/SBCEye

To cut to the chase; I've been working on 'PrintPy', smaller and snazzier, micropython powered with 2 cores and a framebuffer! But still 2x OLED's and one button.
https://github.com/easytarget/PrintPy2040

If curious take a look at the Python/Tools folder, the script there currently runs well, is data-driven and flexible, and prints a once-per-interval status line from the OM. It's very in-development so ymmv.

yngndrw

@EasyTarget You may want to consider an ESP32 over the RP2040. I adore the RP2040 and use it whenever I can but I often find that for projects which involve a lot of JSON, the memory limit becomes an issue. The ESP32 has the advantage that it can use external memory, whilst still being a modern dual-core microcontroller.

EasyTarget

@yngndrw said in PrintEye; simple information panel for Duet boards.:

You may want to consider an ESP32 over the RP2040

The design uses a XIAO (seedstudio) form-factor. Go for it.

I have a ESP32-C3 (risc-v) Xiao that I could use.. Or I could get either of the S3 Xiao boards. But they all lack an onboard NeoPixel (and cost more..), so I'd need to add one, or do without.

Actually the Xiao C3 board is going to run a LORA transceiver + temperature sensor at my sailclub.; 5uA deep sleep, USB-C and onboard charging circuit for 5eur! Fantastic bit of kit. Also risc-v which pleases me; I have a VisionFive2 running LaserWeb on my CNC.

There is a pattern here which I'm seeing a lot; Somebody mentions using ESP32 and shortly thereafter someone arrives saying 'but why not use Pico!', and vice-versa.

PrintPy can use both... It's a concept, not set in stone.

edited for tone.

yngndrw

@EasyTarget I'm just advising that memory might become an issue for the JSON parsing, that's all. I did say I adore the RP2040, it's my go-to when memory isn't an issue - They all have their place. I'll keep to myself next time, sorry to bother you.

EasyTarget

@yngndrw You are right, I was a bit snarkyt there; you make a good point and as I have yet to begin porting from CPython to microPython, your words might haunt me when I do

I apologies for the last comment; we've recently had some similar stuff with fanboys/spambots on makerforums and I was translating that here. Mea Culpa.

yngndrw

@EasyTarget No worries, I'm sorry my message came across badly - It was probably not the best judgement for my first post on here in years to be a "have you considered X hardware" post. The issue only came to mind because I'd recently used an RP2040 (Specifically the W5500-EVB-Pico, a fantastic board if you need ethernet in a project) on a commercial project and hit the memory limit a number of times. At the end of the day the "right" thing to use is whatever you're comfortable with - It's all personal preference as long as you're aware of the limits and trade-offs.

dc42

@yngndrw said in PrintEye; simple information panel for Duet boards.:

I'm just advising that memory might become an issue for the JSON parsing, that's all

You might like to look at the PanelDueFirmware code on github. It uses a Json parser that uses minimal RAM.

yngndrw

@dc42 said in PrintEye; simple information panel for Duet boards.:

@yngndrw said in PrintEye; simple information panel for Duet boards.:

I'm just advising that memory might become an issue for the JSON parsing, that's all

You might like to look at the PanelDueFirmware code on github. It uses a Json parser that uses minimal RAM.

Ohh I didn't notice that library, I'll have to give JSMN a try in my own projects! Thanks.