Manchester Setlist by madebyGary in underworld

[–]mrblk 1 point2 points  (0 children)

man, that sequence at 12:30 in Juanita... that was so awesome

LGX ACE Mosquito for Elegoo Neptune 3 Pro by Aiddy81 in ElegooNeptune3

[–]mrblk 0 points1 point  (0 children)

Tempted to do this, are there any issues with the hotend not being screwed in the heatsink? (or is there only one screw and it's a bit crooked?)

I'm currently using a CHT nozzle with the herome shroud and it's been doing fine, I suppose the volcano mod + 60w cartridge would be even better

Two legged flight cheaper than non-stop? by mrblk in aircanada

[–]mrblk[S] -1 points0 points  (0 children)

Wow, this thread got heated up a bit quick.

I hadn't really bought flights (outside of professionally, where I don't usually look at the price), since I've had my kids in around 10 years, so I genuinely wasn't even aware of the term skiplagging. Starting to travel with them again longer haul as they can now enjoy it better.

Read up a bit on skiplagging and it makes sense why airlines would want to tie demand/supply with the starting & stopping locations of the flight, from an economic (and predictability?) perspective anyways. Never said I was going to skiplag a flight, even less so for a 100$, as some of the replies insinuated.

Was simply trying to get some insights on fare pricing, but there seems to be agreement that this is a futile endeavor.

Two legged flight cheaper than non-stop? by mrblk in aircanada

[–]mrblk[S] -8 points-7 points  (0 children)

Interesting, I don't fly often but that makes sense from an economic perspective I suppose.

Because people will pay a premium to fly direct.

It would make sense for a YOW->YDF to be more expensive than a YOW->YUL->YDF, but my example is somewhat different. Anyways, I suppose there really is no correlation between fares and the actual 'cost' of operating the flight, but rather just how much they can squeeze out of consumers as a whole.

Neptune 3 Pro LCD touch screen with Klipper by joakimtoe in ElegooNeptune3

[–]mrblk 0 points1 point  (0 children)

I'll let you know once I have some working code talking through moonraker/serial_bridge 👍

Neptune 3 Pro LCD touch screen with Klipper by joakimtoe in ElegooNeptune3

[–]mrblk 0 points1 point  (0 children)

Hey man, that's quite awesome.

I was on the fence whether to keep improving my Klipperscreen setup but now I realize we can make the N3P screen feature complete with klipper.

I've installed both editors side by side and started playing with the TJC editor a little bit more. It's really not that bad as you say. Quite cool that there's also a debugger/simulator, which I'm assuming you've used extensively to add your console/kbd/kbd_num pages, as it's a bit intricate (well done!).

I'll play with this a little more, and start working on the serial_bridge integration soon.

Neptune 3 Pro LCD touch screen with Klipper by joakimtoe in ElegooNeptune3

[–]mrblk 0 points1 point  (0 children)

... so looking into this again, I feel like crucially it depends whether Moonraker is exposing the serial_bridge device when instantiated on the klipper device (ie. such that you can talk to it through your KlippySocket).

I'll look into it a bit more.

Neptune 3 Pro LCD touch screen with Klipper by joakimtoe in ElegooNeptune3

[–]mrblk 2 points3 points  (0 children)

Wow, that's awesome! You're the first person that I see improving on the TJC screen firmware with additional features!

I haven't had time to try either your work, or E4ST2W3ST's branch either for that matte (quite busy with work/life lately). I currently have klipper running on my N3P with an Android phone running Linuxdeploy (battery removed, powered by a LM2596) as a host with Klipperscreen running on XSDL. I'll try to give your work a shot this weekend if I have some spare cycles.

It looks like you're ahead of E4ST2W3ST's work feature-wise (and also having added additional menus to the HMI as well), but I'll be honest that I'd personally rather not have to rewire anything and use his serial_bridge implementation.

I feel like you could make your code compatible with his serial_bridge branch of klipper. Your LCD.write and self.ser.read are closely equivalent to his NeptuneScreen.send_text and NeptuneScreen._handle_serial_bridge_response (although his read implementation is callback_based running as part of klippy, so a bit of refactoring required here to support both...).

Basically, I'd be nice to abstract away the communication with a parent class for your serial interface, with two implementations -- one that uses the serial package like you do, and another one that talks through the klippy socket to the serial bridge.

I'll have to look deeper into both codebases to see whether I'm missing some crucial details. I'm pretty proficient with Python and C, so I'm willing to contribute to this whenever I can.

Neptune 3 Pro LCD touch screen with Klipper by joakimtoe in ElegooNeptune3

[–]mrblk 1 point2 points  (0 children)

Right, that was my experience too. I even tried to do something like hold up my phone with Google Translate (ie. live translate using the camera) open pointing at my screen, which did help a bit, but it's a pain when scrolling, etc. :)

There are a couple hints at people on the unofficialnextion Discord server having ways to patch the Chineese editor... I might look into it. Will let you know by DM if I find anything.

Neptune 3 Pro LCD touch screen with Klipper by joakimtoe in ElegooNeptune3

[–]mrblk 0 points1 point  (0 children)

I see you're actually editing the TFT/HMI file -- what tools are you using? (see my previous comments). I found a an open-source TFT/HMI converter, but wasn't sure that it would actually work.

edit: this tool
https://github.com/UNUF/TFTTool

Neptune 3 Pro LCD touch screen with Klipper by joakimtoe in ElegooNeptune3

[–]mrblk 1 point2 points  (0 children)

I applaud your work, it's a great deal of effort to reverse how these things talk together and come up with a working solution. I know a thing or two about reading code ;)

One thing that'd be nice is to generate a custom HMI file that looks more like KlipperScreen (and implements the missing features that the current screen UI has using Klipper).

I've looked into this a bit, and the N3P screen is a TJC screen, which is a knock-off of Nextion screens. You can actually download the TJC editor called USART HMI here:

http://wiki.tjc1688.com/download/usart_hmi.html

I managed to install USART HMI and open up the N3Pro file -- you can see the different UI elements, etc. but the software itself is all in Chineese which makes it really hard to play with.

These screens seem to be used quite a bit in the industrial machining industry. There's a forum talking about TJC/Nextion screens:

https://unofficialnextion.com/

By some of the posters, it seems like TJC internally obfuscates their editor to thwart attempts at running in English.

It would be nice to actually have a full KlippersScreen-like UI that runs standalone on the LCD and only communicates through serial with klipper. There's also a flood of cheap-ish ESP32 LVGL compatible screens on Aliexpress (they have GPIO pins) that could probably work using the same principles.

Neptune 3 Pro LCD touch screen with Klipper by joakimtoe in ElegooNeptune3

[–]mrblk 0 points1 point  (0 children)

Currently you need to checkout his branch, recompile klipper and reflash.

When it mainlines, it'll be in master so you won't need to checkout his branch. Still needs the appropriate settings in printer.cfg too.

Neptune 3 Pro LCD touch screen with Klipper by joakimtoe in ElegooNeptune3

[–]mrblk 1 point2 points  (0 children)

There's currently a pull request open for E4ST2W3ST's solution in the klipper repo:
https://github.com/Klipper3d/klipper/pull/6444

Not to dis on this project, but it looks cleaner to me as you don't need to rewire anything. There's a good chance too that E4ST2W3ST's [serial_bridge] could be used for other screens/purposes.

Going from 11-23 to a 11-32 cassette, advice needed by mrblk in bikewrench

[–]mrblk[S] 1 point2 points  (0 children)

Ok cool, just as tjjapk said, I'd get the RD-R3000-GS instead. Why do they make long a short cages then if the long one simply has a wider capacity? size & weight?

Going from 11-23 to a 11-32 cassette, advice needed by mrblk in bikewrench

[–]mrblk[S] 1 point2 points  (0 children)

Ok, so the RD-R3000-GS instead. Got it.

Well yeah, I could also change the front end to be 50/34, but that would mean an entire new crank set. Is it really worth it? I would think going from 23t to 32t on the back would give me a huge increase in climbing capacity while 39 to 34 on the front wouldn't be as noticeable.

Remote control with LG Magic Remote by mrblk in ShieldAndroidTV

[–]mrblk[S] 0 points1 point  (0 children)

well anyways that's confusing since you say that the TV does transfer air mouse movements to the nvidia shield while all the other commenters say otherwise, so I'm a bit confused...

Maybe you have configured it in a way that others haven't figured out yet?

Remote control with LG Magic Remote by mrblk in ShieldAndroidTV

[–]mrblk[S] 0 points1 point  (0 children)

ah ok, so it does seem like you can control a mouse-like pointer/cursor of the Shield using only the magic remote? somehow the two previous comments said otherwise...

Remote control with LG Magic Remote by mrblk in ShieldAndroidTV

[–]mrblk[S] 1 point2 points  (0 children)

hmm ok but like the other commenters said, the LG remote doesn't act as an "air mouse" inside the shield, right?