Voron Trident 350 extremely slow build

[mbunjes]

I must say I'm a bit underwhelmed by the Fysetc Spider board. The documentation is sparse to put it mildly and confusing.

After coming from the extremely well documented Octopus this is a bit of a disappointment.

[mvdveer]

19 hours ago, mbunjes said:

Wiring of the new controller finished. Mow let's see if I can get Klipper to work.

Very tidy and neat

[smirk]

Good spot! And just as well the magic black smoke did not escape i the process.

[mbunjes]

Thank you sir. But now I have a problem.
The Revo Voron does not clear the bed to reach the sexbolt end stop.
The tool head is at max X but as you can see the clearance is not enough.
Since I cant move the Trident bed I'm not sure what else to do

[mbunjes]

I realized I had my bed a bit higher than standard so I managed to install the thumbscrews and the top of the sexbolt is now level with the bed. 

[claudermilk]

One other thing that I did is filed down the printer part a bit. The edge of the Chicago Screw head is nearly even with the back edge of my bed. I've also shoved the bed as far forward as part wiggle room will allow. It's tight fit, but it works in the end.

Just ignore the drool & yellow filament blob. I had just changed filament. Also, the proximity to the bed isn't an issue that part has nearly 860 hours of print time sitting there, plus any preheat time. YMax is set at 260 which puts the gantry physically about where yours is at.

[mbunjes]

Yeah, thanks, it's tight but it works.

 

[mbunjes]

After a long wait for the postal services to wake up and do their job, finally : first power up of the Stealthburner toolhead : success !

[mbunjes]

Please help !  I was checking and everything worked beautifully but suddenly Moonraker started disconnecting every 10 seconds or so and now I can't connect at all anymore.

I did move the Z-axis rather vigorously (I thought the printer was off but it wasn't) just before this happened. I sure hope I didn't brick my board.

I have to ask for help because I'm not very good with Linux and have no idea where to start troubleshooting.

[smirk]

Don't worry we'll get through this. FIrst question are you able to log into the Raspberry PI - SSH in from another machine? That'll let you start poking around log files.

If you'd manually moved the z-axis without disconnecting the stepper motors, then I might expect the worse you'd do is knacker a driver rather than the entire board. However, just checked on my setup  and disconnected the MCU from the PI and all Mainsail grumbles about is that it cannot connect to the MCU. So I suspect the issue might not be a dead board.

If you can get logged into the PI you can check various log files - happy to help with that.

[mbunjes]

Thanks for your help.

I can start a web-browser session, it seems that when I issue a few commands the connection stops.  When I do nothing the connection seems stable.

I am able to ssh into the Pi at the moment.  

I managed to attach both the Klippy and the Moonraker logs, is that ok ?
 

klippy.log moonraker.log

[mbunjes]

i spoke too soon, I just lost it again without doing anything.

 

[smirk]

Sorry dog was harrassing me for food (and probably a walk).

If you can get logged into your PI - I'll assume it's using the standard "pi" user account, if that's the case then the "home" directory for "pi" will be "/home/pi" and everything related to moonraker, klipper, mainsail, etc will be stored in that directory (in various sub directories).

The moonraker logs will "probably" be stored in the "/home/pi/klipper_logs" directory. So when logged in, at the command prompt type "cd klipper_logs" (you will automatically be placed into the "home" directory when you log in).

You can the type "ls" to list the files in the directory (NB: you can see which directory you are currently in by using the "pwd" command).

This is an example from my machine:

pi@voronpi:~ $ cd klipper_logs
pi@voronpi:~/klipper_logs $ pwd
/home/pi/klipper_logs
pi@voronpi:~/klipper_logs $ ls
klippy.log             klippy.log.2022-08-02  klippy.log.3.gz  klippy.log.7.gz      moonraker.log.1           moonraker.log.3.gz  moonraker.log.7.gz
klippy.log.1           klippy.log.2022-08-04  klippy.log.4.gz  mainsail-access.log  moonraker.log.2022-08-04  moonraker.log.4.gz  webcamd.log
klippy.log.2022-07-31  klippy.log.2022-08-05  klippy.log.5.gz  mainsail-error.log   moonraker.log.2022-08-05  moonraker.log.5.gz
klippy.log.2022-08-01  klippy.log.2.gz        klippy.log.6.gz  moonraker.log        moonraker.log.2.gz        moonraker.log.6.gz
pi@voronpi:~/klipper_logs $ 

There's a bunch of log files. Things which have numeric (e.g. "2.gz" ), or date extensions (e.g. "2022-08-22") are old/archive log files. The current log files have a ".log" extension.

There should be a "moonraker.log" file. Since you've been getting disconnected every 10 seconds I'd expect there to be a fairly regular stream of error messages dumped into that file.

You could try a "tail -f moonraker.log" that will display the 10 last (most recent) lines writen to the file and continue to display each and every new line that gets written (the "-f" stands for "follow" the file contents).

For example:

pi@voronpi:~/klipper_logs $ tail -f moonraker.log
mcu 'mcu': Unable to connect
Once the underlying issue is corrected, use the
"FIRMWARE_RESTART" command to reset the firmware, reload the
config, and restart the host software.
Error configuring printer

2022-10-27 19:40:12,403 [authorization.py:_check_trusted_connection()] - Trusted Connection Detected, IP: 192.168.5.231
2022-10-27 19:40:12,406 [app.py:log_request()] - 101 GET /websocket (192.168.5.231) [_TRUSTED_USER_] 5.48ms
2022-10-27 19:40:12,406 [websockets.py:open()] - Websocket Opened: ID: 1751199024, Proxied: True, User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:105.0) Gecko/20100101 Firefox/105.0, Host Name: voronpi.local
2022-10-27 19:40:12,592 [websockets.py:_handle_identify()] - Websocket 1751199024 Client Identified - Name: mainsail, Version: 2.2.1, Type: web

You can see from my moonraker.log file the complaint about the MCU not being connected (I deliberately disconnected it). Hopefully you will see the errors displayed causing the problem - the errors will be fairly inscrutable so happy to help decipher.

As I say if you're getting a disconnect every 10 seconds you should see a lot.

 

To cancel the "tail -f" command just press CTRL+C (Control key and "C" simultaneousl) and that will take you back to the LINUX command prompt. To logout just just the "logout" or "exit" commands.

 

Post what you find and we'll help.

 

 

[smirk]

The lines

2022-10-27 16:33:15,067 [update_manager.py:_get_remote_version()] - Client fluidd-core/fluidd: Github Request Error - [Errno -3] Temporary failure in name resolution
2022-10-27 16:33:15,271 [klippy_connection.py:_check_ready()] - Klippy ready
2022-10-27 16:33:15,611 [announcements.py:_fetch_moonlight()] - Failed to update subscription 'moonraker': [Errno -3] Temporary failure in name resolution
2022-10-27 16:33:15,745 [data_store.py:_init_sensors()] - Configuring available sensors: ['heater_bed', 'extruder']
2022-10-27 16:33:17,655 [announcements.py:_fetch_moonlight()] - Failed to update subscription 'klipper': [Errno -3] Temporary failure in name resolution
2022-10-27 16:33:19,697 [announcements.py:_fetch_moonlight()] - Failed to update subscription 'fluidd': [Errno -3] Temporary failure in name resolution

look interesting. Need to figure out which name it's failing to identify and connect to -  or rather what does the machine call itself. It'll be just one process running on the PI speaking to another process running on the PI but the machine will have a name for itself which it probably has set up automatically.

I'll have a dig once I've walked the dog.

[smirk]

Couple of quick questions. Your hostname (PI name) is "fluiddpi"? From the PI itself what happens when you ping fluiddpi ?

It probably should resolve to something like 127.0.1.1?

Also if you disconnect the MCU complete (pull out the USB cable and reboot) does the behaviour change? Just wondering if it'll then start to just grumble out the MCU not being connected or still give these continuous disconnect/name resolution issues? Right dog walk....

[mbunjes]

I can ping fluiddpi, although the times fluctuate between 210ms and 4ms. Strange.

When I remove the usb cable the dashboard immediately complains "Lost communication with MCU 'mcu'

I don't have to reboot to see that.
At the moment the connections seems stable 

[mbunjes]

Could it have been a wifi hiccup ?

[smirk]

That huge variance is rather concerning. Unless you've got a lot of activity on the network. Pinging my PI across my WIFI and it varies but is a nice average of 4ms (occasional max of 7ms). Internally (i.e. pinging itself from itself) and it is is rock solid at 0.1ms. I presume that 200ms variance is external (e.g. from you laptop to your PI)? Rather than internally (on the PI itself) - if it was varying that much on a virtual (loopback) adaptor then something is seriously broken.

However, even on 200ms variance that's disrturbing, unless of course there's some major WIFI activity.

I'm still interested in that temporary name resolution failure.

There shouldn't be any name failures if everything was internal to the PI (at most it's connecting to the loopback), but your WIFI comment got me thinking?

Are you using http://app.fluidd.xyz ?  That will run in  a browser on your laptop/desktop and that could be the issue with failed name-lookup with horrendous network timeouts. I can see app.fluidd.xyz in the CORS section of the moonraker config, so I'm presuming....

As well as the incredibly high ping times - are you experience a high packet loss?

[mbunjes]

I just did a re-ping : 
14ms
10ms
8ms
126ms

No loss : 0%

I'm running fluiddpi.local on my desktop to connect to my pi. The desktop is connected to an old router that I use as a wifi extender. Works like a charm. Well, maybe not anymore.

And again I tried to ping, but now I can't get a reply on the hostname, only on the ip address. It looks a lot better though

14ms
10ms
6ms
5ms

[smirk]

1 hour ago, mbunjes said:

Could it have been a wifi hiccup

I think that's probably it. I was playing with app.fluid.xyz on my set up (since I use Mainsail) and I can see why it might crap out if the network (wifi) is dodgy/overloaded. The app.fluid.xyz uses websockets, personally I hate it with a passion but I have my own grumpy-old-man-made-my-life-unneccesaily-complex reasons for that, but it means there's a constant two-way chit-chat going on between your PI and your browser so any network issues (higher latency, lost packets) is going to cause unpleasant non-optimal issues.

[mbunjes]

But I'm using the http connection for fluidd

[smirk]

1 minute ago, mbunjes said:

I can't get a reply on the hostname

Oh dear, thegrumpy old man in me is coming out (bloody websockets, bloody mdns). You should be able to ping your fluidpi.local - I'm presuming you use the name to connect your desktop fluidd app to the moonraker gubbins on the PI?

I'm trying to remember the order that I need to resolve things in, occassionally my local (voronpi.local) name goes (and beyond cursing I cannot remember if I reboot everything in a particular order).

What sort of machine is your desktop (windows,mac, linux, etc)? If you normally use the name to connect that I think simply clearly the DNS cache on your local machine might resolve that issue (forces your machine to look up the address again).

 

[smirk]

5 minutes ago, mbunjes said:

But I'm using the http connection for fluidd

Sorry, I'm probably confusing things in a grumpy old man way - (websockets is a protocol build on top of HTTP and will be used by websites/web applications without your knowledge, it's just how they work internally to communicate behind the scenes to do all that fancy-schamcy dynamic updating ofweb pages).

[smirk]

13 minutes ago, mbunjes said:

No loss : 0%

I agree it's looking better, as you say the wifi has perhaps had a brain fart. It's not necessarily that your wifi extender setup is giving up.WIfi is akin to black-magic and can be pretty fickle at times (too much humidty, tin-foil hats, someone turning on their mobile hotspot can all cock it up).

If the latencies have settled down and stopped varying wildly that is good, the 0% packet loss is excellent. The only remaining fly-in-the-ointment is the name resolution (as I say I presume you connect the fluidd on the desktop to your PI as http://fluidd.local or some such).

The MDNS (multicast DNS) stuff works with your client machine "shouting" who's this name  (fluidd.local) and the server (raspberry PI) broadcasting a response which includes its IP address. Wonderful when it works and a PITA when it doesn't. WIthout rebooting everything I think clearing the DNS cache on your desktop should fix the issue .

[mbunjes]

It's a rather old windows 10 desktop. You're not confusing things my ancient mind had forgotten my hard learned IT lessons. I flushed the dns cache (thank god I remembered how to do that).

Did a ping on the hostname : success and this time an average of 4ms