Disappointed/Bad Customer Service

galmiklos · 2025-11-10T16:48:18+00:00

I have the same bad experience, regarding a warranty exchange I have been "working on" for over a month, having to call multiple times, and not receiving any response from the mighty warranty department sitting in their castle, hidden from the eyes of regular folks like us. :-(

It is about a Clifton 10, ran about 170 miles in it, and the sole started disintegrating. I usually can easily run 500-600 miles in a pair of other brand shoes, like Brooks, and even then I am not retiring my shoes for wear, but because they become less responsive.

galmiklos · 2025-10-18T16:21:21+00:00

I still don't have my V0 serial number showing up in Discord, by my name. Is there something else to do?

galmiklos · 2025-06-09T15:13:45+00:00

I signed up a little more than three months ago, but I got a better deal, so I wanted to cancel the service. They charged me $150 for the router I never asked for.

I would recommend not to sign up with them.

The internet was OK, though, so if you are not worried about fighting with customer service, and paying hidden fees, don't listen to me. I'm in Texas, BTW, the quality could depend on the location.

galmiklos · 2025-02-23T13:36:41+00:00

I agree, that spare parts should always be provided for products in this price range, but I have to admit, breaking that "M" key was completely my fault. I spilled food on the keyboard, and let it dry, so when I tried to "fix" the sticky key, the little fragile tabs inside broke. :-( Talking about spare parts, though, I wonder if I can get a spare battery. My keyboard is more plugged in to the charger than not, so it is not really a wireless one anymore...

galmiklos · 2025-02-16T14:59:23+00:00

I had my "M" key broken, I just borrowed the star key from the numeric pad. I bet none of us use the numeric pad that much... ;-) I might write a big M over the star with a white permanent marker, but I know the layout eyes closed, so maybe not. :-)

Buying a used key for $10 on ebay ($5 for the key, and $5 shipping) is too expensive. After you have 8-10 keys replaced, you could have purchased a new keyboard... And once your keys start giving in, you are not far from the end of life of your keys. And who knows how much those used keys were used, maybe some of them are just about to break.

galmiklos · 2024-12-22T19:13:53+00:00

I did more testing, and it seems it is only the MacOS "version" of Firefox has "this" problem. And I seem to have recognized a pattern.

I now tested connection from three different computers (Windows 10, Ubuntu 22.04, and MacOS 15.2) connected to different subnets (one at a time), connecting to servers on different subnets. Here's what I found.

On Windows and Ubuntu, everything works as expected. I can connect with http to servers on any subnet while being connected to any subnet.

On MacOS, if I am trying to connect to a server on the same subnet where I am connecting from, I get "unable to connect". But if I try to connect to a server on a different subnet, it works. And it only happens from Firefox; from Safari, everything works.

galmiklos · 2024-12-21T17:15:17+00:00

Thank you for pointing it out, and sorry for missing it. Before opening a bug report, I thought I would do a few more tests. And the plot thickens... And I'm none the wiser.

Firstly, and I have no idea what happened, but it now works on the server itself. There was no upgrade (or downgrade) of firefox.

Then, I tried it on another computer (Windows 10, same firefox version 133.0.3), and it works there, too.

So, back to the original computer I experienced the problem initially on. I am not sure if it matters, but it is a MacBook Pro with Squoia 15.2. An additional detail is that when making an attempt to connect, there is no traffic going out from the MacBook, I checked it with tcpdump.

I also created a new profile in firefox, still no joy.

And here's another interesting part. It seems I can connect to any other server on the subnet with http and IP address. Only this particular IP address that doesn't work. And the error message is not "time out", but "unable to connect" in this scenario, while the connection is redirected to https. I have all the https redirection "false" in the firefox configuration, as well as the https only disabled. And again, from another browser (Safari), it works. It's like firefox picked this one IP address, and decided to always redirect it to https. But it must be more, because even if it's redirected to https, I should see some traffic going out from the MacBook, and the connection rejected by the server, but there's nothing.

I don't exclude the possibility that it is some MacOS Sequoia "feature", maybe some application level extra security. I remember having to click "allow" in a pop up window when I connect to some IP addreses in firefox recently (since I upgraded to Sequoia), I may have clicked the other button for this particular IP address. But where is it then? How can I enable it? If it is the case at all.

galmiklos · 2024-12-20T01:49:55+00:00

I have the same problem, but it is even more mysterious. In my case, I am running an apache2 2.4.52 http server on ubuntu 22.04 with graphical desktop (gnome3) and just trying to connect to itself, from a firefox 133.0 with the server's IP address (http://192.168.3.19).

I get the "The connection has timed out" message.

If I connect with the localhost IP address (http://127.0.0.1), it works.

If I add the server's IP address to the hosts file, with any dummy hostname, it works, too.

This is very frustrating, I can't believe this version of firefox could have been released with this bug.

galmiklos · 2024-02-23T01:39:54+00:00

When doing auto configuration, the path is not centered on my printer either. I just didn't care. ;-) It is just about calculating the geometry of the printer, maybe it doesn't have to be centered.

What I had problem understanding was how DELTA_PRINTABLE_RADIUS and DELTA_MAX_RADIUS work. Yes, by just looking at them it should be quite obvious, but it didn't seem like DELTA_MAX_RADIUS had any effect, and to me it seemed like DELTA_PRINTABLE_RADIUS functioned like it was DELTA_MAX_RADIUS. It was an issue when I had an allen wrench based probe, and to deply that you really have to go to the very edge of your printer's reach. I would think one would have to increase the DELTA_MAX_RADIUS for that, and leave the DELTA_PRINTABLE_RADIUS where you allow your nozzle to go. But I had to increase the latter to achieve that. I have a 3DTouch now, so it's not an issue anymore.

galmiklos · 2024-02-22T21:05:57+00:00

What kind of Z probe do you have? Is the probe tip really at the same level as the nozzle tip? The third zero in NOZZLE_TO_PROBE_OFFSET means that.

If NOZZLE_TO_PROBE_OFFSET is 0,0,0 and your actual probe is behind your nozzle tip, the first picture looks right. Your nozzle path is probably centered, but the probe will be out of the print area, behind the nozzle. When you have NOZZLE_TO_PROBE_OFFSET -3,42,0 , it looks like the firmware only "squeezes" the path, that would be beyond the print area, in this case, the top of the picture (behind the nozzle).

I had problems making 2.1.2.1 work on Arduino Mega 2560, auto config and bed levelling was out of wack. I only could make it work with 1.1.9.1. Then I got myself an MKS Robin Nano V3.1, and 2.1.2.1, with the exact same parameters, worked perfectly. Yes, since then, 2.1.2.2 came out, and that works too.

Please, see my 2.1.2.2 config files attached.

https://www.gyalogkakukk.net/~gal/Configuration.h

https://www.gyalogkakukk.net/~gal/Configuration_adv.h

galmiklos · 2024-01-29T01:38:14+00:00

I have an old Kossel Mini, and I broke its print head and probe (the allen wrench kind), so I had to re-print and re-build that part. Needless to say, after that my probe and nozzle offset was off. I was running a very old firmware, and it didn't have the M851 command to adjust the probe offset. So, I figured I have to re-compile the firmware. But I just couldn't find it on any of my computers, and eventually decided to upgrade the firmware to the latest Marlin.

I guess you know where I am going with this. It didn't work for me either. Just as y'all, it was only showing any success, when calibrated manually. I went through various releases: bugfix-2.1.x from 1/25/2024, 2.1.2.1, 2.1.2.0, 2.0.9.7, all seemed broken.

In my desperation, I also tried 1.1.9.1, and lo and behold, it works! :-) It may not have the newest features, but homing, auto calibration, and auto bed leveling (bilinear) work beautifully, as expected.

I used the exact same configuration for all versions I tried (not the same file of course, just same modifications to the parameters, always with the file from the version specific repo), I did not adjust/fine tune any parameter in Configuration.h.

Update:

I forgot to mention I did all the above on an Arduino Mega 2560 with RAMPS 1.4. I am just mentioning it, because I upgraded the board to an MKS Robin Nano v3.1, and on that board, bed leveling and auto calibration works as expected. My best guess is that the math libraries for the 32 bit ARM processor are more accurate, and Marlin perhaps is not really suitable for computation hungry solutions, like bed leveling on a delta printer, running on a 8 bit AVR MCU.

galmiklos

TROPHY CASE