In a previous life, I was the admin of a large computer network. One of the best features of the Cisco gear we used was the command "show tech-support". It spits out a huge text file with the entire configuration of the device, along with a number of diagnostic command outputs, error and operation logs, component temperatures, version info, etc.
The file could either be used in-place for diagnostics or sent to Cisco tech support for further analysis, sidestepping a lot of back-and-forth with the support people.
It occurred to me that it would not be that hard to achieve something similar, either implemented in firmware or else done in DWC. That file, uploaded to the forum (perhaps via an automated mechanism direct from DWC?) would provide a huge amount of troubleshooting data very easily.
Even better would be a way to unpack that data into a visualiser/validator tool that showed common issues, potential conflicts, firmware upgrade 'gotchas', etc. Again, this is something we had with Cisco where complex configurations led to difficult-to-spot and subtle issues. I appreciate that this is not trivial to implement but it wouldn't have to happen all at once and, once done, might actually cut down on the time spent troubleshooting, especially with 'new user'-type issues.
Overall - at any point, but it'll probably be hard to see the output while printing. Although try that in console - it might work.
Tbh your issue sounds exactly like mine, but, you're right, it's different if you aren't using G10 anywhere.
You might find this old RepRap thread interesting https://reprap.org/forum/read.php?1,182481. Lots of posts from "nophead" who used to make and sell an excellent Mendel variant (in kit form I believe).
BTW there is an identical "CE" mark that is often used but which has nothing to do with any regulatory requirement. It stands for "Chinese Export"
@edgars-batna said in We need a category for reporting problems specifically:
Yes, a form. Something like a JIRA bugtracker, Bugzilla, Redmine, etc.
dc42 has already ruled out a "bug reporting" category.
Structured bug reporting is fine for programmers and beta testers and the like, but for end users it is not going to be pretty.
My question was more the difference in M305 (RRF Configured) VS M307
This may help to explain the difference between M301 and M307.
Yes this I do and is stored in the override config. Used to manually input the PID values after a report on the older Marlin based PCB for this machine.
And as the link goes on to explain, the best way to get PID parameters to use for M307 is to use the auto PID tuning routine provided by M303.
In this case, no matter what, static on the Duet or not, the Duet MAC has to be on the switch port at all times. If not, the Switch will not know where/what port to send the packets. And your PC keeps an ARP table with every IP address and MAC of local devices, or MAC of Gateway for all devices that need to be reach via gateway/router. I maybe speaking a foreign language now.... But if the MAC isn't on the switch (and the switch is working properly), something maybe wrong with the NIC on the Duet. Funny thing is, it appears to stop working every 20 to 25 days and maybe more often during extended time prints over/around 30 hours. (I also do not shut my 3d Printer off)
@gnydick said in Suggestion for change to implementation of baby-steps:
@dc42 He is correct that the Z indicator doesn't show the actual position. If I baby step 100mm from position 5, it will always display 5.
I've said this before, but it doesn't seem to have weight with you, there are MANY more workflows than: click, print, finish.
I expect you to say to add baby step reset to the stop.gcode or to the slicer, but then that would defeat the ability to re-use the value.
And, since baby-steps impact, but not stored value, are transient between homings, as they are just a value applied, with no impact on the actual z height measure, you have to also reapply them between prints if even you don't reset them.
If we see a pattern and that we always need -.15 baby-step, you'll say to apply that offset in the config, but that can be filament specific. So you say, that's fine, keep it global, but when you use a differing filament, adjust the baby-step for that print. That only works for one print if you home between prints. So you say remove re-homing between prints. Well, I have a printer in development that may not be reliable, so I need to re-home between prints.
You see the cycle here? It's like the Three Stooges file cabinet. It's a never ending cycle of work arounds. if the baby-step was part of the z-height register AND remembered to be applied to the offset of the beginning position of a print, all of these situations would be handled without workarounds. Sure, if it seems to be a permanent need, put it in the config. But I don't want to stop what I'm doing, update the config, reset the printer, lose my heat, and start over. Maybe baby-stepping can store to its own file so it persists between reboots.
Like I said, the Live-Z Marlin feature just never fails, it never complicates things. Homing will always trigger at the same height, but the live-z offset both gets applied to the gcode for printing as well as effects the z-height register.
You seem to be saying that the baby stepping offset is somehow remembered over homing but not actually applied. I don't believe that is the case; but I'm willing to be persuaded if you can provide a sequence of GCode commands (+ manual checking of nozzle height if needed) to demonstrate it. The other possibility that occurs to me is that you are homing to max Z and your printer is gradually getting hotter and expanding, so that you need increasing amounts of negative babystepping to counter the expansion.
oh good idea, another spacer didn't think of that, thanks!
I do have the smaller 9 x 20 x 7 on the way, and that I know will not press into the plastic mount, should I use that instead? it's 20mm wide and the mount is 22.3mm so it won't press into the mount, should I use that?
Thanks. That would make implementation simpler by having the RPi manage sending the slices to the LCD panel and control the exposure time.
Any plan to put together a wiring diagram?
I meant to include the link for the mUVe:
page 13 starts the discussion on M650 if it helps
Yeah, that's a pretty standard policy. But this isn't a standard product. If I wanted standard, I'd buy a $30 MKS board off amazon and if it was DoA, I'd expect to have to jump through a few hoops to get it replaced. Instead, I bought a premium product from an authorized distributor for a premium price.